How to Build an App Like Brightwheel: Parent Communication, Staff Management, and COPPA Compliance

A preschool chain with 15 centers pays Brightwheel $36,000–$72,000 per year. That number compounds every year. The parent data lives in Brightwheel's database. The billing relationship runs through their system. When your state licensing agency needs a custom report, you either work around their export format or file it manually.

That is why daycare franchise networks, after-school program operators, and multi-center childcare organizations build their own platforms.

Custom breaks even in two to three years. After that, every dollar saved goes back to the business.

How Brightwheel makes money (and what your options are)

Brightwheel operates on a per-center SaaS model. Centers pay $200–$400 per month per location, plus transaction fees on tuition payments processed through the platform. According to Crunchbase funding data, Brightwheel has raised over $275 million, built for mass-market reach across single-location preschools and small chains.

That model works for Brightwheel. It punishes franchise operators.

A 15-center network at $400/month pays $72,000 per year, every year. At 25 centers, that is $120,000 annually. The platform does not become cheaper as you add locations. There is no volume discount built into their model.

When you build your own platform, your monetization options open up depending on your business structure:

If you operate the centers: you eliminate the per-center SaaS fee. A platform built for $110,000 breaks even against a $72,000/year Brightwheel bill in just under two years. After that, it is pure savings.

If you are building a SaaS for other operators: you control the pricing model. Common approaches are a flat per-location fee (typically $150–$250/month), a percentage of tuition processed (1–2%), or a blended model. At 50 client centers paying $200/month, you are running a $1.2M ARR product.

If you run a franchise: you bundle the platform as part of the franchise fee or charge it back to franchisees at cost. This creates a software asset that grows in value with each new location sold.

According to IBISWorld's Childcare Services report, the US childcare market generates over $60 billion in annual revenue, with multi-location operators accounting for a growing share. The per-center SaaS model transfers a disproportionate amount of that revenue to software vendors.

Who builds this instead of buying Brightwheel

Building custom makes economic sense at scale, not at one location. The organizations that build their own are specific.

Preschool and daycare franchise networks operating 10+ locations. Their Brightwheel bill has crossed $40,000/year and keeps climbing. More importantly, Brightwheel's compliance reports do not match their state's licensing format. They have been filing the gap manually for two years. The franchise development team wants a system that generates state-specific reports on demand, handles franchisee-level billing separately from the parent entity, and gives the franchisor a consolidated dashboard without paying for yet another integration.

Head Start and government-subsidized program operators. These programs receive federal and state funding through CCAP (Child Care and Development Fund). The funding agency requires specific attendance documentation — timestamped records, not aggregated counts — to confirm that subsidized slots were used by enrolled children. Brightwheel's subsidy tracking does not produce the exact report formats that state agencies request. Head Start operators end up exporting raw data and reformatting it in Excel before every billing cycle. That is a built-in compliance risk.

After-school program operators running programs across a school district. These operators serve dozens of sites, with each site attached to a specific school's bell schedule. They need check-in tied to school dismissal times, staff-to-child ratio tracking that adjusts by grade level, and billing structures that align with the district's subsidy payment calendar. Off-the-shelf childcare software is designed around daycare hours, not school-year programming.

Employer-sponsored childcare centers at healthcare systems and corporate campuses. These centers operate under the employer's data policies, not a consumer SaaS vendor's terms. Parent data and child health records cannot sit in a third-party system without explicit data governance controls. The employer's legal team ends up putting a hold on any new software that does not meet their data residency requirements. Custom gives them full control of where data lives.

"Digital check-in and ratio tracking are no longer optional for licensed childcare centers. State licensing agencies increasingly expect software-generated audit trails, not paper logs."

-- Sharon Ricks, former Early Childhood Program Specialist, Georgia Department of Early Care and Learning, speaking at the 2023 NAEYC Annual Conference

What features does a childcare management app need?

A childcare management platform has two distinct user groups: staff in the classroom and parents on their phones. Features that work for one often fail the other if they are not designed separately. Here is how the feature set breaks down by phase.

V1 — what you need to open the doors

Check-in and check-out. This is the most safety-critical feature in the system, and the one state licensing agencies check first. Parents check in using a QR code, a PIN, or face recognition. Staff see a live roster of who is present in each classroom. Every arrival and departure is logged to the second with the identity of the adult who completed the pickup. Only adults on the authorized pickup list can check out a child. When someone not on the list attempts pickup, the system flags it immediately. Without this feature, the platform cannot go live at a licensed center. Building it right adds roughly $15,000–$20,000 to the build cost compared to a simple sign-in sheet equivalent, but state licensing requires the audit trail.

Daily parent reports. Parents want to know what their child did. A daily report covers meals, nap times, diaper or potty outcomes, activities, mood, and photos from the day. The design challenge is not the report itself — it is getting teachers to complete it during the day rather than all at once at closing time. The UI needs to work one-handed on a tablet while a teacher manages a toddler. Large touch targets, quick dropdowns, and a direct-to-camera photo button. V1 reports that require too much typing get abandoned within two weeks. We have seen it.

In-app parent messaging. SMS takes the conversation out of the platform and into personal phone numbers, where it becomes undocumentable. In-app messaging keeps every teacher-parent exchange timestamped and logged. Three modes cover the main cases: one-to-one between a teacher and a parent, group announcements to all parents in a classroom, and urgent center-wide alerts for closures or illness outbreaks.

Basic tuition billing. Monthly invoices, automated ACH payments, sibling discounts, and late payment fees. Cross-platform mobile (iOS and Android from one codebase) saves $30,000–$50,000 compared to building native apps for each platform. We build cross-platform unless there is a specific performance reason not to.

V2 — add after you have proven the model

Staff-to-child ratio alerts. Staff-to-child ratios are set by state law and vary by age group: 1:4 for infants, 1:6 for toddlers, 1:8 for preschool-age in many states. A platform serving a multi-state franchise needs to store the correct ratios per state and per classroom type. The system tracks who is clocked in and assigned to which room at any given moment. When a ratio is violated, the center director gets an alert immediately. Adding this feature after launch costs $20,000–$30,000 more than designing it into V1 because it requires reworking the staff attendance data model. It belongs in V1 for any licensed center, but is listed here because single-location pilots sometimes defer it.

Subsidy management. Government childcare assistance programs like CCAP pay a portion of a family's tuition directly to the center. The parent pays the remainder. The system must track the subsidy amount and the parent-owed balance as separate line items, invoice each party correctly, and reconcile subsidy payments when they arrive on a different schedule than parent payments. For Head Start operators, there is an additional layer: attendance records that demonstrate the subsidy was used for actually enrolled children. Exporting this in the format a state agency requires adds $15,000–$25,000 to the build depending on the number of states served.

Staff certification tracking. CPR, first aid, and state-mandated training hours all have expiration dates. The system stores each certificate and sends alerts before expiration. A staff member whose CPR certification has lapsed cannot legally be counted toward ratio compliance. Background check status is a binary: cleared or not cleared. The system blocks a staff member from being added to a classroom roster if their check has not been cleared.

V3 — scale features for multi-state operators

Configurable compliance report builder. Every state has different licensing requirements. Injury reports, medication administration logs, and nap records for infant rooms all need to match the format a state agency expects during an inspection. A configurable report builder lets multi-state franchise operators create report templates for each state without a developer involved. This is not a simple feature. It adds $30,000–$50,000 to the build but eliminates a permanent manual compliance workflow.

API integrations with state subsidy systems. Some states offer direct API access to their subsidy management systems. When available, this replaces manual file exports with automated reconciliation. Building and maintaining state-specific integrations is ongoing work, not a one-time cost.

Multi-entity billing and consolidated reporting. Franchise operators need to see enrollment, tuition collection, and compliance status across all centers in a single dashboard. Each franchisee may have its own billing entity. The platform needs to handle that structure without collapsing all financial data into a single account.

Build vs. Brightwheel: when does custom win?

Keep using Brightwheel when:

You operate fewer than five locations and your state's licensing requirements match Brightwheel's standard report formats. At that scale, the per-center cost is manageable, and building custom software to replace a tool that works is not a good use of capital. Brightwheel also handles product updates, new feature development, and compliance changes for you. For a small operator, that ongoing maintenance value is real.

Build your own when:

Your network has crossed 10 locations and the annual Brightwheel bill is approaching or exceeding $50,000. Your state licensing agency requires report formats that Brightwheel does not produce. You are processing government subsidies and need audit-ready documentation that does not require manual reformatting before submission. Your franchise structure requires franchisee-level billing separate from a parent-company dashboard. You operate in states with compliance rules that differ from Brightwheel's defaults and the workaround is a recurring staff burden.

The payback math is direct. A $110,000 custom build against a $72,000/year Brightwheel bill for a 15-center network breaks even in under two years. A 25-center network paying $120,000/year breaks even in 15 months.

According to the National Association for the Education of Young Children, over 60% of childcare centers in the United States operate in multi-location networks or franchise arrangements. That is the market where custom software has a clear financial case.

What to get right before you build

The biggest mistake operators make before a build is skipping the compliance audit. Every state has different licensing requirements. Ratio rules differ. Required log formats differ. The events that must be documented differ. Before writing a line of code, map every state your network operates in, pull the actual licensing regulations, and identify every report the state agency expects during an inspection. Build those requirements into the spec.

The second mistake is designing the daily report UI for desktop. Teachers use tablets. They are standing up. They have a child in their lap. Every input that requires typing is friction. Use dropdowns, presets, and photo capture wherever possible.

The failure mode we see most often in childcare platform builds is treating the compliance layer as a feature to add later. Teams that defer it invariably rebuild a significant portion of their data model in month four when the first state audit reveals the report formats are wrong. Designing the compliance architecture upfront adds two to three weeks at the start. Rebuilding after launch costs eight to twelve weeks and disrupts a live operation.

How RaftLabs approaches this build

RaftLabs has built SaaS platforms for franchise networks and multi-location operators. The compliance audit before design is not optional: it is the step that determines how many state-specific report variants the platform needs and how complex the billing module must be.

We run a two-week discovery sprint to finalize feature scope and compliance requirements for the specific states the operator serves. Development follows for ten to twelve weeks. The team is one product lead, two to three developers, and a QA engineer focused on the compliance workflows.

The cross-platform mobile choice (React Native for the parent app, React for the teacher tablet) saves $30,000–$50,000 compared to native apps on both platforms, with no meaningful performance penalty for childcare use cases. Relational database architecture is the right choice for compliance reporting because the audit trail requirements demand well-defined schemas and reliable timestamped records. That setup adds predictability to the compliance module that a document database does not provide.

Talk to us about your network size and states served. We will scope the build in one call.