A Project That Would Not Build and a Team That Was Gone
A small clinic running a structured weight management program had invested in a custom mobile app. The idea was straightforward: patients would log weight, food, and activity on their phones, and that data would flow into Epic so clinicians could track progress without managing a separate system.
The development team they had hired did not finish the job. When the engagement ended, the clinic was left with a codebase that would not build, a source code handover that was incomplete, and an Epic integration that existed only in partial form. The product was pre-beta. Nothing was ready to put in front of a patient.
They needed someone to come in, make sense of what existed, and get the thing finished. That is what Sequoia was brought in to do.
Salvaging What Was There and Rebuilding What Was Not
Sequoia Applied Technologies is a Santa Clara software engineering firm that builds and rescues software products for technology companies across life sciences, healthcare, and enterprise software. This was a salvage engagement from day one.
The first task was forensic. Before any development work could happen, the team had to understand what the handover actually contained: which files were present, what the application was supposed to do, what was broken, and what was simply missing. The codebase would not build in the state it arrived, so reconstructing a working build environment was the precondition for everything else.
Once the project was buildable, the team could assess what the prior work had actually produced and where the gaps were. The Epic integration was one of the larger gaps. It existed in partial form but was not functional end to end. Sequoia completed it using approved API contracts with token-based authentication and scoped data access, and added reconciliation logic and alerting for failed syncs so data reaching Epic could be trusted.
The mobile app itself needed significant work. Multiple crashes were fixed, including a photo crash and issues with exercise and weight plotting. Code was refactored where the original structure made ongoing development untenable. Features including dynamic graph scaling, bio age tracking, daily save alerts, and push notifications were completed or corrected. The app was then tested across a range of Android and iOS devices, with validation on multiple hardware models to confirm stability before release.
The backend and infrastructure followed a clear architecture once the build was stable. Python and Django handled the server-side logic. PostgreSQL stored patient and clinical data. Apache served the application on Debian Linux running on AWS EC2, with separate staging and production instances so testing never touched real patient records. AWS SES handled email delivery. Scheduled jobs ran nightly alerts for the care team.
What the Stack Looked Like Once It Was Working
The system ran across three layers: the mobile app, the backend services, and the Epic integration. Each had distinct ownership within the codebase, which mattered for a rescue project where parts arrived in different states of completeness.
Patient-facing app for weight logs, food entries, activity tracking, daily goals, and reminders. Tested across a range of Android and iOS devices and hardware models. Multiple crashes were fixed during the rebuild, including photo handling and exercise and weight plotting. Dynamic graph scaling and push notifications were completed.
Python and Django for server-side logic, PostgreSQL for data storage, Apache with mod_wsgi as the web server, running on Debian Linux on AWS EC2. Role-based access, audit logging, and scheduled cron jobs for nightly care team alerts. Separate staging and production environments on AWS from the start.
Completed a partial integration using approved API contracts, token-based authentication, and scoped data access. Added reconciliation logic and alerting for failed syncs so the care team could rely on what they saw in Epic. The integration runs server-side, not through the app directly, so it can be monitored and retried independently.
EC2 instances for production and staging, AWS SES for email delivery, and snapshot-based backups for recovery. The environment separation meant the team could test against a realistic environment without any risk to production data or to the real Epic connection.
For smaller clinics considering Epic integration: the approved API framework this integration used is not restricted to large hospital systems. Clinics that access Epic through affiliated networks or hosted arrangements can use the same approach. The engineering does not change based on the organisation's size.
Common Questions About Healthcare App Rescue and Epic Integration
Can you take over a healthcare app that a previous developer abandoned?
Yes. Sequoia Applied Technologies has done this. The starting point here was a pre-beta Python and Django codebase that would not build, with incomplete source code and a partial Epic integration. The team assessed what was recoverable, rebuilt the missing pieces, and brought the product to a working state on iOS and Android.
How do you approach a project with missing or incomplete source code?
The first step is understanding what actually exists. That means examining every file in the handover, working out what the application was meant to do, identifying what is broken or absent, and deciding what can be salvaged versus rebuilt. For a project that will not build at all, the build environment itself has to be reconstructed before any other work is tractable.
What does completing a partial Epic EHR integration involve?
It depends on how far the prior work went. In this case the integration existed in partial form. Sequoia completed it using approved API contracts with token-based authentication and scoped data access, and added reconciliation and alerting for failed syncs so the care team could trust the data provenance in Epic.
What tech stack did Sequoia use for this healthcare app?
Python and Django for the backend, PostgreSQL for the database, Apache as the web server on Debian Linux, and AWS for hosting including EC2 for production and staging and SES for email. The mobile app ran on iOS and Android, tested across a range of devices and hardware models.
What kind of companies does Sequoia Applied Technologies work with?
Sequoia Applied Technologies is a Santa Clara, California software engineering firm that works with product companies across life sciences, healthcare, cleantech, enterprise software, and IoT. Engagements include new product builds, rescue and salvage of abandoned projects, EHR integration, and production delivery.