Why We Rebuilt from Scratch
RestartiX ran on Strapi — a popular open-source content management system used as a backend. It got us started quickly, but as the platform grew, the cracks became too significant to patch.
This page explains the business case for the rebuild and what changed.
What wasn't working
| Area | Before (Strapi) | After (RestartiX Platform) |
|---|---|---|
| Speed under load | Pages slowed down as more users connected simultaneously | Handles thousands of simultaneous users without degradation |
| Security risk | Built on a framework with a history of vulnerabilities and thousands of third-party packages | Built from scratch with minimal external code — smaller attack surface, easier to audit |
| Healthcare compliance | Difficult to prove to auditors that patient data was protected — hidden behaviors in the framework made it hard to trace what was happening | Every action is logged, every data access is traceable — audit-ready for GDPR from day one, with HIPAA readiness built in |
| Data isolation | One clinic's data could theoretically be exposed to another through framework gaps | Database-level walls between clinics — impossible for one clinic to see another's data, enforced by the database itself |
| Reliability | One bad or slow request could freeze the entire server | Requests are isolated — one slow operation never blocks others |
| Infrastructure cost | Required ~500MB per server instance — expensive to scale | ~20MB per instance — same budget supports 25× more capacity |
| Development speed | Changes were risky — hidden side effects meant bugs slipped through to production | Errors are caught before deployment — faster iteration with fewer regressions |
| Vendor independence | Locked into Strapi's roadmap and limitations | Built on Go — used by Uber, Cloudflare, Docker — large talent pool, no vendor lock-in |
Why not just upgrade Strapi?
Strapi's architecture means that compliance, performance, and isolation are fundamentally limited by how the framework works — not by configuration. Getting to healthcare compliance (GDPR, HIPAA) on Strapi would require fighting the framework at every step.
A from-scratch rebuild lets us:
- Design compliance in, not bolt it on
- Own every behavior — no black-box middleware, no auto-exposed routes
- Scale efficiently — the binary is 25× smaller and 10× faster to start
- Audit everything — every line of code is ours, every data path is explicit
What we kept
The rebuild is technical, not a product reset. Five years of domain knowledge — how clinics work, what specialists need, how patients behave — shaped every decision.
- All the business logic and workflows were preserved and improved
- Patient and clinic data will be migrated from the legacy system in a one-time operation
- The product experience improves, the operational foundation becomes solid
The key architectural decision
The previous system had two separate services: the main Strapi backend and a separate scheduling microservice (Intakes). Having two services meant:
- Duplicate authentication
- Data had to sync between two databases
- Bugs caused by the sync
- Two deployments to manage
We merged them into one. One codebase, one database, one deployment. The scheduling engine runs inside the same service as everything else. No sync bugs. No duplicate auth. No mapping layer.
Learn more
- System overview → — How the platform is structured
- Key technical decisions → — The reasoning behind Go, PostgreSQL, Clerk, and more