Our Client’s Vision

The vision is a marketplace that makes finding and seeing a doctor as simple as any consumer app. Patients search verified physicians, book in-person or virtual visits, complete intake, and pay in one flow, managing care for their whole family, including minors who need a guardian on the account. Physicians get a calendar that syncs with the one they already use, a video room, e-prescribing, and their administrative load reduced rather than moved. Practice administrators get oversight of providers, credentials, bookings, and revenue in one place.

The plan is to prove the model with an MVP and expand if it works, with everything HIPAA compliant from the first release rather than retrofitted.

Technologies

React, Kotlin, Swift, .NET 8 microservices, PostgreSQL, Azure

Integrations

Checkr, NPI Registry, Stripe, Waystar, Twilio, DrFirst, Athena, Azure OpenAI, PDFTron, Azure Face

Team

Core team of 6 full time: project manager, backend engineer, frontend engineer, mobile engineer, QA engineer, and technical lead, with architecture, UI/UX design, and DevOps engaged part time

Timeline

Discovery 6 to 8 weeks, then 7 sprints, about 14 weeks, to MVP release

Challenge

A national two-sided marketplace for clinical care carries constraints a general booking product does not. Five of them shape the build, and four of the five are usually discovered late.

Verification is not identity checking. Confirming a person is who they claim does not confirm an active, unrestricted license. That answer lives in the national provider registry, in each state board, and in background verification, and it changes over time.
Matching is governed by licensure, not distance. A physician licensed in one state generally cannot treat a patient located in another. The rule follows where the patient is at the time of the visit, and the answer changes again by modality. Prescribing adds its own restrictions on controlled substances delivered through telehealth.
Marketplace payments are not checkout payments. The platform collects from patients and pays physicians, which brings connected accounts, payout scheduling, and defined behavior for no-shows and cancellations on both sides. A no-show policy has to be visible on the physician profile and acknowledged by the patient at booking, or it is not enforceable.
There are four user types, not two. Patient and physician are the obvious pair. Clinic administrator and platform super administrator are where verification, disputes, fraud rules, and monetization actually live, and a solo practitioner needs both physician and admin rights under one login.
Protected health information enters the system the moment intake exists, and every downstream tool inherits that boundary, including analytics, notifications, and error reporting. Every vendor touching it needs an agreement in place before launch, not after.

Cabot’s Solution

Cabot starts with a structured discovery phase, then builds to a live MVP in seven sprints. This engagement stops there. AI appears in both halves of it, compressing how the work is done and removing manual work inside the product.

The discovery phase, and what it produces. Six to eight weeks that end with a single report a founder can take to a board, a lender, or an engineering hire. Ten deliverables:

Target user personas built from survey responses and public platform research, covering goals, pain points, and digital proficiency for each role.
High-level user journey maps for every persona, built around hard cases rather than happy paths: a guardian booking for a minor, a disputed no-show fee, a credential that lapses mid-quarter.
User flows for each role, mapping every system interaction, decision point, and data input, which is what makes the compliance checks findable before they are built.
A prioritized feature list under MoSCoW across all portals, so the MVP boundary is a decision on the page rather than an argument mid-sprint.
High-level application architecture with system context, application, and deployment views.
Third-party integration mapping naming every external service, what it does, and which internal service owns it.
A RACI matrix across planning, requirements, design, architecture, development, QA, and launch, so nobody discovers ownership during a release.
A milestone plan and sprint breakdown with a goal and a task list for every sprint through to handover.
A ballpark effort and cost estimate in man-days by role, with a contingency buffer, cloud infrastructure costs at both MVP and production scale, and third-party license costs.
A compliance and security overview covering the applicable frameworks and the specific controls that satisfy them.

The architecture: two data planes, one eligibility gate. Physician discovery, availability, and ratings sit in a public plane holding no patient health information. Intake, video, the encounter record, and payment capture sit in a clinical plane where every vendor is covered by a signed agreement. No booking becomes an encounter without passing the gate, which checks patient location at the time of the visit, license status in that state, verification and exclusion status, and whether the requested modality is permitted. Every decision is logged with its reason.

AI in how the product is built. Cabot's MVP practice uses AI to take on repetitive work so the team spends its time on the decisions that matter. AI supports market and regulatory research during discovery. Coding assistants handle boilerplate and scaffolding. Generated test coverage runs alongside manual QA inside pipelines built for regulated environments. Nothing reaches the repository without human review, and senior engineers own every architectural decision.

What the MVP actually uses, named precisely. One genuine language model feature, and two pieces of automation that are often labeled AI but are not. Naming them accurately matters more than the label, because the distinction is the first thing a technical reviewer will test.

Generated intake questionnaires. Language model. Intake and consent forms produced per specialty and presented at the point of booking, so a physician receives usable clinical context instead of a free-text reason field. This is the one place a model is doing work at MVP.
Document reading at onboarding. Optical character recognition, not a language model. Insurance cards and government ID read to auto-populate profile fields, which removes typing rather than making judgments.
Face matching against government ID. A vision API. Confirms the person submitting the ID matches the photo on it. Machine learning underneath, but a commodity service, not a differentiator.

Credential verification itself is not AI and should never be sold as such. Licenses, certifications, and NPI are checked against the provider registry, state board records, and a background check provider. Those are authoritative lookups, and their value is precisely that a model is not deciding the answer.

AI that comes after MVP, and why it waits. The rest of the AI roadmap is real and costed, and it is deliberately not in the first release. Each item depends on something the MVP has to prove or integrate first.

Symptom-based discovery and triage. Needs booking volume and search behavior to tune against. Guiding patients toward a specialty before there is data on what they actually search for produces confident routing to the wrong place.
Clinical note drafting from visit dictation. Needs the EHR integration that lands in the following release, because a draft note with nowhere to go is a demo rather than a workflow.
Pre-visit summaries from patient free text. Follows intake, once there is enough real intake content to summarize usefully.
Full document extraction across licenses and certifications. Broader OCR and language-model extraction beyond ID and insurance cards, sequenced with the credentialing automation it feeds.

Every one of these keeps a human in the loop by design. Extracted values are confirmed against an authoritative source. Drafted notes are reviewed and edited before submission. Routing suggests rather than decides, and automated diagnostic suggestion stays out of scope permanently, not just at MVP.

‍

Process

Delivery runs on Cabot's delivery framework, executed in two-week Agile sprints with a working demo at the end of every one. Seven sprints take the platform from foundation to a live MVP.

Sprint 0, Foundation. Backlog finalized, CI/CD pipeline, and development, staging, and production environments, with the compliance boundary decided before any feature work.
Sprint 1, Core user foundations. Patient and physician registration, two-factor authentication, profile creation, government ID upload, guardian accounts for minors, and physician credential submission with NPI, license, and background verification.
Sprint 2, Profiles and search. Family accounts, notification preferences, doctor search with specialty, name, insurance, and location filters, and calendar management with two-way sync.
Sprint 3, Booking. Detailed doctor profiles, a real-time availability grid, the end-to-end booking flow, intake and consent forms at booking, a physician's daily dashboard, and a secure video interface.
Sprint 4, Admin portals. Clinic registration, provider management, credentialing status tracking, a master calendar, a super admin verification queue, an audit trail, and a no-show policy with patient acknowledgement.
Sprint 5, Licensure and clinical. Patient location capture and validation against physician licensure, free-text booking notes, secure messaging, and file attachments at booking.
Sprint 6, Close out. Stripe checkout for co-pays and cash visits, the HIPAA-compliant video room, confirmations and receipts, regression and load testing, and production deployment.

Everything beyond this is a decision for after launch, made with usage data rather than assumptions. Insurance eligibility, EHR integration, AI-assisted dictation, subscription tiers, and sponsored placements all sit in later releases and are deliberately not part of this engagement.

Six components carry the MVP:

Credentialing pipeline. ID and insurance documents read with OCR and face matching to remove manual data entry. Physician licenses, certifications, and NPI verified against the provider registry and third-party background checks, with an approval queue, a full audit trail, and scheduled re-verification. Broader language-model extraction across the wider credential set follows in a later release.
Eligibility gate. A standalone service in front of booking that decides whether a physician may treat a patient, in that location, by that modality, on that day, so a change in state rules is a change in one service.
Booking and scheduling. One calendar across in-person and virtual visits, two-way sync with Google Calendar and iCal, a guardian workflow for minors, and availability filtered by what the gate permits, with intake and consent forms generated per specialty at the point of booking.
Encounter service. HIPAA-compliant video with chat and file sharing, a waiting room, a fallback for degraded connections, and a durable record of the encounter.
Payments and payouts. Stripe checkout for co-pays and cash visits, funds routed to the physician's account, eligibility checking with a clear disclaimer, and an enforceable no-show policy acknowledged at booking.
Four-role platform. Patient, physician, clinic admin, and super admin portals over one data model, with the solo practitioner handled as a role toggle inside a single login.

Challenges Faced and Solutions Provided

Matching physicians to patients across state lines. Conventional marketplace matching ranks by distance and availability, which can produce bookings that cannot legally take place. Cabot made eligibility a precondition of search rather than a check at checkout. Availability is filtered through the gate before a patient sees it, using patient location at visit time rather than the address on the account, and blocked attempts return a reason rather than a failure.

Keeping patient data inside a boundary that can be audited. An MVP built as one application drags every attached tool inside the compliance boundary. Separating discovery from clinical data at the data layer let the public marketplace use ordinary tooling while the clinical plane stayed restricted to vendors under agreement, and notification content was designed to carry no clinical detail, which is the most common way an early platform leaks.

Four portals without four products. Building patient, physician, clinic, and platform administration as separate applications would have been the expensive route. One data model with role-based access and one set of services kept the surface small enough to test and made the solo practitioner case a permission toggle rather than a fifth build.

Holding the MVP line. Scope creep is the highest-rated risk on an engagement of this shape. The MoSCoW list agreed in discovery made it manageable, so a request to add something mid-build is answered by a document both sides signed rather than a negotiation.

Impact

At the end of this engagement, the client holds a live MVP and the evidence to decide what happens next. This discovery-to-MVP engagement is scoped to deliver:

A working marketplace in the client's launch states, with verified physicians, booking across in-person and virtual visits, secure video, intake, and payments, ready to open to real patients.
Every booking provably eligible before it becomes an encounter, with the license and location decision logged and auditable on each one.
A compliance posture that survives a security review, because the baseline ships with the MVP rather than waiting for a later hardening phase.
Real usage data on the questions that matter at this stage, including whether patients book a physician they have never met, whether physicians show up, and which specialties and states carry demand.
A documented and costed roadmap for everything deliberately left out of the MVP, so the client's next decision is a choice rather than a rescope.
Assets the client owns outright, including source code, design files, architecture and API documentation, and knowledge transfer to whoever carries it forward.

Conclusion

A care marketplace succeeds or fails on whether it can prove, for every single booking, that the physician is permitted to treat that patient. Cabot builds that proof into the architecture rather than bolting it on, uses AI where it removes manual work that would otherwise cap growth, and keeps the MVP small enough to answer the question the business actually needs answered.

Discovery settles the scope, the architecture, and the numbers in six to eight weeks. Seven sprints take it live. What comes after that is a decision made with real usage data, and it stays yours.