Client background
The client is an Australian HealthTech SaaS company building clinic management and patient records software for independent medical practices. Their platform handles appointment scheduling, clinical notes, billing integration, and secure patient communication — the kind of software that needs to be reliable enough that a doctor can depend on it every single day without exception.
By the time they approached Squash Apps, the product had been in market for two years and had found strong product-market fit with independent GP clinics across New South Wales and Victoria. Renewals were high, inbound demand was growing, and the product roadmap was backlogged with features that would meaningfully expand their total addressable market. There was only one problem: the engineering team couldn't keep up.
Their two in-house engineers were technically strong but were responsible for everything — new feature development, bug fixes, infrastructure maintenance, customer support escalations, and security patches. The founders had tried to hire additional engineers locally but found the Sydney talent market too slow and too expensive for a Series A company watching burn rate carefully.
The challenge
The core problem was a dangerous imbalance between product ambition and engineering capacity. The two in-house engineers were talented but completely overwhelmed. 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 production incidents, customer escalations, or compliance requirements from health regulators.
The result was a feature backlog that kept growing instead of shrinking. Product managers and founders were spending an increasing share of their time managing client expectations for delayed features rather than doing the forward-looking work that would accelerate growth. Worse, the unpredictability of releases was eroding confidence internally: investors wanted to see a disciplined shipping cadence, and the team couldn't deliver one.
From a technical standpoint, the CI/CD pipeline was effectively non-existent. Deployments happened manually, required a specific engineer to execute them (creating key-person dependency risk), and had no automated testing gate before code reached production. This meant that bugs which could have been caught in a staging environment were regularly reaching live clinics — a serious problem in a regulated health context where downtime or data errors have direct patient-care implications.
There was also an architectural drift problem. Two years of urgency-driven development had accumulated meaningful technical debt: inconsistent API patterns, duplicated business logic, and a mobile app (Flutter) that had diverged from the web platform's data model in ways that required manual workarounds to keep in sync.
How we engaged
Squash Apps was brought in initially for a scoped 3-month engagement to augment the core team. After reviewing the codebase and interviewing the two in-house engineers, our CTO Srijith identified the highest-impact intervention: before adding feature development capacity, we needed to fix the deployment pipeline and establish quality gates.
The first four weeks were spent entirely on foundational work: setting up a proper CI/CD pipeline on Azure DevOps, writing a test harness for the critical billing and appointment modules, and establishing a shared architectural decision record so that the entire team — including the incoming Squash Apps engineers — was building in the same direction.
From month two onwards, we operated as a fully integrated pod alongside the in-house team. Two senior Squash Apps backend engineers joined the existing .NET Core API work, one React engineer took ownership of the web frontend, and a Flutter specialist was brought in to close the mobile/web data model gap. All engineers participated in the same sprint ceremonies: daily standups (IST/AEST overlap), weekly sprint reviews, and bi-weekly retrospectives.
Srijith personally attended the first three sprint reviews to ensure the delivery culture was calibrated correctly from the start. The engagement was structured to give the client complete visibility: all work was tracked in Azure DevOps, code reviews were conducted openly in GitHub with in-line comments, and the Squash Apps PM provided a written weekly status update to the founders every Friday afternoon.
What we built
The most consequential early deliverable was the CI/CD rebuild. We replaced the manual deployment process with a fully automated pipeline: code merged to the main branch triggered a build, ran the test suite, deployed to a staging environment, and required a manual promotion step to production. This single change eliminated an entire class of production incidents — the ones caused by untested code reaching live systems.
Alongside the infrastructure work, we delivered a comprehensive test suite for the billing module. This was the highest-risk area of the platform: incorrect billing calculations had the potential to create regulatory problems and destroy client trust. We wrote 200+ unit and integration tests covering every billing scenario the product supported, reducing the error rate in that module by more than 60% within two months of coverage being in place.
On the product side, the team shipped a full redesign of the appointment scheduling interface — the most-used part of the platform — migrating it from an older jQuery-based implementation to a modern React component architecture. This unlocked significant UX improvements that had previously been blocked by the technical constraints of the legacy code.
The Flutter mobile app received a substantial rebuild that aligned its data layer with the web API, eliminating the sync workarounds that had been consuming engineering time for over a year. Clinicians using the mobile app to access patient records on tablets could now rely on real-time data consistency with the web platform.
Over the 18-month engagement, the pod shipped 47 distinct product features, resolved 230+ bug tickets, and completed a full SOC 2 Type I readiness assessment — a requirement the client needed to meet for a major hospital network partnership they were pursuing.
Technical approach
The platform is built on .NET Core for the API layer, with a React web frontend and Flutter mobile client. Data is stored in Azure SQL Database with Azure Blob Storage for clinical document and image management. The entire infrastructure runs on Azure App Service with Azure Front Door for CDN and DDoS protection.
One of the more technically interesting challenges was the FHIR compliance work we undertook for the hospital network integration. FHIR (Fast Healthcare Interoperability Resources) is the international standard for healthcare data exchange, and implementing a compliant FHIR API endpoint on top of the existing data model required careful schema mapping and a new versioning strategy for clinical records. We built a FHIR R4 adapter layer that translated internal data structures to the standard format without requiring changes to the core application schema — protecting the stability of the existing product while opening the integration pathway.
On the frontend, we introduced a component library based on Radix UI primitives with a healthcare-specific design system on top. This gave the product team the ability to build new screens much faster and ensured visual consistency across a product that had previously accumulated significant UI debt from different engineers working in different styles.
Results
The outcomes were measurable and significant. Release frequency increased 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 established.
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 sprint completion rate — the percentage of sprint-committed work that actually shipped — rose from approximately 65% to 92% over the first six months.
Most importantly, the client secured the hospital network partnership they had been working toward, citing their new FHIR compliance capability and demonstrated engineering maturity as key factors in the procurement decision. The partnership represented a significant revenue milestone for the company and validated the investment in technical foundations. The ability to point to a clean deployment pipeline, comprehensive test coverage, and a FHIR-compliant integration layer gave the client's sales team credible answers to the technical due diligence questions that enterprise healthcare procurement teams ask.
This engagement is a reference case for what software development staff augmentation can deliver for a scaling HealthTech SaaS company: not just additional engineering headcount, but the architectural leadership, DevOps discipline, and mobile development depth that a two-person team cannot provide internally. The combination of CI/CD modernisation, automated testing, and FHIR compliance work delivered outcomes across three different dimensions — operational velocity, product quality, and enterprise sales capability — that justified the investment many times over. For Australian HealthTech companies building clinical software, practice management platforms, or patient engagement tools, this engagement demonstrates how the right engineering partner accelerates both the product roadmap and the commercial outcomes that depend on it.