Decade-Long Partnership building a Purpose-Built Childcare Management System for Market-Leading Childcare Group

Industry

Childcare

Company size

50 - 200 Employees

About

This Client has a network of premium early learning and childcare centers operating across Sydney, Australia, with locations in areas like across Sydney. Catering to children from nursery age up to school readiness, it offers play-based, child-centered education.

3TB

Of Childcare data captured, securely stored since 2017

The Situation

A purpose-built software platform for early childhood education centres had been in market for several years. The platform handled the operational complexity of running childcare — staff rostering, parent communications, meal menu management, enrolment processing, educator profiles, and compliance documentation — in a sector where operational reliability isn't optional. If the platform goes down at 8am on a Monday, childcare centres can't function.

By the time Halcrow became involved, the platform was operational and had a live customer base across multiple childcare providers in Australia. The founder had built significant product capability. What the business needed was a steady, embedded technical partnership: someone to own the ongoing reliability, support the feature backlog, and respond when things went wrong.

The structural challenge: SaaS platforms for regulated sectors like childcare accumulate operational complexity over time. Parent communications, attendance records, enrolment IDs, rostering configurations — every one of these is connected to a family's daily life. Bugs aren't just technical issues; they're a centre director calling at 8am because an educator can't access the system. Support needs to be fast, accountable, and close to the product.

Why they called us

The founder approached Halcrow through network referral. The requirement was clear: a technical partner who could sit inside the product, respond quickly to support requests, and build features that the growing customer base needed.

The platform's technical stack — AWS-hosted, with mobile app components across iOS and Android — required a team comfortable operating across infrastructure, backend, and mobile simultaneously. Platform reliability and feature velocity were equally important, and optimising for one at the expense of the other wasn't acceptable.

Law 3: Decision authority close to the work. Support requests from childcare centres arrive with urgency. A team that has to escalate every issue before acting can't serve a product like this well. The operating model needed to be: receive, diagnose, fix, communicate.

How we worked

Embedded System: Support + Feature Development + AWS Operations

The engagement operated across three parallel streams:

1. Mission-Critical Support

The highest priority in the operating model was mission-critical incidents. When the platform became unresponsive, when email notifications fired incorrectly, when user accounts had configuration problems — these were treated as urgent by the team and resolved quickly with direct communication to the client.

Support requests came through a structured ticketing system, with clear priority tiers. Mission-critical issues — anything affecting platform availability during operating hours — were handled within hours. Non-critical bugs and feature requests moved through a sprint-based development cycle.

2. Continuous Feature Development

The product roadmap required ongoing feature delivery. This included: changes to rostering terminology and workflows, notification system improvements, enrolment processing changes, user account management features, and changes to the mobile app's push notification behaviour.

Every production release was communicated through structured release notes covering the tickets resolved, the testing approach, and any known limitations.

3. AWS Infrastructure Management

The platform ran on AWS. Capacity decisions — scaling, cost management, suspension and reinstatement of services — were managed by Halcrow in consultation with the client. When the client needed to temporarily reduce costs during a low-demand period, the team suspended the relevant services and reinstated them when required. When the business grew and needed capacity increases, the team managed those changes.

WHAT CHANGED

Representative Work: Incidents and Feature Delivery

Rostering and terminology changes: The platform's rostering module used terminology that didn't align with the awards and compliance language childcare centres used day-to-day. The team changed "RDO" to "Rostered Time Off" and "Change of RDO" to "Change of Rostered Time Off" — small changes, but ones that removed friction for educators using the system against their employment conditions.

Notification reliability: Incorrect email notifications during closure periods created confusion for parents. The team identified the root cause — a conflict between the notification logic and the closure configuration — and resolved it in the next release cycle.

Account and enrolment management: Duplicate profile issues, incorrect notification routing for role changes, welcome email failures for new educators — these are the steady-state operational issues of a platform with a growing customer base. Each was tracked, diagnosed, and resolved through the standard support process.

AWS service management: When the client needed to pause infrastructure costs between seasons, the team coordinated a clean suspension of AWS services and a clean reinstatement, with data integrity maintained throughout.

WHY THIS WORKED

Childcare is a sector where operational trust is earned slowly and lost quickly. Centre directors who encounter platform reliability issues don't give many second chances — they have parents and educators depending on their operational tools.

The operating model Halcrow ran for this platform prioritised response speed and communication over everything else. When something went wrong, the client knew about it before their customers did, and they knew what was being done about it.

Law 8: Operational trust is built through consistency, not heroics. The memorable moments in a support engagement are the incidents handled well. But the foundation is the steady-state reliability that means most days, nothing needs handling at all.

what you're buying

This case study is published without the names of the client, founders, or product at the client's request. The project details, support structure, and outcomes are accurate.

Get an honest second opinion on your AI or software development problems. Free.

Call with Sam