How We Quadrupled a HealthTech SaaS Team's Shipping Speed (Without Replacing Anyone)

When an Australian HealthTech SaaS company came to us in 2023, their engineering situation had reached a breaking point. They had two excellent engineers. They had strong product-market fit — GP clinics across New South Wales and Victoria were renewing at high rates and referring new clients. They had a backlog full of features that would meaningfully expand their addressable market.

What they didn't have was the capacity to ship any of it.

The Problem: Two Engineers, Everything On Their Plate

Their two in-house engineers were responsible for everything: new feature development, bug fixes, infrastructure maintenance, customer support escalations, and security patches. Sprint after sprint, the team would commit to a set of deliverables, get three-quarters of the way through, and then be pulled off-course by a production incident or a health regulator compliance requirement.

Sprint completion rate: approximately 65%. Not because the engineers weren't working hard — they were working too hard — but because the team was simultaneously responsible for running the system and improving it.

The CI/CD pipeline was essentially non-existent. Deployments happened manually, required a specific engineer to execute them (key-person dependency risk), and had no automated testing gate before code reached production. In a regulated health context where downtime or data errors have direct patient-care implications, this was a serious liability.

There was also architectural drift. Two years of urgency-driven development had accumulated meaningful technical debt: inconsistent API patterns, duplicated business logic, and a Flutter mobile app that had diverged from the web platform's data model in ways that required manual workarounds to keep in sync.

What We Did in the First Four Weeks

Our CTO Srijith reviewed the codebase and identified the highest-impact intervention: before adding feature development capacity, fix the deployment pipeline.

This is an uncomfortable recommendation to make because clients want to see new features shipping, not engineers working on infrastructure. But it's almost always the right call. A team with no automated testing and a manual deployment process will accumulate production incidents as it scales — and every production incident eats the engineering time that should be going into the product.

The first four weeks were spent entirely on foundational work:

• Setting up a proper CI/CD pipeline on Azure DevOps — code merged to main triggers a build, runs the test suite, deploys to staging, requires a manual promotion step to production
• Writing a test harness for the critical billing and appointment modules (the two highest-risk areas of the platform)
• Establishing a shared architectural decision record so the entire team was building in the same direction

From month two onwards, we operated as a fully integrated pod alongside the in-house team: two senior .NET Core backend engineers, one React engineer, and a Flutter specialist to close the mobile/web data model gap. All engineers participated in the same sprint ceremonies — daily standups at the IST/AEST overlap, weekly sprint reviews, bi-weekly retrospectives.

The Results That Followed

Release frequency went from roughly one deployment per month to weekly releases within four months of the engagement starting.

Bug escape rate — the number of production bugs per deployment — fell by 50% once the CI/CD pipeline and test coverage were in place. The billing module alone got 200+ unit and integration tests written against it, reducing the error rate in that module by more than 60%.

Sprint completion rate went from 65% to 92% over the first six months. The team grew from two engineers to twelve (two in-house plus ten from Squash Apps across backend, frontend, mobile, QA, and infrastructure) without any of the communication overhead that typically accompanies rapid team growth.

The engagement also unlocked a commercial outcome the client had been working toward for a year: a hospital network partnership that required FHIR compliance and demonstrated engineering maturity. We built a FHIR R4 adapter layer on top of the existing data model — protecting the stability of the core product while opening the integration pathway — and the client's sales team had credible technical answers for the enterprise procurement due diligence. The partnership was signed.

What This Engagement Taught Us

The mistake most scaling SaaS companies make is treating staff augmentation as a headcount problem: add engineers, ship more features. But headcount alone doesn't fix a team that's stuck at 65% sprint completion. What fixed it here was a sequenced intervention: fix the foundation, then scale the team, then accelerate the roadmap.

The two in-house engineers were capable and committed. They didn't need to be replaced — they needed infrastructure that let them work at the level they were capable of, and a team around them that could run multiple product tracks simultaneously without creating coordination chaos.

Eighteen months in, the engagement is ongoing. The client secured their hospital network partnership and has used it as a proof point to accelerate sales with other enterprise healthcare clients. The engineering team is now running three simultaneous product tracks with weekly release cadence maintained consistently.

"They rebuilt our engineering foundation while simultaneously shipping product. I've never seen an offshore team integrate this cleanly with an in-house engineer — it felt like one team, not two." — CTO, Confidential HealthTech SaaS, Australia

If your SaaS team is hitting a similar ceiling — strong product, strong market fit, but engineering capacity that can't keep up with the roadmap — book a 15-minute call. We'll tell you honestly whether a pod would help and what the right structure would be for your specific situation.