How HIPAA-compliant software gets built, the process behind Ocean

Most healthcare software projects don't fail on technology. They fail because compliance was treated as a launch checklist, or because the product optimized for the wrong outcome from day one.

I built Ocean , a HIPAA-regulated platform that matches patients with the right therapist, end to end as CTO. This is the process behind it, and the same process I bring to every healthcare and non-profit engagement. If you're evaluating a developer for software that touches sensitive data, this is what "done right" looks like from the inside.

Start from the clinical outcome, not the feature list

Before I was an engineer I was a social worker, and it changes the first question I ask on any project. What does a good outcome look like for the person on the other side of the screen?

For Ocean, a good outcome isn't "a match was made." It's a therapeutic relationship that holds. Decades of therapy-outcome research point at the alliance between patient and clinician as the thing that predicts whether treatment works, so that became what the software optimizes for, and every technical decision downstream had to serve it.

Treat HIPAA compliance as architecture, not paperwork

When software handles protected health information (PHI), HIPAA shapes the data model on day one, retrofitting it later costs multiples more. In Ocean, compliance is built into the code paths themselves.

• Column-level encryption on sensitive fields, and decryption failures fail closed, never open.
• An append-only audit trail written in the same database transaction as every read or write of patient data. The invariant is simple. PHI cannot leave the system without an audit row.
• Mandatory multi-factor authentication with passkeys for every user, patients and clinicians included, not just staff.
• A compliant AI boundary. Language-model calls run only on infrastructure covered by a Business Associate Agreement, request bodies are never logged, and background-job payloads carry identifiers, never health information.

None of this is visible in a product demo. All of it is what an auditor, an insurer, or a breach investigation will ask about.

Choose boring technology, and test the seams

Ocean runs on a deliberately unexciting stack. A Django REST API on PostgreSQL, a Next.js/TypeScript frontend, cloud-managed queues for background work. Mature technology means fast security patches, easy hiring, and a platform that's still maintainable in five years. Novelty is a cost, I spend it in exactly one place per project, the part that is genuinely the product.

The discipline lives in the tests. Hundreds on the backend, including tests that assert the compliance behaviors themselves, the fail-closed encryption, the no-PHI-in-reports rule, with deploys gated on the suite passing. When the architecture evolved, the heaviest testing landed on the seams the migration created, because that's where systems actually break.

Let evidence beat cleverness, even your own

The first version of Ocean's matching engine was the kind engineers love. Vector embeddings, linguistic-style similarity, weighted composite scores. Building it taught me the domain. Then the evidence taught me something uncomfortable: alliance quality is driven more by the clinician's skill, cultural humility, detecting and repairing ruptures, responsiveness to feedback, than by how similar a patient and clinician look on paper.

So the live system inverts the usual recommender design. Each clinician is scored once at onboarding on those alliance competencies. Matching then retrieves on hard requirements, licensure in the patient's state, insurance, availability, language , and a ranking pass blends that skill score with patient-specific fit, producing reasons a human can read rather than an opaque score. The embeddings didn't survive contact with the evidence. Deleting a clever system you built is painful. It's also the job.

What this means if you're hiring a developer

The process transfers to any organization whose software touches sensitive data, community health, behavioral health, case management, non-profit services.

• Define the human outcome before the feature list.
• Treat your regulatory reality as architecture, not a pre-launch task.
• Buy boring technology everywhere except the one place your product is genuinely novel.
• Demand that the novel part be explainable, in healthcare, a recommendation you can't explain is one you can't trust.

If you run a non-profit or a healthcare organization and this sounds like how you'd want your software built, tell me what you're working on. What it costs is no mystery either: my pricing and sliding scale are published, and the case study on turning years of spreadsheets into a client-facing analytics platform shows this process on a real build.