If you want to get a feel for how the early care and education technology market is trending, state-level requests for proposals (RFPs) are a good place to start. We took on the challenge of curating and reviewing over a year’s worth of solicitations in an attempt to identify common themes. After reading the procurement tea leaves, it’s clear that the next big ECE technology revolution is already underway.

Since the start of 2024, more than ten states have gone out to bid for new  child care information systems, spanning public-facing initiatives aimed at improving  family access and delivering better user experiences to back-end efforts meant to streamline workflows, manage subsidies, and consolidate disparate, legacy systems. One of the things that jumped out at us is the long overdue shift from custom build, full-code-ownership requirements to a willingness by state agencies to entertain Software-as-a-Service (SaaS) alternatives when a strong functional fit exists. 

Given that many of these states are moving off of older custom builds that no longer meet their needs despite millions of taxpayer dollars invested, we should perhaps not be so surprised that SaaS is becoming a more attractive option. Even so, many industry vets who have witnessed disastrous implementations firsthand believe the shift is happening too slowly; indeed, we did still see a small number of solicitations mandating custom development and excluding SaaS proposals. These RFPs are still often couched in legacy language from previous procurement cycles, and tend to be far more prescriptive about how things should be done as opposed to focusing on the desired outcomes. 

Why does SaaS find itself on the national radar now? Why are some states embracing it while others have been slower to change? What’s ultimately the difference in the end product? Let’s take a closer look.

Background

When we say “SaaS,” we’re talking specifically about a subscription pricing model for a software product that already exists and requires little to no custom development to meet a state’s needs. Costs are generally more spread out over the life of the contract, with significantly lower one-time implementation costs supplemented by an annual licensing fee for the use of the platform. Typically, SaaS companies release regular updates to their product and provide both strategic and technical support as part of their license agreement.

Custom builds, on the other hand, are one-off efforts often contracted out to large consulting and development firms. These typically come with much larger upfront costs for the building of the platform, followed by a “handoff” of sorts in which the purchasing agency becomes the owner of the code. Ongoing costs are typically dependent on the level of maintenance and support needed to keep the platform running and adapt it to meet new needs, along with any staffing costs for internal developers and support staff. 

5 Reasons to Consider SaaS

1) Configurable over Customizable

Those in the custom build camp often fall back on the idea that they need something designed to spec for them alone, or it won’t work for their unique business needs. While it is true that no two states do things exactly the same way, there is a surprising amount of overlap. The thing about SaaS products is that because they are used in many different parts of the country (or world), they need to be relatively flexible to adapt to local workflows, regulations, reporting requirements, and other needs. SaaS platforms often boast an array of “no-code” configuration options enabling organizations to tailor the software to their use cases with back-end toggles, customized language, and end-to-end workflow automation. 

Custom builds, on the other hand, are designed specifically to meet today’s needs, often at the expense of tomorrow’s anticipated pivots. Agencies find themselves constrained by the rigidity of these builds within just a couple years of implementation, and are left with no recourse but to contract out additional development work to bolt new functionality onto the system, adding additional time, work effort, and cost with each new evolution of the system. 

In the past, custom builds offered more control over the look and feel of the platform. Agencies (understandably) didn’t want to deliver an experience that was plastered with the name and logo of a software company. But, the best SaaS platforms today are also white-labeled, meaning they can be configured to match the branding of any agency, right down to the desired color palette, logos, and terminology. 

2) Faster Time to Launch and More Predictable Costs

We cheated a little by including two benefits in one here, but the two are so often intertwined that it didn’t feel right to separate them. Nearly everybody who has existed in this space for any amount of time can point to a project in which everything went wrong. Implementation deadlines missed, extreme cost overruns, hundreds of thousands of dollars in change orders…The list goes on. 

It’s not that this can’t happen with SaaS—there are plenty of companies out there that have no shame about overpromising and underdelivering—but because agencies are paying to use the software rather than build the software, the risk is significantly lower. If it doesn’t do what the vendor said it would do, the agency can simply end the contract and move on to another option. 

Now consider this: a state agency signs a contract with a custom development shop to build the system of their dreams. However, because the system is being built from scratch by people who likely aren’t as familiar with the industry, it becomes a game of telephone between agency staff, project managers, and software engineers. Issues that should have been anticipated and avoided keep popping up, delaying one deliverable after another. 

Those delays start to snowball and now, a full year into the contract, there is no working product, the entire timeline has shifted, endless change orders have nearly doubled the initial cost projections because the system is being built one piece at a time with no consideration for how it will all work together, and the agency needs to make the impossible decision of whether to proceed with the project in the hope that it will start to come together, or simply abandon the work that has been done and eat the sunk cost. It’s a story we’ve seen play out time and time again, and it never results in a happy ending for anyone. 

3) The Human Element

“I don’t know what we’d do if Margaret ever left!” 

“Josh is our database guy—he’s the only one who really knows how the system works.”  

“I’m sure there’s a way to do that, we just don’t have anyone left in the office who knows how.” 

Raise your hand if you’ve heard any of these before 🙋🏻‍♂️. Custom builds are almost always reliant on a very small number of power users tasked with keeping the system afloat. These are typically either the same people who were there when the system was initially implemented, or the latest in an unbroken chain of IT support staff leading back to when it was. 

In a space where turnover is so prevalent, that’s a risky proposition that comes with an almost guaranteed loss of knowledge and expertise when someone moves out of a role and hands the keys to the next person. With every change, more and more blind spots are introduced. When the people who helped build it have all moved on, the whole system stagnates. 

SaaS products are backed by dedicated support and success teams. Agencies get all the benefits of a single point of contact, extensive product documentation, training resources, support processes, and often even direct access to product teams for feedback, clarification, and prioritization, without the hassle of hiring additional in-house support. Custom builds rarely come with that kind of support; once the code is handed over, it becomes the state’s responsibility, and all the heavy lifting falls on Margaret and Josh from there. 

4) SaaS Doesn't Go Stale

One of the most common scenarios we’ve seen play out at the state level is this: 

• A state makes a massive investment in building a solution that improves their processes and workflows today.
• Within just a few years, those processes and workflows are all different, new needs have arisen, and the rigid custom build can't be adapted without expensive, lengthy development work.
• The state ends up with so many workarounds and supplemental systems that the value they got from the initial build is completely wiped out, and they need to go out to RFP for a whole new system.

With SaaS, you benefit from the evolution and innovation of the entire sector.  Routine maintenance, security updates, and new features are all included in your annual license fee and are happening automatically without the need for any internal intervention or downtime. The ECE landscape is constantly changing, from federal directives down to local strategies, and the needs you have today are little more than a short-term snapshot. SaaS will grow with you. Custom builds will not. 

5) Compliance is Not an Afterthought

Much like functional needs, the laws and industry standards governing technology rarely sit still. This is especially true for data privacy, security, and accessibility. Custom builds have no vetting history. They haven’t undergone rigorous testing and auditing, they don’t hold any certifications, and they don’t have an existing user base validating adherence to industry standards. Because custom builds are so spec-driven, compliance is more likely to be a “check-the-box” addition to build requirements and far less likely to be deeply embedded throughout the platform. 

Given the sensitivity of what’s stored in most child care information systems—especially family and child data—the most stringent privacy and security standards should be non-negotiable. The SaaS platforms competing for state contracts typically have existing contractual obligations for ongoing review, monitoring, and auditing of security controls. These controls evolve as needed to accommodate any changes to state or federal law. Custom builds are once again designed only for the requirements of the moment, meaning every one of those changes will necessitate additional development work.   

Accessibility has also become a growing point of emphasis due to updated ADA guidance, acceptance of the Web Content Accessibility Guidelines (WCAG) as an industry standard, and an increase in  lawsuits stemming from inadequate accommodation for users with physical or cognitive disabilities. SaaS platforms should all be able to provide a Voluntary Product Accessibility Template (VPAT) demonstrating their adherence to those standards before a contract is even executed. Custom builds not only require an expensive embedded accessibility expert to ensure everything is designed with adequate accommodations, there’s also no way of testing or demonstrating that alignment until after the fact. 

And as those requirements evolve, as they recently did with the move from WCAG 2.0 to WCAG 2.1, Level AA as the accepted technical standard for state governments? SaaS solutions will inherently evolve with them. Custom builds will most likely be out of compliance within a year or two of their completion, and the modifications necessary to achieve the latest standard won’t come cheap or easy, assuming the state even realizes they’re out of date before the first lawsuit hits. 

Less Risk, More Sustainability

The preference for one-off development projects and total ownership over code was no doubt rooted in good intentions. When the digital transformation first began to happen, there were no existing  ECE data and technology platforms that were robust or agile enough to accommodate differences in state processes and workflows. The most successful companies were those who secured some of the early contracts and learned from each distinct build, applying those lessons and best practices to the next one, and so forth. 

Some of these systems worked fine for many years, and—in the absence of alternatives—nobody thought to question whether the approach of continuously adding new, niche products for different functional needs (e.g. licensing, workforce registry, family portal, application and eligibility, etc…) was sustainable. Only recently have states begun to take stock of their increasingly disjointed tech stack with an eye toward consolidation and efficiency. Rather than repeat the mistakes of the past, the shift to SaaS aligns with a future state in which more processes are centralized, maintenance costs are more manageable, and the systems have the capacity to evolve over time. Otherwise, you’re just replacing one legacy system with another soon-to-be legacy system. 

We are optimistic that the procurement trend encouraging more SaaS proposals will continue to grow in magnitude as more states make the decision to modernize their approaches. We see this as a boon to the whole industry, resulting in tighter integration of services, more equitable and accessible user experiences, and significant cost savings that will free up more funds for child care supply and affordability.