An Australian healthcare platform

Stuck in development for 8 months with no clear deadline in sight.

Grail took over from the previous vendor, rebuilt the platform and had it live in production within 30 days. By day 40, 100 business customers had been onboarded.

Before Grail: Stuck in development for 8 months with no clear deadline in sight
Grail rebuild: Live in production within 30 days
Early rollout: 100 business customers onboarded by day 40

The problem

A slow vendor and unstable software had left the company unable to launch

The company had spent 8 months building the platform with another vendor, but it was still incomplete and unstable. Even a small bug fix could take days or a week, and fixing one problem often broke something else. With no reliable launch date, the company could not go to market.

The company chose Grail as its technology partner to take over the entire build. We became responsible for the product, codebase, infrastructure, testing and production, giving the company one team accountable for getting the platform live and keeping it working.

01 · The audit

We audited the inherited platform before choosing what to keep

We started with the code, data, infrastructure and product documents the previous vendor left behind. The goal was to understand what worked, what the company still needed and whether the existing platform could be made dependable.

The audit covered three separate codebases and 32 .NET projects. We mapped how the parts connected, followed 13 areas of the product from start to finish and checked how safely a new team could change and run them.

How we audited it

01Map the whole platform
We traced the core platform, onboarding system and custom sign-in service, including the data and outside tools each one used.
02Reconstruct how it worked
We followed the important journeys through the code and wrote down the rules the new platform had to preserve.
03Find where changes could fail
We checked which behaviour had automated protection, where errors could be missed and why one fix could break something else.
04Work out what it would take to run
We reviewed access, infrastructure, monitoring and the day-to-day work required to keep the platform dependable.

What we inherited

Core platform

Vue 2 web portal

Large set of .NET backends

Separate onboarding

Its own .NET and Razor product

Its own data and business rules

Custom sign-in

A separate Node service

Sessions and identity managed in-house

What the audit found

Three codebases and 32 .NET projects: The inherited estate split the core platform, onboarding and sign-in across a large collection of projects that had grown separately.
The platform depended on legacy frameworks: Important parts of the platform used old .NET and Vue versions, making every future change harder and riskier.
Important journeys had little protection: There were some tests, but too few around the behaviour the company depended on. A change could pass unnoticed and break another journey.
27 states and 39 transitions modelled: Writing the core journey as a state model exposed missing paths for cancellations, disputes, failed fulfilment, notifications and admin recovery.

02 · The rebuild

We replaced three disconnected systems with one product

The new platform used React and TypeScript in the browser, Hono and TypeScript on the backend, and Postgres for the main data. Sharing one language across the product meant a mistake could be caught earlier instead of appearing only after a user reached the screen.

We replaced the custom sign-in service with WorkOS, used Temporal for work that needed several reliable steps, and built the infrastructure on AWS EKS. The company received one system with clear ownership instead of three products that had to be kept in sync.

One TypeScript product: React on the frontend and Hono on the backend gave the product one shared language and end-to-end type checking.
Managed sign-in and permissions: WorkOS replaced the custom sign-in service, while the platform kept control of users, organisations, roles and sessions.
Clear data and long-running work: Postgres became the main source of data, and Temporal handled work that needed several steps, retries or a reliable wait.
Infrastructure the team could reproduce: The platform ran on AWS EKS with changes, migrations, secrets and monitoring handled through a repeatable delivery setup.
A proven scheduling interface: We adapted selected components and interaction patterns from Cal.com’s MIT-licensed open-source code into the local React product.

03 · Grail Software Factory setup

We set up Grail Software Factory for the rebuild

We connected the repository to the Factory and gave it the useful knowledge from the audit: how the product worked, what the new platform had to do, which decisions were already settled and what each change had to preserve.

We turned that knowledge into requirements, technical plans and Tasks. We also wrote down the checks for each part of the product. Every Task began with the same source material and returned with working evidence the company could review.

This mattered because the team did not have to explain the product again for every piece of work. Accepted decisions stayed beside the code, and the next Task could start with what the Factory had already learned.

01
Connect the repository
The Factory recorded an exact starting version and kept every Task separate from the main codebase while work was underway.
02
Put product knowledge beside the code
We added the business rules, agreed requirements, architecture, known risks and working instructions uncovered during the audit.
03
Define how work is checked
The repository named the commands for checking the frontend, APIs, database changes and complete browser journeys.
04
Create the review path
Each Task had to return a reviewable change, the checks that actually ran and working product evidence before production.

04 · Building through the Factory

Each Task moved from a business request to working software

The company described the result it needed in normal business language. Grail turned that into a clear Task with examples, the right product knowledge and the checks it had to pass. When the Task was ready, the Factory started work automatically.

Work happened in an isolated copy of the repository, so many Tasks could move at once without interfering with each other. The company could see the current stage, answer a question when one was needed and review the result on staging when it was complete.

01
A requirement entered the Factory as a Task with the outcome, examples and product knowledge it needed.
02
When the Task was ready, the Factory started work in an isolated copy of the repository.
03
The company could see whether the Task was being understood, planned, built, reviewed, tested or prepared for staging.
04
If a business decision was missing, the Task paused and asked the question in the same discussion.
05
Completed work returned with a plain summary, the checks that passed and a video showing what had changed.

05 · Correctness

Every change had to show that the important parts of the product still worked

The inherited software protected only a small part of its behaviour with automated tests. The rebuilt platform now has more than 700 automated test files covering business rules, APIs, database changes, long-running work, browsers and complete user journeys.

Each Task began from a known repository version. Its checks ran against the exact change the company was reviewing. A failed check stopped the work from moving forward, and a later code change made the earlier result stale instead of quietly reusing it.

Automated checks were one layer. Grail reviewed architecture, permissions, data handling and failure paths. The company then tested the working product on staging and decided whether it matched the real operation.

06 · Feedback and knowledge

Every answer became part of the product knowledge

Feedback arrived through calls, WhatsApp messages and captured product issues. Grail turned it into tracked requirements and Tasks, then kept the original question, answer, screenshots and review notes together with the work.

When an answer changed a lasting business rule or technical choice, it also changed the knowledge beside the code. The next Task began with the accepted decision already available instead of asking the company to explain the same point again.

Feedback became clear work: Notes from calls, written messages and captured issues were attached to the right Task instead of disappearing across different channels.
The knowledge base kept the decision: When feedback changed a lasting rule or technical choice, we updated the requirement or architecture beside the code.
The next Task began with more context: Future work could use the accepted decision, its tests and the earlier evidence without asking the company to explain it again.

Technology used in the rebuild

TypeScript

React

Hono

Postgres

Temporal

Sentry

AWS

07 · Production support

Problems in the live platform returned as clear work

Grail stayed responsible after the rebuild. Sentry errors and traces helped the team see what had failed, which user journey was affected and where the investigation should begin. Product issues captured with Jam included the screen, recent actions and network details needed to reproduce the problem.

The useful context became a maintenance Task in the Factory. The team could fix it, add an automated check for the missed behaviour and return a working staging version for review. That kept support and new product work in the same system instead of building a second queue around it.

08 · The outcome

Live in production within 30 days

The rebuilt platform was live in production within 30 days. By day 40, the company had onboarded 100 business customers. Grail stayed on as its technology partner for new features, infrastructure and production support.

Within 30 daysThe rebuilt platform was live
The product, infrastructure, checks and operating process were in place for the company to move forward.
Day 40100 business customers had been onboarded
The company continued adding customers while new work moved through the same Grail team and Factory process.

Grail stayed after the rebuild. The same team now handles new features, bugs, infrastructure and production. The company can explain what it needs once, review the working change and keep moving.

Bring us the software that has to work