The firm was running its operations on a sprawl of spreadsheets and a vendor tool whose maker had announced end-of-life with a twelve-month wind-down. The vendor's migration path was to a SaaS successor product that priced at four times the current contract and required the firm to send patient-identifying data to a third-party cloud. The firm's engineering team — three people, all senior, all already at capacity — could see the build that needed to happen but could not get clear of operational work long enough to start it. Karakor was brought in to deliver the platform end-to-end while the in-house team kept the lights on, with the engineering lead in the design conversation throughout.
SOFTWARE · INTERNAL TOOLING
A greenfield internal platform that shipped on time
A five-month build for a regional healthcare-services firm: replacing a sprawl of spreadsheets and a deprecated vendor tool with an internal operations platform the firm's engineering team now owns end-to-end.
- Client
- Regional healthcare-services firm, ~250 employees, two markets, US.
- Duration
- Five months
- Practice
- Software & Private AI
Results
5 monthsDiscovery to production, with weekly written updates throughout
2Feature additions the in-house team has shipped since handoff, without Karakor
0 bytesPatient-identifying data that left the firm's network boundary during or after the build
4× → 0Vendor price increase avoided by building rather than migrating
- Threat model and architecture document, signed by the engineering lead before any code was written
- End-to-end build: data model, API, web front-end, identity and access, audit logging, deployment pipeline
- Migration tooling — one-shot import from the deprecated vendor and the spreadsheet sources, validated against a sample by the firm's operations team
- A reference architecture document that names every operational decision a future engineer will ask about
- Three operator runbooks covering deployment, incident response, and data export
Weeks 1–2 were discovery and the design document, agreed with the engineering lead in writing. Months 1–4 were the build — weekly written updates to the engineering lead, fortnightly demos to the operations team, production-quality code with tests from week one. Month five was the migration weekend and the handoff: the operations team migrated to the new platform on a Saturday, with Karakor and the engineering lead in a shared room watching the import logs. The handoff session ran six hours; a follow-up working session ran four. The codebase is in the firm's own repositories. There is no Karakor-hosted infrastructure in the path.
The platform has been in production for six months. The firm's engineering team has shipped two feature additions since handoff without Karakor's involvement — the test was whether the codebase was readable enough that the in-house team could extend it, and the answer was yes. The firm avoided the vendor's SaaS migration entirely; patient-identifying data has remained inside the firm's network boundary throughout. The engineering lead has used the reference architecture document twice to onboard contractors without Karakor in the conversation.
The handoff is the test of a build. Code your client can read and extend is worth more than code that is more clever and only you understand. Karakor wrote the same code we would have wanted to inherit.
Short excerpts representative of the actual documents shipped in this engagement. Anonymised to preserve client confidentiality; faithful to the structure and substance of what we delivered.
Data model: matter-centric, not patient-centric. Every record is anchored to an operational matter (intake, case, billing cycle). Patient identifiers are stored once, in one table, accessed through one query path, with one audit log. Every other table references the patient through an opaque internal identifier. This is the property that makes the audit trail tractable.
Deploy is a single command run from the engineering lead's workstation. The command runs migrations against the production database, then promotes the new container image. There is no rollback button because there does not need to be one — the migration is reviewed and rehearsed in staging before it runs in production. If the deploy fails, the previous container is still running. Restart the previous container. That is the rollback.
Question from the engineering lead: "Why did you split the audit log out of the main database?" Answer recorded in the reference architecture: because the audit log is read-rarely, written-always, and must outlive the operational database in retention. Separating it at this stage costs almost nothing and saves a future migration. The lead agreed and asked us to write the reasoning down. The reasoning is on page 14 of the reference architecture.
ContinueAll 05 →
CYBERSECURITY · ASSESSMENTA written security posture before procurement askedA six-week NIST CSF-scoped assessment for a mid-market services firm fielding enterprise security questionnaires faster than its IT lead could answer them.SOFTWARE · PRIVATE AIA private-AI deployment a partner can defendA four-month build for a healthcare-adjacent organisation: on-premises model deployment with matter-aware retrieval, audit logging, and a runbook the in-house IT lead operates unattended.
Engage
We respond within two business days. Scoping calls are obligation-free and run thirty minutes.
