Healthcare · B2B SaaS
Legacy desktop app to cloud-native SaaS — zero data loss
Replaced a Microsoft Access / VB desktop product with a NestJS + PostgreSQL + Next.js SaaS. Built a B2B API distribution channel, Stripe billing, and clinical-grade governance.
Domain: Healthcare / Veterinary Pharmacy / B2B SaaS Engagement: Fixed Fee with T&M overage provision Duration: ~11 months (16 weeks active development + 7 months production support) Team Size: Architect, Project Manager, Senior & Junior Full-Stack Engineers Client Location: United States
The client operates a long-standing pharmaceutical reference product used by veterinary medicine professionals to support safe and effective prescribing. The existing platform was a legacy Microsoft Access / Visual Basic desktop application with roughly 600 active clinical users. An earlier attempt at a cloud rebuild existed but had never gained traction with users — a common failure mode when domain knowledge lives implicitly in legacy code and doesn't survive translation.
The business needed to:
The project was structured as a rebuild, but the real engineering problem was a migration of institutional knowledge — and the failed prior cloud attempt was a visible reminder of what happens when that's underestimated.
A ground-up cloud platform on an enterprise-grade stack, migrating all critical data from the legacy Access database, with a B2B API layer, an administrative panel, a reference portal, and a self-service partner portal — plus a sync channel back to the legacy desktop client to support users who aren't ready to migrate.
To support users who are not yet ready to migrate off the desktop app, the cloud admin can export updated drug and clinical data in a format compatible with the legacy desktop application (.mdb / .csv). Legacy users receive the package via email or download link and import it into their desktop client. Cloud and legacy users operate on the same authoritative dataset throughout the transition — the cloud is the single source of truth even for users who haven't switched to it.
The hardest problem on this engagement wasn't building the APIs — it was ensuring that dosage calculations and drug interaction rules in the new system produced identical results to the ones clinicians had relied on for years. A near-miss would be worse than a total failure: silent output drift in a clinical reference product is exactly the kind of thing that erodes trust irreversibly.
The approach:
This is slower than "just rewrite it" but it is the only approach that produces a system a clinician will trust.
Access databases accumulate a particular kind of pathology: duplicated data across tables, implicit relationships that exist only in the UI code, columns whose meaning changed over time. Translating that into a clean relational PostgreSQL schema required deciding — for every table — what was essential relationship, what was denormalization for editing ergonomics, and what was accidental. Enforced foreign keys, check constraints, and properly-typed columns replaced a decade of "please enter a valid date" comments on a text field. The schema is the first place where the migration made the data better than it was, not just portable.
Clinical data changes don't just need an audit log — they need time-travel. Historical prescribing decisions that referenced a drug record need to be interpretable against the version of that record they saw, not whatever it looks like today. The governance model is:
current version and a history via temporal audit tables populated by triggersdraft state and are invisible to end users until explicitly approved by an authorized reviewerB2B partners ship products that embed this data. Breaking their integrations breaks their product — which breaks our trust with them. API versioning is explicit (URL-scoped), deprecation windows are communicated in both the response headers and the partner portal, and breaking changes are never shipped inside a minor version. The API's public contract is a first-class artifact — not whatever the code currently happens to do.
Webhook delivery to partners is a system that will fail — their endpoints will go down, their TLS certs will expire, their IPs will change. The delivery pipeline is built around that reality:
The two-way compatibility story is frequently done wrong — teams allow legacy clients to continue writing and then spend the project fighting sync conflicts. We designed from day one with the cloud as the single system of record; legacy is strictly a read-only subscriber consuming periodic data packages. There is one authoritative dataset, versioned and audited; legacy users get slightly older snapshots of it until they migrate.
The engagement runs as a fixed-fee project with a production-support tail:
| Layer | Technology |
|---|---|
| Backend / API | NestJS (Node.js), TypeScript |
| Database | PostgreSQL (relational, with temporal audit tables) |
| Frontend | Next.js, React, Tailwind CSS |
| Authentication | JWT (admin/UI), API keys (B2B partners) |
| Billing | Stripe (subscriptions + webhooks) |
| AWS SES | |
| Infrastructure | AWS (ECS/EC2, RDS, S3, CloudFront, Route 53, ACM, CloudWatch) |
| DevOps | Docker, GitHub Actions, staging + production environments |
| API Documentation | OpenAPI / Swagger |
| Validation | Parallel-run harness + golden-file regression suite against legacy outputs |
| Legacy Source | Microsoft Access / Visual Basic |
Replacing a mature, domain-heavy legacy application is not a rewrite project — it is a migration of institutional knowledge, and the failure mode most rebuilds run into is underestimating that. The hardest parts of this engagement were not the APIs or Stripe integration; they were extracting dosage and interaction logic from a decades-old Access database and an abandoned cloud attempt, proving the new system produced byte-identical results to the one veterinarians already trusted, and designing governance that keeps clinical data auditable going forward. The combination of schema reconciliation, parallel-run validation, draft-approve governance, cloud-to-legacy sync, and a partner-ready API layer gave the client both a modern SaaS product and a new distribution channel — without asking 600 clinical users to take a leap of faith.
More recent work
Healthcare · Patient management
A six-app healthcare ecosystem — the product our client took to Shark Tank
Patient app, resident web, staff portal, admin dashboard, shared SDK, and an AI emergency dispatcher — all sharing a single backend with role-isolated access. Built for a healthcare startup that was later featured on Shark Tank with the product we delivered.
Read the case study
Transportation · Smart city
Multi-modal routing and cashless ticketing for public transit
Proprietary IP we built and productised — launched on the App Store and Play Store. 150+ APIs, dynamic fare engine, real-time vehicle tracking, ONDC-certified, and a voice AI for 250+ metro stations.
Read the case study
Tell us what you're trying to build. Discovery calls this week, scope within 3 business days.