Four codebases. One design. A few months.
We built the machine first.
MyPath.Care runs on a Go API and native applications for iOS, Android and web, all four built to production grade in parallel against a single design. The explanation isn't unusually fast engineers. We built a second piece of software first — over 100,000 lines of agent configuration, workflow orchestration, tooling and proprietary skills — and used it to build the product.
Software does not ship slowly because people are slow.
It ships slowly because the process leaves the expensive work to the end. Four failures do most of the damage, and every one of them is a process choice rather than a talent problem.
The design gets discovered by building
Decisions that should be settled once, up front, get made a file at a time. The expensive mistakes surface last, when they are most expensive to undo.
Review arrives when everyone is tired
The work is nearly done, the reviewer has a day job, and the incentive is to wave it through. Real problems get filed to a backlog nobody clears.
The documentation drifts on day one
Written by hand, out of date by the next commit, and rebuilt from memory when an auditor asks what the system actually does.
Platforms quietly stop matching
A capability lands on web, arrives late on iOS, and never lands on Android at all. Nobody notices until a customer does.
We built a machine that argues with itself.
Speed is only worth having if the result can be trusted, so most of the system is built to attack its own work before a person ever sees it. What reaches the human expert is a decision with the evidence already assembled.
One reviewer, one failure class
Independent reviewers read every plan in parallel. One looks only for access boundaries that fail to close. Another looks for state machines with undefined transitions.
Then the reviewers get refuted
A separate pass tries to break everything those reviewers produced, because a review that only accumulates concerns is worth very little.
It stops instead of guessing
The system applies a change where there is one defensible answer and stops where there is not. A build that halts on a real question beats one that goes green by guessing.
Verified on a dedicated machine fleet
Headless machines run nothing but this, around the clock, driving up to 24 simulators, emulators and browsers at once against high-volume test data. Blocked is never counted as a pass.
We build the world we test against, then break it on purpose.
A verification fleet is worth exactly as much as the conditions it can reach, and the conditions worth reaching are the awkward ones. So two pieces of purpose-built tooling sit under it, 13,000 lines of them, kept entirely outside the product: one founds a full care network from nothing, the other breaks the network underneath it.
One command founds a complete care network
Twenty organizations along the payer-to-network-to-provider chain, and every professional account, patient record and care order that hangs off them, with the messages, documents, calls and history attached.
Every agent gets its own copy, so eight drive at once without ever contending for a record, and every list pages, every search returns, and access boundaries get exercised at volume rather than against three rows.
The other one fails any route on command
The second tool sits between every client and the server and can fail or delay any route on demand. That is how the offline, error and retry paths get driven identically on iOS, Android and web, instead of being reasoned about once and hoped for.
A timeout stops being an incident somebody reproduces by accident six months after release and becomes an ordinary test case, run the same way on all three apps every time the fleet goes out.
It writes rows, not clicks
Founding the network directly in the database rather than acting out a user is what makes the awkward states reachable at all. Each of these is a routine fixture here, and none of them can be staged by clicking through the product. That is where defects hide, and a human tester almost never gets there.
Both refuse to touch any environment that is not on a declared test list, and they refuse before opening a connection. None of this removes human testers. It moves them up: the machine settles what is objectively broken and hands over a verified build, so people spend their whole budget on whether the product reads well, flows well and feels right.
Everything else arrives on a board the system works itself.
Features of consequence go through a specification. Everything else lands as a card on an ordinary Kanban board, the same one the human testers write to: a broken screen somebody photographed, a fix nobody has confirmed, a complaint that some flow is confusing. A person names a queue. The run loads it whole, decides which cards belong together, and drives everything it can to closed.
It reproduces before it reads any code
Every card is driven against the current build first. Only "could not reproduce it" retires work, and that alone has to prove the setup was genuinely established and the reported behavior was then absent.
It fixes where the cause is
Cards are sliced to the codebases whose code could actually cause them, which is frequently not the platform the tester happened to be holding. Broken uploads on all three apps is one server bug, not three client bugs.
It knows a defect from a decision
A card is authoritative that something looked wrong to a competent user. Behavior departing from settled product truth gets fixed without asking. A request for something new escalates every time.
The card comes back written up
A plain line for the tester on what to verify, plus the root cause from the agent that made the change, posted verbatim. A card that kicks back later does not start over from zero.
One run covers intake triage, defect reproduction, root cause analysis across four codebases, implementation, quality assurance on real devices, and stakeholder communication. That is most of what an IT department does, minus the product authority, which stays with a person on purpose.
We bet on the wrong database. We replaced it in five business days.
In the last week of June the system of record moved from a cloud document store to a fully relational one, AlloyDB for PostgreSQL. The authorization model, the search infrastructure, the real-time machinery, and the data access layer of four codebases moved with it.
We started on a document store for the reasons everyone starts on one. It looked more scalable, more extensible, and cheaper than a relational database, and it served the product's first year. Then the ceiling came into view. Document stores are poor at the searches and joins a coordination product needs more of every month. Every count and cross-reference has to be maintained by hand. And a permission change waited on a fresh sign-in token before it took effect.
Plan drafted Thursday afternoon. Merged, deployed and in front of QA the following Thursday morning.
The server and all three native apps moved in lockstep, because the contract between them changed shape.
Re-homed onto the new data layer, every one of them against a single reconciled server contract.
Across four repositories, including sixteen schema migrations in the server alone.
Found in the human smoke test, each fixed on every affected platform the same day.
It was only ever read. The change stayed reversible until the moment we accepted it.
Established engineering organizations schedule a year for this category of change and staff a team for it. More often they never schedule it at all, because a re-platforming touches everything and the safe-feeling choice is to keep living with the foundation you have. It was one of forty specifications the system has landed, and the cadence has not slowed as the product grew to 445,000 lines behind 240 endpoints.
A platform that keeps pace with your operation.
Four things we hold ourselves to, and each one is checkable. Two of them decide the argument: ownership is what separates this from a consultancy and from a coding assistant, and evidence is the whole case in a regulated field.