Education software is one of the harder places to build, and the difficulty has surprisingly little to do with engineering.
Start with the environment your product has to survive in. Districts maintain access to an average of 3,001 unique digital tools, while students and educators each interact with about four of them annually (Instructure, 2026). You are entering a market where nearly everything purchased gets quietly forgotten, and where the person evaluating you has learned to expect exactly that.
Then add the stakes. In 2025, 52% of US school districts experienced a cybersecurity incident, up from 36% the year before. The people evaluating your platform have either lived through one of those or watched a neighboring district live through it. That experience shapes every question they ask about identity, permissions, and who holds the data.
Underneath both sits what separates education from most verticals. These systems run for a decade, serve people who cannot pause for a fix, and get replaced on a calendar with one window a year.
The education projects I have seen go badly were rarely undone by a technical decision. They were undone by a migration nobody scoped, or a rewrite that should have been a rescue. What I check first is whether the plan accounts for the day everyone moves.
If you are comparing custom education software development services, this is the half the capability menus leave out. Rescue versus rewrite, the two-audience problem, what a cutover demands, and when buying beats building, drawn from three products we shipped. More context: our custom software development work.
Serving two audiences: teachers and administrators
Your product probably has two users, and they will never agree on what good looks like.
One of them opens it during the worst few minutes of her week, on a phone, often with one hand free. The other is a district administrator comparing you against two competitors for twenty schools at once, and he will never touch your product under pressure. Both have to say yes, and they are judging completely different things. Her test is whether the product works in the moment she actually needs it. His test is whether it holds up across a network of schools he cannot personally supervise. He is also asking whether it will still be worth renewing in two years.
Designing for a user who is under pressure
Ask a product manager who has built for that moment what the interface should do, and the answer gets very short.
"Someone using this is in the worst moment of their working life, holding a phone, and they need to do two things. Select the location. Send the alert. Every decision we could remove from that screen, we removed. Software should be built for the state the user is actually in." — Vitor Carnello, Product Manager, DevSquad
Read that as an engineering constraint rather than a design preference, because it changes what you build underneath. Fewer decisions on screen means fewer states to hold. No optional fields means no validation branch firing while somebody runs down a hallway. On our project Emergent 3, one requirement shaped everything below the interface. An alert has to reach every phone on campus immediately, including the phones set to silent. A notification that politely waits its turn is worthless. The delivery layer was chosen to satisfy that, and so was everything sitting under it.
What district administrators need that teachers never see
The administrator's version of your product is a different product, and it is usually the one that closes the deal.
Emergent 3 never asked for an admin portal. We argued for building one anyway, because the company was selling into districts that run many schools at once. Adding scope to our own project was worth it. What that portal gives an administrator:
Oversight of every school in the network from one place
Reporting that spans all of them, rather than one school at a time
Drill activity tracked school by school, so a school that has quietly stopped practicing surfaces while there is still time to fix it
An early signal that a district has gone quiet, which is the same signal that predicts an awkward renewal conversation
That last one deserves a moment. The feature that keeps a district prepared is also the feature that protects your revenue, which makes it an easy thing to fund.
Most education builds are rewrites, not greenfield
You are probably not starting from an empty repository.
Education software has a long half-life. Institutions buy on multi-year cycles, and the systems they buy stay in service well past the point where anyone enjoys maintaining them.
So the work that lands on your desk tends to arrive in one of two shapes:
A platform that works and cannot be updated. The product is live and earning, but nobody can safely change it.
A rebuild that has stalled short of shippable. Money has been spent, and there is still nothing to sell.
Both are legacy app modernization problems wearing different clothes.
The call you make in the first two weeks, finish or restart, will shape the budget more than any technical decision that follows it.
When to finish another team's build
Eckerd College's Leadership Development Institute had been paying for a rebuild for more than a year and still had nothing it could sell.
The plan was reasonable on paper. Merge a decade of separate product portals into one system, carrying certifications, licenses, client records and years of accumulated data across with it. Execution was where it came apart, and Flavio Pano, who inherited the project, is blunt about the diagnosis while being fair about the cause.
"The company before us was one or two developers. No product manager, no QA, no tech lead. They had been building for over a year and the portal still could not go to market. I do not think they failed on code. They failed because nobody was validating the work or maintaining a real backlog, and the system was far too big for that to hold." — Flavio Pano, Product Manager, DevSquad
We kept the partial build instead of restarting it. The team cleaned up the existing code, stabilized what was there, and got the platform reliable enough to carry paying customers. The reason was economic rather than sentimental. A fresh start would have cost Eckerd a second year on top of the one already spent. Nothing in that code was worth a year.
When to rewrite from scratch instead
Emergent 3 needed the opposite call.
The company came to us with roughly 50,000 people using its school emergency alert platform. V1 had stalled, and nobody was able to touch it, partly for legal reasons. Bugs sat unfixed and planned features went unbuilt. When the system stalled, the founder rebooted the servers himself and hoped. The platform was rewritten and relaunched in five months from scratch. The scoping conversation that made it possible opened by asking what could come out, not what should go in.
"I told Phil, we are in crisis mode and we need help. He said, 'I can help you, but my team won't touch that codebase. We'll write everything fresh, and I'm confident we'll build a better product than what you have today.'” — PK Keller, Founder of Emergent 3
So how do you tell which situation you are in? I have inherited enough half-built platforms to know the first question is not whether the code is good. It is whether anyone was validating the work while it was being written. Code you can read is recoverable, and a year of unreviewed decisions usually is not.
The cutover is the hardest part of the build
Every agency process diagram you look at this week will end at deployment.
That is a strange place to stop, because in education software the launch is a migration, and the migration is where projects come apart.
Two constraints make it harder here than in most industries:
The calendar is fixed. Your window is rare and immovable, and missing the summer means waiting a year for the next one.
Your users cannot absorb a failed switch. A teacher mid-incident and a trainer mid-program have nowhere else to go, no workaround, and no interest in an apology email.
Neither is inside your control, which is why the migration plan gets built around them rather than fitted in afterward.
When old and new systems cannot run side by side
Sometimes the architecture makes the decision for you.
Emergent 3's V2 was written in a different language from V1, which meant the two could not run in parallel. No phased rollout, and no fallback. We shut V1 down and moved roughly 50,000 users onto the new platform and its native mobile apps in a single move. The data migration went through cleanly. That kind of night is won or lost weeks earlier, in the data work, which Sandro Boçon describes well from a rollout of his own.
"The real work of launching was not training. It was data. Every store exported whatever list it had, and we normalized it and loaded it store by store. We considered letting each store import its own, and decided against it, because we could not guarantee the information would come through complete. Getting the data right is not a step you delegate to the customer." — Sandro Boçon, Product Manager, DevSquad
The temptation is always to hand that job to your customers, since they know their own records better than you ever will. Resist it.
Sequencing a rollout so revenue never stops
When a staged retirement is possible, sequence it so the money starts early.
Eckerd College's Leadership Development Institute did not wait for a full migration before selling. The Conflict Dynamics Profile went live first, then the remaining English products, then all five languages. The legacy portals were switched off one at a time after that. Trainers were running live programs throughout, so the new platform had to match the old ones feature for feature before anything could be retired.
The principle underneath that is simple enough to plan around. Get something sellable live as soon as it genuinely works, then retire the old systems one at a time. There is a catch, and it stalls more staged rollouts than any technical problem does. Nothing forces a user off an old system if the new one cannot do something the old one did. Feature parity is not a nice-to-have on a migration plan. It is the condition for switching anything off at all.
What FERPA and COPPA actually change in the code
You have seen the badge row already. FERPA, COPPA, GDPR, SCORM, LTI and WCAG, laid out in a tidy line on every agency page you visited this month. None of it tells you what to build.
Strip away the legal framing and these regulations resolve into two engineering questions. Who is allowed to see what, and what record survives the action. Districts are asking both harder than they used to, and with good reason. Vendor related incidents rose from 4% of reported district breaches in 2023 to 32% in 2025.
Verifying parents and guardians is the hard part
Students and teachers are the easy part.
In K-12, the hardest identity case is the parent or guardian, because your system has to prove who is allowed to collect a child. Emergent 3's newest work handles exactly that. After an evacuation, students are moved off-site, and every parent has to be told where to collect their child. Each one has to be verified before a release happens. The product does it with a QR code the parent presents on arrival, an ID check, and a full log of every release. Higher and professional education runs the same problem with different stakes attached. On Scholars in Medicine, signing up requires a valid NPI number. Every registered user is a verified US healthcare provider rather than whoever happened to find the URL.
What you need to log, and why
Logging is architecture, not a feature you add in month four.
In a regulated environment the record is part of the product, and somebody will eventually ask you for it. Three that have to exist by design:
Every child release, logged with who collected whom and when
Drill activity per school, so a district can prove it was prepared
Every permission change, so you can answer who granted access and on what date
When I review a build for a school product, I look at the permission model before anything else. Every other decision inherits from it. Retrofitting roles and audit logging into a system that assumed one kind of user is where teams lose a quarter.
Build or buy against Blackbaud, PowerSchool, and Veracross
Some of what you are planning to build already exists, and the existing version is better than what you would ship in month one.
Blackbaud, PowerSchool and Veracross have spent decades on student information, admissions, gradebooks, tuition billing and advancement, and they are good at those things. Any page that never recommends buying is a sales document dressed as advice, so here is the honest split. It comes down to one question: is the software the thing you sell, or the thing that keeps the lights on?
Buy when your requirements match the product
Buy when your workflow is a normal workflow.
If you could describe it to a competitor in one sentence and they would nod along, an incumbent has already solved it. That covers a lot of ground.
Student information and records management
Admissions and enrollment
Gradebooks and assessment recording
Tuition billing and payments
Advancement and donor management
Building any of those is an expensive route to somewhere you could already be standing. The higher value move is usually integration, and Emergent 3 is a good illustration. It connects to the parent notification system districts already run, so schools are not maintaining two sets of contact details. The product avoids an argument it was never going to win.
Build when nothing on the market fits your model
Build when nothing on the market is shaped like your business. Three conditions justify it:
The software is the product you sell, rather than the system behind the product
The workflow is specific to your institution and gives you an advantage worth protecting
The model you distribute under is one the incumbents cannot support
Eckerd is the clearest example of that third case. The assessments, the scales, the reports and the certification model are all specific to them, and nothing off the shelf could have carried it. The platform now serves distributors in Portugal, Brazil, Colombia, France and Germany, with every product available in all five languages inside a single system. Revenue is earned per license and per report, so every trainer added in a new country is incremental income. That is SaaS product development in everything but name, run by a college. Build when the software is the business, and buy when the software is the overhead.
Spotlight on three education platforms that took us less than 6 months to build
Ask anyone describing themselves as a leading custom software development firm for education to name three products they shipped. Then ask what each one took.
Here are ours. They were picked because they cover different shapes of the same problem, not because they flatter.
ParentPulse went to market in under four months. A survey and parent experience platform for Christian schools, giving them NPS ratings, experience benchmarks and a read on parent satisfaction. The version one scope was kept deliberately narrow. Deliver real value without packing the product full of features, get it in front of customers, and let revenue decide what came next. It was built on Laravel after a design sprint that cut the feature set down before development started.
BoosterHub launched V1 in six months. Booster club management, replacing a pile of spreadsheets, cash boxes and scattered contact lists. Roughly two years after the first meeting, the company reported 10,000 users in the system. It also reported 70,000 transactions worth more than $2 million processed in a single year. BoosterHub later brought development in house, so we handed over the codebase, trained the new team and wrote the documentation.
Emergent 3 was rewritten and launched in five months, against a four month estimate. Around 50,000 users moved in one cutover with no fallback, onto native apps across every platform plus the district admin portal. Two and a half years later the product is still shipping continuously, on a codebase the company owns outright.
None of those timelines came from working faster. Each one came from cutting scope before development started. That is the least glamorous decision available on a software project, and reliably the most valuable.
How to decide your next step
The decision in front of you is simpler than you think.
There are only two ways to go:
You already have a platform. The question is whether it can be finished, and two weeks with someone willing to read the code and assess the team around it will usually answer that.
You are starting fresh. The question is what to cut, and cutting is what makes the timelines above possible.
Either way, answering it before development starts is worth more than any technology choice you make afterwards.
That is what a discovery sprint is for. If you are weighing up a custom education software development company, ask them to run one first and tell you honestly what they would remove. Their answer will tell you a great deal about how the rest of the project is likely to go.
Custom education software development FAQs
Four to six months for a well scoped first version, based on what we have shipped. ParentPulse went to market in under four months, BoosterHub's V1 took six, and the Emergent 3 rewrite took five against a four month estimate. The variable is almost never engineering speed. It is how much scope comes out before development starts, and how quickly the people who own the decisions can make them.
Finish it when the code is readable and the previous team's problem was structure rather than skill. Eckerd's rebuild had stalled for over a year under a vendor with no product manager, QA or tech lead. The partial build was still worth keeping, because restarting would have cost another year. Rebuild when the codebase is frozen, legally encumbered, or written on a stack that cannot carry the business forward.
Treat it as two engineering questions rather than a certificate to collect. Decide who is allowed to see what, and decide what record survives every action. Design both into the permission model before you build features on top. In practice that means role based access and verified identity for anyone acting on a student's behalf. It also means audit logging that can answer who did what and when, months later.
You can, and sometimes there is no choice, but the calendar is working against you. A district mid year has live classes, live programs and no appetite for downtime. A mid year move needs either a phased retirement, or a single cutover with the data work fully finished in advance. If you can wait for a summer window, wait. If you cannot, budget the migration as a project rather than a launch task.
DevSquad solves complex business problems with internal software users love. Learn more about our custom development services.
Rafael Lunardelli is the CTO at DevSquad and founder of Pinguim Academy. With nearly two decades in software development, he specializes in scalable systems, DevOps, QA, and modern PHP development. Rafael has led enterprise projects at KPMG and now teaches thousands of developers through his Laravel-focused courses, conference talks, and online content.