Regulated markets

MVP Development for Healthtech Startups

I built SYNCHFIT, an AI fitness product, which put me in the space where health data, machine learning, and consumer expectations collide. Healthtech is the market where the decisions made in build week one are the hardest to reverse in year two.

The pattern I see: a team ships fast, wins a pilot with a provider or an employer, then discovers PHI is scattered across six vendors with no audit trail and no BAA anywhere. Unwinding that costs more than building it correctly did. In an MVP the correct version is only marginally more work, because the surface is still small.

Book a 30-min call See pricing Contact Me

How the build runs

What is different about scoping a healthtech MVP

The PHI boundary gets drawn in the scoping week, not later

Before a screen is designed I map which fields are PHI and which systems are allowed to see them. That single diagram decides your analytics tooling, your error tracker, your logging, and whether an LLM can touch the data at all. Drawing it takes an afternoon at MVP stage and is a migration project once you have live patient data.

Audit logging is designed in, because bolting it on is brutal

HIPAA expects you to prove who accessed what. Building append-only, queryable access logging into an MVP is close to free because the data model is still forming. Adding it to a live system means backfilling history you do not have. This is the clearest example of MVP-stage decisions being worth real money later.

Every vendor in v1 has to be BAA-capable

I check this at selection time rather than at security-review time. Plenty of excellent tools cannot sign a BAA, and finding that out during your first health-system review costs you the deal. The MVP stack gets chosen against that constraint from the start, which occasionally means a less fashionable tool.

FHIR gets scoped to what closes the pilot, not the standard

Full interoperability is a large project and almost never belongs in a v1. I scope the narrow slice your first pilot actually requires, usually a handful of resource types, and structure it so the rest can be added without a rewrite. Building the whole standard for customers you do not have yet is the most common way healthtech MVPs run over.

If a model touches care, the failure mode is designed first

Not the model. What happens when it is wrong, who reviews it, what is logged, and how a clinician overrides it. Get that specified and the model choice becomes the easy part. It also gives you a defensible story when a partner asks, which they will.

Scope

What a v1 looks like here, specifically

Screen counts are a starting point, not a quote. The real number comes out of the scoping week, and it is almost always lower than the brief that walked in.

8 to 14 screens

Typical v1 for a healthtech product, scoped in the first week

Goes in v1

Auth with real role separation, usually patient, clinician, and admin
The core clinical or member workflow end to end
Append-only audit logging on every PHI read and write
An explicit PHI boundary, with BAA-capable vendors only
The narrow FHIR slice your first pilot requires, if any

Deliberately deferred

Full FHIR or HL7 coverage until a signed customer needs it
SOC 2 controls beyond the architectural ones, which come with the first enterprise deal
Patient messaging and scheduling unless they are the product
Native mobile before the web workflow is validated

What you're actually buying

Scoping, the build, and launch

Week 0

Scoping: every screen counted and priced

We go through everything you think the MVP needs, screen by screen, and cut it down to what actually has to exist to test the thing you're testing. Every remaining screen gets counted and priced at $80, across whichever platform it needs — mobile, web, desktop, or Linux. You leave with a scope doc and a total, not an estimate that moves once we start.

The build

Design and development, with you seeing it every week

My Panicle Tech design and engineering team builds it, screen by screen; I own the architecture, the code review, and the calls that are expensive to get wrong. You get a working build to look at every week, not a status update. If a screen turns out to need more than was scoped once it's half-built, that gets priced honestly before it's fully built, never absorbed silently.

Launch

Handover, and two weeks of me still answering the phone

Deployed, monitored, and documented well enough that the next engineer who touches it isn't guessing. Two weeks of post-launch support are included, because the bugs that matter are the ones your first real users find, not the ones QA finds.

Why me, for this market specifically

Experience, not a capabilities deck

Plenty of teams can build screens. Fewer have shipped for Healthtech specifically, been wrong about it, and had to fix it with their own name on the commit. Here's what I'm bringing.

Built SYNCHFIT, an AI-driven fitness and health product
M.Tech in Cybersecurity: access control and data protection are the core discipline
Experience taking regulated products through enterprise security review
Full-stack: I write the code, not just the policy document

Pricing

from $80 a screen. Counted up front.

Design and build, screen by screen, across mobile, web, desktop, and Linux. My Panicle Tech team designs and builds it; I own the architecture and the technical decisions as advisor on the project. Added screens are priced at the same rate, never renegotiated after the fact.

MVP Design & Development

from $80

per screen

Scoping week: every screen counted and priced up front
UI/UX design and full-stack development, screen by screen
Built by my Panicle Tech design and engineering team
I own the architecture, code review, and technical direction
Mobile, web, desktop, and Linux apps, whichever the product needs
Deployment, monitoring, and handover documentation
Two weeks of post-launch support
Added screens priced at the same per-screen rate, never renegotiated after the fact
Option to continue on a fractional retainer

Full pricing and the scoping process →

Questions

Healthtech, specifically

Will the MVP be HIPAA compliant when you hand it over?

The architecture will be built correctly: PHI boundaries, audit logging, BAA-capable vendors, access control. Compliance itself is broader than software and includes policies, training, and agreements that a specialist firm handles. What I own is making sure the system they audit is actually built right, which is the part that is expensive to fix later.

Does the audit logging and access control inflate the screen count?

No, it is backend work and does not add screens. It does add a few days to the build and I show that as a separate line in the scope rather than folding it into the per-screen rate. In healthtech I treat it as non-optional, so it is quoted in every scope I send.

We have a pilot with a health system starting in three months. Is that enough time?

Usually yes for the build, and the scoping call is where we check honestly. The risk is rarely the engineering timeline, it is the security review running in parallel. I would rather scope a tighter v1 that passes review than a broader one that stalls in it.

Can we use an LLM on patient data in the MVP?

Sometimes, and it depends entirely on the vendor and the BAA. Some providers will sign, some will not, and the answer changes what is possible. I check this before it gets designed in rather than after, because discovering it late means redesigning the feature.

More general questions about pricing, timeline, and what's included are answered on the main MVP development page.

Earned, Not Claimed

What the founders and teams I build with say

I had the pleasure of working with Kunal while building out my MVP and I have to say that it was pleasure to both interact and work with him and his team. As a first time founder, I had a lot of self doubt and internal ruptures, however Kunal's calm, never-say-die and never-panic attitude often helped bring me back to center. I can't vouch for him enough.

Anand Tahiliani

Founder, Debaser Technologies

I had the pleasure of working closely with Kunal during my time as a Product Manager at DhunGuru. As our CTO, Kunal and his team at Panicle Tech worked closely with me across the entire product journey, from building and launching our mobile apps to developing and maintaining our web platforms. His technical expertise, ownership, and willingness to collaborate made a real difference, and I genuinely enjoyed working with him throughout the journey.

Anirudh Joshi

Product Manager, DhunGuru

Kunal helped us architect Mosler's core platform, connecting smart lock hardware, our cloud dashboard, and PMS integrations into one reliable system. The foundation he helped design in those early days still scales with us today.

Pranav Kapoor

Co-Founder, Mosler

If you need more than a build

Already have a product, not just an MVP?