Case study / Healthtech
integra odonto app
From firsthand dental practice workflows to an AI-assisted full-code platform.
- My role
- Founder & Technical Product Lead
- Timeline
- 2022–present; full-code transition from March 2025
- Evidence
- Inspected source + a read-only synthetic patient review
I’m Felipe Peloggia, a dental practice co-founder and technical product builder. I built the AppSheet generation independently, then initiated the full-code transition. I own requirements, domain modeling, UX behavior, acceptance criteria and major system-design decisions, using AI as the implementation workhorse.
This case study describes a bounded evidence set. It does not establish production readiness, successful clinical writes or runtime organization isolation.
01 / Problem & constraints
Keep the clinical context in view.
Dental practice work spans patient registration, scheduling, clinical records, treatment planning and finance. integra odonto app brings these domains into one application for dental practice workflows.
My clinical and operational background informs how I model those workflows and define expected product behavior. The project moved from an AppSheet application toward a React, TypeScript, Express and PostgreSQL platform through AI-assisted implementation.
The presentation has its own constraints: patient information must stay private, personal design ownership must be distinguished from implementation, and a visible interface must not be mistaken for a verified clinical action. The journey below uses only approved synthetic records and read-only observations.
02 / A product journey
Find a patient. Review their context.
Three real application captures show a synthetic patient search, summary and existing clinical timeline. Product labels remain in Portuguese; the annotations here are in English. Each view was reproduced twice using direct route entry in an approved synthetic environment on 28 October 2026.
Step 1
Find the synthetic patient
Filtering the patient list isolates an explicitly synthetic record. Identifying and contact fields are unfilled. This demonstrates the observed filter result, not patient creation or validation.
Real application · Synthetic data · Read-only observation. Open image at full size ↗ Step 2
Review the patient summary
The summary makes missing registration fields visible alongside clinical action controls. Those controls provide interface context; their actions were not exercised.
Real application · Synthetic data · Read-only observation. Open image at full size ↗ Step 3
Inspect the existing clinical timeline
The read-only timeline shows one completed attendance and a linked appointment, with no recorded procedures. These counts describe the synthetic fixture, not business outcomes.
Real application · Synthetic data · Read-only observation. Open image at full size ↗
03 / Engineering decisions
Two boundaries worth examining.
These stories explain choices visible in inspected source and the tradeoffs they expose. My contribution is product and system-design direction with AI-assisted implementation. They do not imply I personally wrote every implementation detail or that these behaviors were exercised in the captured journey.
Separate system and organization database access
Problem: System-level responsibilities and organization-specific data need distinct access boundaries.
Implemented approach: The source separates system-database access from organization-database access. Organization connections are cached by connection identity, with configurable cache and pool limits. The system factory checks configured database identity against the constructed client options.
Tradeoff: Connection reuse comes with connection-identity and cache-lifecycle responsibilities, including expiry and size-based eviction. Separate access paths express the design; they do not prove runtime isolation.
Evidence and limit: Static source inspection supports these mechanisms. My stated design direction prioritizes per-organization runtimes and dedicated databases, but no isolation, resource-use or security test is established here.
Validate appointment inputs at the server boundary
Problem: Appointment input includes time ordering and clinical context that static request types alone cannot establish at runtime.
Implemented approach: Appointment creation uses a shared Zod payload schema in the server handler and OpenAPI declaration. The client mutation calls a generated appointment service. The server parses the payload before calling its service and has an HTTP 400 branch for schema errors.
Tradeoff: Generated request types and runtime validation coexist. The generated payload allows nullable date strings, while server refinement requires a valid, ordered interval. Shared declarations alone do not establish validation parity or generation freshness.
Evidence and limit: Producer/consumer source inspection supports this boundary, including date coercion and clinical patient/professional checks. No appointment request, persistence result or error response was exercised for this story.
04 / Architecture
A logical view of the access boundaries.
05 / Quality, outcomes & current limits
What the evidence establishes.
The demonstrated result is a repeatable read-only review of a synthetic patient across three views, including an existing attendance/appointment relationship. The two engineering stories establish source-level mechanisms and visible tradeoffs. No measured business impact is claimed.
A central distinction is between design intent, inspected implementation and observed behavior. Keeping those separate makes the product review useful without overstating what a screenshot or a shared type can prove.
Evidence scope
Technical stories use source revision 9da4fbd. Captures use a later application revision, 89b558b, in a dedicated synthetic environment on 28 October 2026. Runtime observations from that later build do not verify the earlier source baseline or either engineering story.
Still unestablished here
Clinical writes, appointment creation, end-to-end treatment workflows, runtime organization isolation and full deployment qualification remain outside this evidence set. The captures also do not establish production readiness. The complete static narrative remains available independently of the clinical application.
06 / Continue the conversation
Have a role or a workflow in mind?
I welcome engineering and product-team conversations, and client discussions about workflow modeling, solutions and implementation, or legacy modernization.