Building a healthcare marketplace in six weeks
194K data points, 12K locations, AI-powered price discovery, smart matching, and Stripe Connect — solo, in six weeks. Here's how.
I recently shipped a full-stack healthcare services marketplace — solo, in six weeks. Patients find providers, compare pricing with real confidence scores, and submit service requests through an AI-driven price discovery mechanism. The platform ingests 194K price data points across 12K provider locations, runs AI-powered search with pgvector embeddings, handles payments through Stripe Connect, and serves three distinct portals from a single Next.js codebase.
It was the most technically dense project I have built, and also the most fun. Here is how it came together.
194K data points, 12K locations, AI-powered price discovery, smart matching, and Stripe Connect — solo, in six weeks.
The data problem came first
Before writing a single React component, I spent serious time on financial modeling and due diligence.
The core value proposition of the marketplace is price transparency — patients should be able to compare what providers actually charge for the same service across thousands of locations. That means the data has to be trustworthy, and building trust in messy real-world pricing data is a genuinely hard problem.
I built a multi-source data ingestion pipeline to pull pricing information from every source I could find. Playwright-based web scrapers handled JavaScript-rendered provider directories. HTTP chain scrapers worked through paginated APIs. Structured imports consumed published fee schedules in CSV and Excel formats. For the messiest sources — PDFs, unstructured web pages, inconsistent spreadsheets — I built an AI extraction layer that could pull structured pricing from nearly anything.
All of this fed into a staged ingestion architecture: raw data lands in a staging table, runs through fuzzy matching to resolve provider identity across sources, surfaces for admin validation, and only then promotes to production. The pipeline had to handle deduplication, conflict resolution when two sources disagreed on a price, and confidence scoring so the frontend could communicate how reliable each data point was.
By the end I had 194K price data points across 12K provider locations — enough to build meaningful comparisons and enough variance to make the financial analysis genuinely interesting.
Financial modeling as a feature
What made this project exciting was the depth of quantitative analysis baked into the product itself.
I was not just building CRUD screens. I was analyzing provider economics — understanding pricing structures, modeling unit economics across different service categories, and building systems that could surface statistically meaningful comparisons to patients.
The confidence scoring system became central to the user experience. Each price comparison carries a confidence score derived from source freshness, cross-source agreement, and sample size. A price confirmed by three independent sources last month scores differently than a single self-reported figure from two years ago. This kind of due diligence on data accuracy is what separates a useful marketplace from a misleading one, and encoding that rigor into the product was deeply satisfying engineering work.
AI-powered search
Patients do not search the way databases think.
Someone types "I need a routine checkup near downtown" and the system needs to figure out which service category that maps to, what complexity tier it falls into, and which providers are relevant.
I built a complexity classifier with 27 regex patterns and 19 intent overrides that categorizes incoming queries before they hit the vector search layer. Synonym expansion handles the fact that patients and providers use different terminology for the same services. The whole thing runs on pgvector embeddings in Supabase's PostgreSQL, which keeps the infrastructure simple — no separate vector database to manage.
Three portals, one codebase
The application serves three distinct experiences from a single Next.js codebase.
A patient portal for searching and submitting service requests, a provider portal for managing profiles and responding to requests, and an admin portal for data validation, analytics, and platform management. All three live in a single Next.js 16 App Router codebase using route groups — (patient), (provider), (admin) — which keeps shared logic centralized while giving each portal its own layout and navigation.
Price discovery and payments
When a patient submits a service request, the platform's price discovery mechanism matches them with relevant providers and surfaces competitive pricing in real time.
The matching engine handles provider qualification, pricing validation, ranking by relevance and confidence, and time-based expiration. Once a patient selects a provider, Stripe Connect processes the payment using a capture-then-refund pattern — funds are authorized and captured, but the platform holds them through an inspection window so the patient can flag issues or cancel if needed. Providers receive payouts through connected Stripe accounts.
The stack
The full stack spans six major services, all coordinated from a single Next.js codebase.
Next.js 16 with App Router, Supabase for PostgreSQL, Auth, and Realtime subscriptions, Stripe Connect for marketplace payments, Google Maps for location search and provider mapping, pgvector for semantic search, and Tailwind CSS with shadcn/ui for the interface. Late in the build I did a mobile-responsive retrofit — not a native app, but every flow works cleanly on a phone.
What I learned
Six weeks is not a lot of time for a project this dense.
What made it possible was spending the first week entirely on data architecture and financial modeling before touching any UI. Understanding the shape of the data — how providers price services, where the variance lives, what makes a comparison trustworthy — informed every product decision downstream.
The combination of deep quantitative analysis and modern full-stack engineering is where I do my best work. Financial modeling, data pipelines, confidence scoring, real-time systems, payment flows — these threads all converge in a marketplace like this, and pulling them together into a coherent product in six weeks was the most rewarding build I have done.