Where the suite ends.
HealthTech software development.
Three developers spent eight months on a multi-tenant donation platform for a blood-donation operator, and five spent two years rebuilding a veterinary M&A platform while the inherited system kept serving real users and payments. One replaced a fragmented set of tools, the other took over codebases earlier vendors left unfinished, and in both, healthcare software development came down to which record may be seen, by whom, and when.
Which part of a health platform is worth building?
Most sites run perfectly well on a packaged practice or patient suite, and the vendor carries the upkeep. What makes healthtech software development worth commissioning is sharp rather than gradual: the point where a configuration mistake stops being a cosmetic bug and becomes a data exposure, because a query that forgets its tenant filter returns another organization's records.
Healthtech software development is also where data protection stops being a setting. On the platforms below it is a set of mechanisms in the code, named row by row in the table.
The suite stops at the data-access layer
Each row starts with something a packaged health suite genuinely does well. The second column is what a blood-donation operator or a veterinary M&A company asked us to build when the suite did not reach far enough, and the third names which platform it came from.
| What a packaged tool handles | What a client asked us to build instead | Where we built it |
|---|---|---|
| What a packaged tool handlesRole-based access in a packaged suite. | What a client asked us to build insteadTenant scoping enforced at the data-access layer, so a query that forgets its tenant filter fails safe instead of returning another organization's records. | Where we built itThe donation platform |
| What a packaged tool handlesEncryption at rest and in transit, with the vendor rotating the keys. | What a client asked us to build insteadPersonal data kept out of application logs, URL query strings, error responses, cache keys and payloads sent to outside services. | Where we built itThe donation platform |
| What a packaged tool handlesSigned links to a record. | What a client asked us to build insteadSigned, expiring, tenant-scoped tokens instead of record IDs, so a link cannot be altered to reach someone else's record. | Where we built itThe donation platform |
| What a packaged tool handlesA CRM pipeline with named stages. | What a client asked us to build insteadA practice sale as an explicit timeline of stages with dependencies, where who may see what, and when, is data the system enforces: anonymized teaser, expressions of interest, staged confidentiality agreements, data room, letters of intent, signing. | Where we built itThe veterinary platform |
| What a packaged tool handlesA payments integration. | What a client asked us to build insteadAn append-only ledger of more than sixty transaction types; a charge stays pending until the webhook confirms it, and failures revert automatically. | Where we built itThe veterinary platform |
Three developers, eight months, several organizations on one system
Donation platform for a blood-donation operator
3 developers, 8 months
Three developers had eight months to replace a blood-donation operator's booking and donor-management tools with one platform for two audiences: donors booking their own visits, and staff running the centers. Several organizations share the system, and donor records hold identity, contact details, dates of birth, eligibility and screening notes.
Sites differ in capacity rules, closures and recurring schedules. Flattening those rules would have made the platform easier to build and useless to operate, so scheduling follows how each site runs, and capacity is counted the same way whether a visit is booked on site, online or assisted.
Underneath is one .NET API with Entity Framework Core and PostgreSQL on AWS, behind a Next.js portal and a staff back office. Tenant scoping is applied by default at the data-access layer, and automated checks in the build catch a missing filter before it reaches a shared environment. Every write to a sensitive record carries its audit entry in the same transaction, and production data never reaches a test environment.
The veterinary platform was rebuilt while it ran
Delivered for a client
Veterinary M&A marketplace and practice platform
Five developers spent two years rebuilding a US veterinary M&A company's platform from the inside, while the inherited core kept serving live traffic and real payments.
New capability went in as self-contained vertical-slice modules, accounts moved to AWS Cognito, and every feature branch deployed to its own demo environment with migrations applied ahead of the deploy.
Valuation reports are guarded by pixel-comparison tests in the build, so a layout regression cannot corrupt a document an owner will act on.
Four reasons to keep the suite you have
- Your suite's roles and booking rules already fit.
- Then configure it. Healthtech software development earns its cost where sites differ in ways the suite cannot express, or where one organization's data must never be reachable from another's.
- Your software diagnoses or doses.
- Clinical software of that kind carries its own certification path, and nothing on this page went through one. Look for a vendor with a certified product of that class in its record.
- You want production data in test environments to save time.
- On the donation platform, test datasets are generated, seeded deterministically and reloaded on every environment, and no personal data goes to a third-party service, our own AI tooling included, without recorded sign-off. If that rule is a blocker, we are the wrong team.
- You plan a big-bang cutover on a fixed date.
- The veterinary platform was replaced in slices while real payments ran through it, because neither a rewrite nor a freeze was an option. If the plan is to switch everything over one weekend, we would plan it in slices instead.
Asked before a health project starts
Which platforms has CQUELLE delivered in health and veterinary care?
How do you keep one organization's records away from another's?
Which data-protection rules do you build against?
Can you rebuild a platform while it keeps taking payments?
What runs underneath the two platforms?
Which of your sites' rules would a suite refuse?
Which of your sites could the suite not describe, and what did your staff do about it? That is the whole agenda for thirty minutes with the founder, and you leave with what to configure and what healthtech software development would have to cover, in that order. Often enough the answer is the suite you already own, configured properly.
Or describe it in the form, and expect a reply inside 48 hours.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.