Avoid the mistakes of legacy state systems

BridgeCare represents the next evolution of statewide early childhood infrastructure. Learn how a more modern, human-centered approach is changing the way states operate from the top down.

All articles

Questions to Ask When Evaluating ECE Software Vendors

article
byJohn JenningsonOctober 2, 2025
Questions to Ask Cover

The modernization of our early care and education systems is upon us. Ever-increasing volumes of state-level RFPs, sunsetting of legacy systems, and a growing need for more efficiency and greater data access have created a perfect storm of opportunity for technology vendors in this space. 

But opportunity does not always attract the most well-intentioned crowd, and it’s too easy for technology procurement to become a “learn by making mistakes” situation for those who haven’t been through it before. Unfortunately for most of the leaders making these decisions, those mistakes can result in sunk cost and effort that their organizations can’t easily absorb. 

We’ve long been a proponent of the idea that the ECE community needs to do more to band together in support of a well-functioning system. Technology is one area where we should collaborate and learn from each other, rather than watching the same infuriating script play out time and again. Mitigate your risks and set your org up for success by incorporating these questions into your evaluation process. 

 

Questions to Ask

1. Who else are you working with?

This one might seem head-scratchingly obvious, but it comes with one big caveat: a list of names doesn’t mean anything without context. Your goal shouldn’t just be to find social validation in knowing that others are using the software, it should be to uncover what those others are experiencing. 

Although reference checks are a standard part of RFPs, we’re consistently surprised at how infrequently it happens through other procurement channels. A technology vendor’s ability to deliver on its promises is the only thing that ultimately matters, and unless you’re their first customer, there are already people out there who can attest to whether that’s happening. 

Why does this matter? Without naming names, we’ve seen state agencies sign multi-million dollar contracts with companies that are fighting concurrent breach of contract lawsuits stemming from similar projects in other states. There’s a certain fiduciary duty that’s frankly not being met when buyers don’t thoroughly vet the vendors they’re working with. 

Pro tip: Don’t just rely on the contacts the vendor is giving you. They have no incentive to provide you with a representative cross-section of their customers, and you’ll only end up speaking with their biggest advocates. Find out who else is using their software, how long they’ve been using it (have they renewed their contract after the initial period?)  and consider reaching out to their leadership teams yourself for the real story. 

 

2. Is the product white labeled?

As a government agency or nonprofit serving the early care and education community, your technology infrastructure should represent your brand, your integrity, and your mission. When providers and families visit their respective portals from your website, they shouldn’t feel the jarring impact of entering a whole new experience plastered with the logo and branding of some software company they’ve never heard of. They shouldn’t have to leave your site at all. 

Ideally, you’ll want the web experience to feel seamless for the people you serve. Whether they’re searching for child care, completing an application, submitting attendance records, or viewing payment history, it should be very clear that they’re working with you and the programs you support, not a random third party. 

Why does this matter? The processes of finding care, applying for subsidy, and running an early education program are complicated enough as it is. The more variables you introduce, the more potential for confusion. A disconnected experience results in avoidable barriers to family and provider participation and less enthusiasm for your program. 

Pro tip: It’s very easy to spend the bulk of your evaluation poring over features and functionality. Don’t let “look and feel” get lost in the shuffle. Put yourself in the shoes of your end user and ask yourself if the experience you’re seeing in your demo or sandbox is the experience you want for your families and/or providers. This is one of those things that is obviously beneficial in hindsight, but surprisingly rare in practice. White labeling should be a baseline expectation for the next generation of ECE technology. 

 

3. What functionality actually exists right now?

You would be amazed at how adept technology companies are at making their product look far more capable than it actually is through a combination of clever marketing and heavily controlled demo environments. When you read web copy, see screenshots, or watch videos, it’s natural to assume that what you’re looking at is an accurate depiction of what you would experience in the product, but is it? 

This is a constant point of contention in RFP responses as well, where some vendors will say their product can do everything just to win the business. Because of the way responses are scored (typically as a straight percentage of specifications answered in the affirmative, without any nuance), there’s little incentive for honesty. We’ve even heard of agencies using AI to score specification spreadsheets in recent years, which removes even more context from those responses and offers even more incentive for vendors to kick the can down the road and say “we’ll deal with it after we win.” 

Why does this matter? There are very well known software providers out there right now that are advertising functionality they don’t yet have in an effort to cash in on current market trends. Sure, they’ll build it if the right person comes along to buy it, but there’s no guarantee the end product will end up looking like it does in the marketing materials they’re presenting to the world as accurate. A partnership based on false promises is doomed to fail. 

Pro tip: The best thing you can do is hold vendors’ feet to the fire during the sales process. If you’re writing an RFP, consider very strict instructions for what constitutes “Available” in your specifications. One approach that leaves minimal room for creative interpretation is to include something along the lines of “Must be available for demonstration in a live environment by [date].” If the time comes for the demo and the functionality’s not there, you’ll know exactly what’s going on. Dishonesty should be immediate grounds for disqualification. 

Consider an alternative category for “Functionality does not currently exist, but is included in the cost and will be launched within the agreed upon timeline.” There’s still some level of trust involved, but you should be able to get a better idea from references whether a vendor has a track record of delivering on its promises. 

 

Interoperability

4. How will your product interact with the rest of my infrastructure?

Consolidation of disparate systems is one of the most common drivers for evaluating technology in the first place, but very few products can “do everything,” and even fewer organizations are going to be in a position to move off of all their legacy systems at once. Interoperability has become a top priority at every level of the ECE system, and we expect that trend to continue as momentum builds for modernization throughout the country. 

Read: From Silos to Systems: Unlocking Child Care Data with APIs (Opportunities Exchange, 2025)

There are some systemic issues with integration and interoperability in this field. Namely, the lack of a universal data standard for software companies to reference and build for. K-12 was able to solve this problem in the past two decades thanks to initiatives like Ed-Fi and collaboratives like 1EdTech (formerly IMS Global). Until something similar happens in the ECE space, interoperability will largely depend on collaboration between vendors and lots of manual data mapping.

Why does this matter? Nothing kills buy-in for technology initiatives more than multiple logins, redundant data entry, and siloed, fragmented experiences. When families and providers start to feel like they’re jumping through hoops, the returns on your technology investment diminish rapidly. The most functional system in the world won’t get you where you want to go if it can’t seamlessly push and pull data to and from other sources. Ideally, you want to get to the point where all data only needs to be entered one time in one system and where updates in one will be reflected in the others as needed. 

Pro tip: Integrations are a commonly misunderstood part of the software implementation process. Organizations often have a general sense that their systems need to talk to each other, but the further away you get from state agencies, the less likely you are to have clear requirements around exactly which data needs to be moved, how frequently it needs to happen, and which integration method makes the most sense. 

For an RFP process, you’ll want to have your most data literate team members spell out the exact requirements. In the absence of an RFP, make the time to have a detailed conversation with prospective vendors about what those integrations will look like and whether they’re included in proposed costs. Who’s going to build the API bridges? Who’s going to maintain them? Is API even the best way to accomplish a specific integration? The less room left for interpretation, the better.  

 

5. What will my rollout look like?

Though it might sound counterintuitive, the non-technical aspects of your technology partnership deserve every bit as much attention as your functional requirements. More often than not, the success of your implementation will be determined not by features and functionality, but by the vendor’s project management, subject matter expertise, and customer success and support functions. 

We’ve heard the stories at every level of procurement, from buttoned up RFP processes to local, self-driven purchases. Vendors will deliver a polished pitch, their technology will look like a perfect fit, then, once the contract is signed, you’ll be immediately deprioritized and left to fend for yourself.

Why does this matter?  Because, at the system level, there’s no such thing as plug-and-play software. Given the regional, organizational, and programmatic nuance of most projects, you’ll likely need help configuring the software, setting up reports, identifying which user types need which levels of access, delivering training and creating product documentation for all roles, and much more. It’s a lot, and you’re not going to be able to do it alone. 

Pro tip: Vendors are always going to put their best foot forward during the sales process. The people delivering sales demos and answering your questions are going to be knowledgeable, charismatic, and believable. But they’ll be out of the picture quickly after they win your business. You need to find out what lies under the hood. Ask pointed questions about what your actual project team will look like. 

What certifications does your project manager hold? How many implementations have they done and who can you talk to about the outcomes? Who will be your day-to-day point of contact and how will they work with your team? It’s more work than just comparing product specifications, but anyone who’s been through a bad implementation can tell you how much they wish they had sussed these things out earlier.

 

6. What if we forgot to ask for something?

No matter how thorough you are in your evaluation process, this will happen to you at some point. You’ll get all the way through contracting, start standing up your new platform, and realize you forgot to account for something along the way. We see this all the time. By its very nature, this is a challenging issue to anticipate because it only comes up when you haven’t anticipated something. But the outcomes can range from an easy, no-problem solution to a Very Big Deal that threatens the entire project.

Why does this matter?  The answer to this question will speak to the versatility and flexibility of both the vendor and the software itself. ECE is a space where needs are always evolving and requirements are always changing. The last thing you want is to be boxed in by your contract. The software you need two years from now is not the same software you need today, but consistency matters and you can’t afford to be switching vendors every time families, providers, and your team finally become comfortable with what you have in place. 

Pro tip: Spring this scenario on vendors during the sales cycle and see how confident they are in their response. Those who have been down this road before should not be at all surprised. Try something like “What if we decide we need to add an LMS in six months?” or “What if we want to add eligibility verification for another program?” Will it be as simple as just adding a quick change to the contract and folding it into your implementation, or will it be a significant blocker that the vendor doesn’t have an answer for? 

The future of ECE software is modular. We’ve all learned lessons from the rigidity of legacy systems. New functionality is haphazardly bolted on, disparate systems are brought in to fill gaps, and a few years down the road you have an unrecognizable, Frankensteinesque hodgepodge of software. Modern solutions should empower you to start small and add incremental functionality over time in a way that promotes consistency in user experience and tightly integrated data and processes. 

 

Break Glass

Sometimes You Just Have to Press the Reset Button

What happens if you bring in a technology partner only to find that the answers to these questions are not good ones, or at least not what you expected? Most organizations will lean in the direction of “toughing it out” or “working through it” with a vendor who fails to live up to expectations. There is something to be said for that approach—change is hard, and it’s unfair to your staff and your end users to continuously ask them to learn new things. 

That said, there will be times when the partnership is just not going to get better. The ability to recognize those situations and cut your losses can save you thousands (or millions, depending on the size of the project) and help you salvage the trust of your community before it’s too late. Ideally, you’ll want to avoid those scenarios altogether. By asking the right questions and doing your due diligence up front, you can set yourself and your organization up for success. 

 

Are you experiencing any of this right now?

Whatever the scope of your project, we've very likely seen the good, the bad, and the ugly from relevant technology vendors. Contact us today to learn more about how you can keep risk low and make the right decision for your ECE community. 

Talk to an expert
Share:

Stay up to date with Child Care Matters™

Stay current about new features, industry news, and ideas to inspire innovation in the ECE system.

Unsubscribe whenever you want.

We collect cookies to help improve your experience.

To see what information we collect, read our Privacy Policy.