Childcare and Daycare Software: Build or Buy at Your Site Count
The threshold is roughly 300 children across three or more sites, with more than a third of revenue arriving through subsidy.
On this page
The threshold is roughly 300 children across three or more sites, with more than a third of revenue arriving through subsidy. Below that, on one to three sites in one state with mostly private pay families, buy Brightwheel, Lillio or Procare and spend nothing on custom software, because a few hundred dollars a month is the cheapest software you will ever purchase and a build will not repay itself before your operating reality changes. Above it, the things breaking are your staff to child ratio maths, your subsidy billing and your state licensing records, which is precisely what packaged childcare products treat as edge cases. Expect $60,000 to $400,000.
When is off the shelf genuinely the right call here?
For most centre operators, and we say so often. Brightwheel is a good product. Lillio and Procare are reasonable at the same size, and ChildPlus is the sensible answer for Head Start programmes. At one to three sites and under roughly 150 children, mostly private pay, in one state, the correct decision is to keep paying and get on with running centres.
Buy, and commission nothing, if this describes you. Three sites or fewer. Under about 150 enrolled children. One state, meaning one staff to child ratio table, one set of licensing forms and one definition of whether a teacher on a break counts as out of the room. Mostly private pay families, or a single subsidy programme you can administer without a shadow spreadsheet. And no acquisition plan on the table.
There is one thing every operator should keep buying permanently, regardless of size, and it is the clearest recommendation on this page. Do not build the parent photo and video experience. It is solved, Brightwheel does it well, and rebuilding it is the fastest way to spend a third of a budget on the feature that changes none of your economics. In the worked example below, keeping parents on the existing product through year one removed roughly $60,000 from the programme.
Keep buying your general workforce tools too if they work. Homebase and When I Work do shift management and availability perfectly well. What they cannot do is understand age bands, credentials and ratios, which is a different layer rather than a better version of the same thing.
When does a custom build actually pay off?
When these signals arrive together, and at this size they usually do.
- Over 300 children across three or more sites. Below that, the Friday reconciliation is annoying. Above it, it is a role.
- More than a third of revenue through subsidy or employer sponsored contracts. Packaged tools model tuition as a plan attached to a child. Real revenue at this size is overlapping payer contracts against attendance, with approved hours caps, absence allowances and separate billing cycles.
- Two or more states with different ratio rules. Each state is a separate rule set rather than a setting, including its own licensing forms and often its own subsidy remittance format.
- Someone spends more than eight hours a week reconciling spreadsheets against your software. Price that honestly and add the billing person maintaining the shadow spreadsheet alongside it.
- A citation better real time data would have prevented. A report telling you that a room was out of ratio on Tuesday at 15:40 does not stop Tuesday.
- An acquisition plan. Every centre you buy arrives on a different system, and folding it into one operating picture inside thirty days becomes a term in the deal maths rather than a technology preference.
How do they compare on the things that matter in this industry?
Five comparisons, and none of them are about parent messaging.
Whether ratio is a state or a report. Packaged products know check ins. They treat ratio as something you run afterwards, because attendance and the time clock live in separate modules and nobody is watching the intersection. A build holds live room state computed from child presence, staff presence with qualification flags, and your state's ratio table as editable data, then alerts a director when a room is one child away from breaking and names qualified staff across your other sites who could cover. It also writes an immutable per room log, which is what you hand a licensing specialist instead of an explanation.
Whether billing derives from attendance. A plan attached to a child cannot express a family at sixty percent subsidy and forty percent private pay with a sibling discount on before care who dropped from five days to three mid period. A payer contract stack against attended minutes can, and it produces the parent invoice and the state claim from one record so they cannot disagree.
Whether capacity is projected. Enrollment tools capture the lead. Neither can tell a parent at 21:40 whether there is an infant spot in March, because March infant capacity depends on which toddlers age up, which nobody has modelled.
Whether the schedule respects the binding constraint. General workforce tools optimise cost and availability. They do not know a teacher without an infant credential cannot cover infants.
Whether a licensing packet exists. Medication logs, incidents, acknowledgments and staff training records in four places is forty minutes in front of an inspector.
What does total cost of ownership look like at your scale?
Two bands, and they are genuinely different products rather than sizes of one. The operations release, meaning the ratio engine with live room state, the immutable compliance log and one clean billing path, runs $60,000 to $130,000 over 12 to 16 weeks in Digital Heroes delivery experience. The full platform adding enrollment with capacity forecasting, subsidy and split billing, scheduling driven by projected attendance, incident and medication records, credential tracking and the licensing packet export runs $150,000 to $400,000 phased over 6 to 12 months.
A four location operator with about 400 enrolled children across two states and two subsidy programmes, migrating from Procare, landed at $153,000 across eight months, with the ratio engine live at week fourteen and parents left on the existing application throughout year one.
Running cost is 18 to 25 percent of build annually, roughly $28,000 to $38,000 on that build, against which your existing per child subscription fees fall away. Compare the net rather than the gross. Four lines sit inside that percentage and deserve naming. State rule maintenance, which is an afternoon of an administrator's time if ratio tables are data and a change request every time if they are code, so ask that question before signing. Subsidy extraction upkeep, because a county file format changing mid quarter is normal. Support during opening hours, since a check in system down at six in the morning is an operational emergency rather than a ticket. And classroom device replacement, because door mounted hardware takes more punishment than office hardware.
Against that, put your per child or per centre monthly fee across sixty months, then add the Friday reconciliation, the shadow spreadsheet, and the leakage. In centres we have looked at with around 400 children across several sites, the gap between what should have been billed and what was billed runs $4,000 to $9,000 a month once late fees, drop in days, unchased subsidy co pays and ratio driven overtime are counted.
What does the hybrid look like, and when is it the honest answer?
Buy the platform, build the thin layer you actually need. In childcare this is not a compromise, it is the sequence we recommend to almost every operator who crosses the threshold.
Keep Brightwheel or Procare for parents. Keep Homebase or When I Work for general shift management if they work for you. Keep your accounting system and your payment processor. Then build only the layer that knows age bands, credentials and ratios: live room state, the compliance log, and billing computed from attendance with a payer contract stack per child. That is the $60,000 to $130,000 release, and it replaces the shadow spreadsheet and the group chat named something like Ratio Help without touching anything parents see.
A smaller hybrid exists for operators not ready to fund the whole release. Build the ratio engine alone. It is the highest value component, it is the one no packaged product does live, and it is a complete deliverable in its own right. Everything else can wait a year.
The hybrid stops being honest in one situation. If your current product will not expose check in and staff clock data through a usable interface, the ratio engine becomes a duplicate check in process, which means two answers to who is in the room. In a system whose entire purpose is a legally binding count, two answers is worse than one imperfect answer, and at that point you are replacing rather than layering whether you planned to or not.
Which should you choose, by operator size and stage?
- One to three sites, under 150 children, one state, mostly private pay. Buy Brightwheel, Lillio or Procare. Commission nothing and spend the difference on staff.
- Head Start programme of any size. Buy ChildPlus. It is built for that funding model and rebuilding it is not a good use of restricted money.
- Three or four sites, 150 to 300 children, one state, one subsidy programme. Still buy, and fix your process. Write down your ratio rules, your absence rules and your fee policy properly, because that document is what a build would encode anyway.
- Over 300 children across three or more sites, or two states. Hybrid. Keep parents where they are and build the ratio engine and the billing layer. This is the highest value project in the category.
- Heavy subsidy operator across several programmes. Build, phased. Start with the programme carrying the most revenue and prove the remittance extraction and exception review loop before adding the rest.
- Acquisitive operator. Build the operations layer and treat it as deal infrastructure. Every centre arrives on a different system, and thirty day integration is either a capability you own or a discount you give.
One discipline regardless of size. Model your ratio tables as editable data on day one. That single decision is the difference between adding your fourth state in a few weeks and adding it as a new project, and it is the trap most packaged tools fell into.
If you would rather scope this before committing budget, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. You keep the specification either way.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- SMS reminders that stated the specific cost of the appointment to the health system reduced missed appointments in Trial One, with the DNA (did-not-attend) rate falling from 11.1% (control) to 8.4% (specific-costs message) - an odds ratio of 0.74 (95% CI 0.61-0.89), i.e. roughly a 24-26% relative reduction - at no additional cost. (Trial Two replicated this at an 8.2% DNA rate.). Source: PLOS ONE (Hallsworth et al.) (2015) →
- In a practice using direct self-booking with easy rescheduling, online-booked appointments had a far lower no-show rate (1.8% median) than offline bookings (5.9%), though a hospital's request/triage system showed the opposite pattern - indicating booking-system design, not online booking per se, drives no-show outcomes. Source: GMS / PubMed Central (German medical practice & university hospital study) (2025) →
- McKinsey argues software developer productivity can be measured by combining system-level metrics (DORA and SPACE) with its own outcome-oriented approach, which it reports deploying across nearly 20 tech, finance, and pharmaceutical companies - a claim that sparked significant debate in the engineering community. Source: McKinsey & Company (2023) →
- Mordor Intelligence sizes the field service management market at USD 6.26 billion in 2026, forecasting USD 9.87 billion by 2031 at a 9.54% CAGR, confirming sustained double-digit-adjacent demand for FSM software. Source: Mordor Intelligence (2026) →
Frequently asked questions
How long does migrating off Procare take and what does it cost?
Two to four weeks of real work inside a larger project, quoted at $12,000 in the worked example. Child records, enrollment and staff data move cleanly. Historical billing and subsidy records almost never reconcile.
The time goes into decisions rather than data movement, so put your finance lead on it rather than treating it as a developer task. Run both systems in parallel for one full billing cycle before cutting over, because the failure that actually hurts is a billing period nobody can reconcile.
What happens if Brightwheel or Procare changes its pricing?
Model it on enrolled children rather than sites, because per child components rise exactly as you grow and there is no point at which they stop.
The practical defence is portability. Get written confirmation that you can export child records, enrollment history, attendance, staff records and billing history in a documented structured form on demand. An operator whose attendance and payer data already live in a system they own negotiates a renewal from a different position, and that benefit rarely appears in the original business case.
How long until directors are actually using it?
Twelve to sixteen weeks for the first release, with a real room running the ratio engine from about week ten. Do not wait for a finished system, because directors find things in a live room that nobody finds in a demonstration, particularly around breaks, floats and mixed age rooms.
Weeks one to three are the ratio tables and the payer contract model, and that is the phase to slow down rather than compress. Get those wrong and everything downstream is a rewrite.
Is Brightwheel enough, and where exactly does it stop?
For one to three sites under about 150 children, mostly private pay, in one state, it is enough and it is the right answer. The parent communication side is genuinely good and is not worth rebuilding at any size.
It stops at ratio and at split billing. It treats ratio as a report rather than a live state, because attendance and time clock data sit in separate modules that nobody is watching in real time, and it models tuition as a plan attached to a child rather than overlapping payer contracts against attendance. Judge it on those two grounds.
Should we build a parent application as well?
No, and this is the clearest recommendation here. Photo and video updates to parents are solved, done well, and a native parent application adds meaningfully to the budget while changing none of your economics.
Keeping parents on the existing product through year one removed roughly $60,000 from the worked example. Move the operations layer first, prove the ratio and billing work, then revisit the parent experience with evidence about what your families actually ask for rather than a feature list.
How much of the budget is the subsidy work, and is it worth it?
In the worked example, $24,000 for remittance extraction with an exception review queue, plus a share of the $26,000 billing line for the payer contract stack. That is roughly a third of the build for two programmes.
It is also the highest return component we ship in this category. A billing person reviewing eleven flagged exceptions instead of reconciling two hundred remittance lines by hand is the difference between subsidy revenue chased and subsidy revenue quietly written off, and the writing off is invisible until somebody counts it.
Why does a second state cost so much more?
Because a state is a rule set rather than a setting. Different ratio tables by age band and room type, different licensing forms, different treatment of a teacher on a break, and frequently a different subsidy remittance format with its own absence rules.
The curve depends entirely on the first build. If ratio tables are editable data, states three through six are weeks each. If they are hardcoded, every new state is a new project. Ask a developer to sketch the ratio schema before you sign, and walk if they propose a single ratio column.
Who owns the code and the child data if we build?
You should own the repository, the infrastructure accounts and the data outright, agreed in writing before work starts. Ask specifically who holds the cloud accounts and whether any part of the stack is a licensed component you would keep paying for.
Child records carry state mandated retention periods, background check records carry their own handling requirements, and if you take federal subsidy money you have obligations about who can see what. A developer who cannot answer the data residency and access control question in specifics will make that your problem later, during an audit.
What would a custom scheduling app cost for a small business with one location?
A single-location scheduling app typically runs $8,000 to $25,000 when scoped as an MVP: a public booking page, staff calendars, Stripe payments, and SMS reminders. In Digital Heroes projects, small businesses keep the budget down by launching with a mobile-friendly web app instead of native iOS and Android apps, which cuts 30 to 40 percent off the initial build. Native apps can follow in phase two once bookings prove the demand.
How do I vet a software agency for a booking system project?
Ask to see a live booking system they built and break it yourself: try booking overlapping slots, cancelling inside the penalty window, and switching time zones mid-booking. An agency that has shipped scheduling before will talk unprompted about double-booking prevention, calendar sync conflicts, and no-show handling; one that has not will only talk about screens. Also ask who writes the booking-rules specification, because at Digital Heroes that document is the single best predictor of a project landing on budget.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
Should I hire a freelancer or an agency to build my booking app?
A strong freelancer works for a simple booking page with payments, roughly the $5,000 to $12,000 range in our experience. Choose an agency once the project needs a designer, backend and frontend developers, and QA working at the same time, which describes nearly every system with staff schedules, payments, and reminders. The practical freelancer risk is bus factor: if one person leaves mid-project, an agency replaces them and you cannot.
What should the first version of a booking app include?
Ship four things: a public booking page, staff calendars with availability rules, card payments or deposits, and automated email and SMS reminders. Leave memberships, packages, gift cards, and reporting dashboards for phase two; they roughly double the build cost and get redesigned after real usage anyway. In Digital Heroes MVP scopes, that four-feature core covers about 80 percent of daily front-desk work from day one.
Who owns the code if an agency builds my booking software?
You should own it outright, and the contract must say so: full IP assignment on final payment, source code in a repository you control, and no clause tying the software to the agency's servers. Watch for vendors that keep ownership and charge a monthly license, which quietly turns your custom build back into a subscription. Digital Heroes assigns all code and hands over the repository, hosting accounts, and documentation at handoff, and that should be your baseline expectation from any agency.
Who owns the code when an agency builds my software?
You should, completely, through a written intellectual property assignment that transfers everything on final payment; without that clause, copyright stays with whoever wrote the code by default. Insist that the repository lives in your own GitHub organization from day one and that hosting, domains, and third-party accounts are registered to you. Also check for licenses to the agency's proprietary frameworks buried in the contract, because those can make switching vendors practically impossible even when you own your own code.
What questions should I ask a development agency on the first call?
Ask who exactly will build it, what happens when scope changes mid-project, what their maintenance terms are after launch, and what they will need from you every week. Then ask them to describe a project that went wrong and what they changed afterward; teams that have shipped at real volume have war stories, and teams claiming a perfect record are hiding something. The scope-change answer matters most: a disciplined shop describes a written change-order process, not a vague promise to be flexible.
What are the biggest mistakes first-time software buyers make?
Choosing the lowest bid, paying more than 30-40% upfront instead of on milestones, skipping a written specification, and having no maintenance plan for after launch. The most expensive of the four in Digital Heroes rescue projects is the missing spec: without written acceptance criteria, done becomes an argument instead of a checklist, and every disagreement resolves in the vendor's favor. Fix those four and you have avoided most of the ways these projects fail.
Who can build a custom booking & scheduling software system?
Digital Heroes builds custom booking & scheduling software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other booking & scheduling software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
Published · Last updated .
