Childcare and Daycare Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does scoping a full Procare replacement go wrong so often?

Because the specification gets written from the list of things the incumbent does rather than from the list of things that hurt. Replacing Procare or Brightwheel end to end means rebuilding enrollment, tuition plans, staff records, parent communication, photo sharing, check in, messaging and reporting, and most of that is competent in the product you already pay for. The parent app in particular is a solved problem you will not beat, and it is the part parents notice, so a first release that ships a worse one damages the project politically before anyone looks at the billing.

What follows is a familiar shape. Nine months of work, a large invoice, and directors comparing your new parent messaging unfavourably with what they had. Meanwhile the ratio blind spot and the shadow billing spreadsheet, the two things that actually cost money, are scheduled for phase two.

Invert it. Ship the ratio engine, live check in, the immutable compliance log and one clean billing path first, which is $60k to $130k over 12 to 16 weeks, and leave parents on Brightwheel while you do. Directors get something that prevents a citation in week one, the billing person loses the shadow spreadsheet, and you have earned the right to talk about phase two. Operators who sequence it this way also discover that some of the phase two list stops mattering once the first release is live.

What goes wrong when you migrate historical billing and subsidy records?

Child records, enrollment and staff data move cleanly. Historical billing and subsidy records almost never reconcile, and this is the migration item that turns a two week task into a four week one. The reasons are structural rather than careless. Tuition was recorded as a plan on a child while the real revenue was a set of overlapping payer contracts against attendance, so a family that was 60 percent voucher and 40 percent private pay with a sibling discount on before care exists in the old system as one number and a note. Credits were applied by hand. Subsidy remittances that arrived short were absorbed rather than tracked.

When you load that into a system where billing is computed from attendance, the two disagree, and someone has to decide what to do about each disagreement. That is a finance judgement, not a data mapping exercise, and it needs your billing person rather than the developer.

Two fixes. First, set a cut over date and migrate open balances rather than full transaction history, keeping the old system readable for reference. Nobody needs three years of invoice lines inside the new database. Second, run both systems through one complete billing cycle in parallel and reconcile the outputs line by line before you switch off the old one. That parallel cycle is where you find the family whose arrangement nobody documented, and every operator has at least one.

Why do time clock, payment and accounting integrations break after launch?

The ratio engine depends on three streams agreeing: child presence from check in, staff presence from the time clock with qualification flags attached, and your state ratio table. The time clock is the one you probably did not build, because Homebase or When I Work already runs payroll, and that integration is where the engine quietly goes wrong. A teacher clocks in at the wrong site, a float is recorded against the location she started at rather than where she is standing, or a manual punch edit lands in payroll and never reaches your system. The ratio engine keeps reporting confidently against data that no longer matches the room.

Payments break differently. Card and ACH have different failure timing, and the fee logic that decides which parent absorbs what is a policy question people forget to answer, so refunds and partial payments produce balances that do not tie. Accounting breaks slowest of all, usually because posting dimensions were agreed in week two and the chart of accounts changed in month eight.

The fixes are operational. Reconcile the time clock against your own presence data daily and alert on divergence rather than trusting the feed, because a silently wrong ratio calculation is worse than none. Have your bookkeeper sign off the posting model before it is built, not after. And decide the payment fee policy in writing before anyone codes it, because retrofitting it means reissuing statements.

What happens when the licensing evidence trail is not covered?

A licensing specialist asks for the medication log for one child, the incident report from March, the parent's signed acknowledgement and the staff member's training record for medication administration. In most centers the med log is paper in a binder, the incident is in Brightwheel, the acknowledgement is a photo of a signature someone texted, and the training record is a folder on the shared drive. Forty minutes of assembly happens in front of the inspector, which is exactly the wrong impression to make.

The same gap has a worse version. If your ratio log is derived after the fact from two exports, you cannot prove compliance, you can only fail to prove non compliance. Those are not the same thing when a specialist has already found a gap.

Design the licensing packet before you design the screens. One child record and one staff record with everything hanging off them: incidents, medication administration with dual sign off, allergies, immunisations with state due dates, parent acknowledgements captured as signatures at pickup, staff credentials with expiry alerts 60 days out. Then a packet export that takes a date range and a child or a room and produces the complete file in one document in under a minute. Write the immutable ratio log per room per minute from the start, because it cannot be reconstructed later and it is the single artefact that changes how a licensing visit goes.

Should you build custom or configure what you already own?

Stay on Brightwheel, Lillio or Procare if you run one to three sites under about 150 children, mostly private pay, in one state. At that scale the few hundred dollars a month is the cheapest software you will ever buy, and a build will not pay back before your operating reality changes. Do not build a parent photo app under any circumstances.

There is a middle position that suits more operators than either extreme. Keep Brightwheel for parent communication and check in, and build only the ratio engine, the compliance log and the subsidy billing layer on top of its data. That is a smaller project, it preserves the part parents like, and it targets the two areas where packaged tools are structurally weak: ratio as a live state rather than a report, and county level subsidy rules no vendor will build for a customer base your size.

Build more broadly when the signals cluster, and they usually arrive together. Over 300 children across three or more sites. More than a third of revenue through subsidy or employer contracts. Two or more states with different ratio rulebooks. Someone spending more than eight hours a week reconciling spreadsheets. A citation better data would have prevented. And the one that settles it: an acquisition plan where folding a newly bought center into one operating picture in 30 days has become a term in the deal math.

How do hidden costs get into the quote?

Five items account for most of it. Additional states, because each one is a distinct ratio table, licensing form set and often a distinct subsidy remittance format, and states three through six are only cheap if the first two were built as editable data rather than code. Subsidy programmes, where one county voucher is a few weeks and five programmes across three states is a phase of its own. A native parent app with photo and video, which costs meaningfully more than mobile web and is usually the wrong thing to build. Migration, which arrives quoted as two weeks and lands at four once the billing discrepancies need decisions. And the parallel billing cycle, which is real staff time from your billing person rather than developer time, and is invariably left out of the plan.

Make them visible by asking for each state as its own line, each subsidy programme as its own line, and migration as its own line with a named number of reconciliation days. Then ask what specifically changes when state number three arrives: a configuration record, or a release. If the answer is a release, the ratio table has been hardcoded and every new state is a new project, which is exactly the trap the packaged tools already fell into.

What separates a build that works from one that fails here?

The working ones hold the ratio table as data you can edit without a deploy, with age bands, room types, staff qualifications, break handling and mixed age rules as separate concepts. Ratio is recomputed on every check in and clock in event rather than on a schedule. Billing is computed from attendance with a stack of payer contracts per child, so the parent invoice and the state claim are produced from the same record and cannot disagree. Credentials are hard constraints on scheduling rather than fields on a profile.

The failing ones share one of two shapes. Either a single ratios column appears in the schema, or 1:4 is hardcoded somewhere, both of which mean nobody has shipped this before. Or the project scoped a full replacement, spent its budget reaching parity on parent messaging, and never reached the compliance log.

The test before signing is to ask the developer to sketch the ratio schema in front of you, not describe it. Then ask what they will do with a scanned state remittance advice, and listen for extraction with a human review queue and an explicit exception path rather than a promise to parse it. Anyone offering fully automated subsidy reconciliation with no review step has not watched a county change its file format mid quarter.