The Build Is the Easy Quote. Integrating With What You Already Run Is Where It Blows Up.

The quote you got was for the build. It probably wasn't for the part that actually takes time.

Most software quotes for SMBs, schools, and institutions are scoped around the thing everyone can picture: screens, a dashboard, a booking flow, a parent portal. That's the part a vendor can estimate confidently, because it's self-contained — they control every line of it. What's much harder to estimate, and what quietly eats the budget and the calendar, is connecting that new thing to everything you already run: your accounting software, your student information system, your payment processor, your existing login system, your old database that nobody fully documented.

This isn't a hypothetical risk. It's close to the default failure mode on fixed-scope software projects, and it shows up the same way almost every time: the build finishes on schedule, then the project stalls for weeks on "just" wiring it up to the systems it was supposed to replace or sit alongside.

Why integration work resists estimation the way the build doesn't

A vendor can tell you with real confidence how long it takes to build a dashboard with the features you described, because they've built dashboards before and every variable is inside their control. Integration work doesn't behave that way, for a few structural reasons:

• The other system's documentation is often wrong or incomplete. Legacy SIS platforms, old accounting packages, and in-house tools built a decade ago rarely have accurate API docs. Vendors frequently discover the real behavior of a system only once they start calling it.
• Data is never as clean as it looks in a spreadsheet export. Duplicate student records, inconsistent date formats, three different ways "active" got entered over the years — none of this shows up until someone tries to migrate or sync it, and cleanup is its own project.
• Permissions and auth are usually the vendor's first real blocker. Getting API credentials, firewall exceptions, or admin sign-off from whoever manages your existing system can take longer than writing the integration code, especially at schools and colleges where that system is managed by a different department or a different vendor entirely.
• "Integration" can mean a clean REST API call, or it can mean screen-scraping a system that was never built to be integrated with. Those are wildly different amounts of work, and you usually don't find out which one you're dealing with until someone's inside it.

None of this is a knock on vendors who miss it. It's a knock on scoping it loosely, or not at all, before the contract is signed.

What this actually costs you if it's missed

The failure mode isn't usually a blown total budget — it's a blown timeline, followed by a change order that feels like it came out of nowhere. The build itself gets delivered close to on schedule. Then there's a second phase, unplanned and unbudgeted, where the team figures out how to get data in and out of the system you actually run your business on. That phase is where disputes start, because neither side scoped it, so neither side priced it, and now you're negotiating from a position where the rest of the project is already sitting half-finished.

For schools and colleges specifically, this gets worse because the "existing system" side of the integration is frequently owned by a different vendor with its own support contract, its own API limits, and sometimes its own fee for granting access — a cost that has nothing to do with your dev studio and everything to do with contracts you signed years ago.

How to actually scope this before you sign anything

1. List every system the new software needs to talk to, by name, before you ask for a quote. Not "our accounting software" — the specific product and version. A vendor can't estimate integration work against a system they haven't been told exists.
2. Ask the vendor directly: have you integrated with this specific system before? If not, ask how they plan to find out what it actually supports before committing to a timeline. "We'll figure it out during discovery" is a reasonable answer only if discovery is a scoped, paid phase that happens before the fixed-price build is quoted — not something absorbed into week one of development.
3. Get API/data access sorted before the contract starts, not after. If getting credentials or admin approval from another department or vendor is going to take three weeks, that's three weeks you want to spend in parallel with contract negotiation, not after the build is already underway and blocked.
4. Ask who owns data cleanup. If your records need deduplication or reformatting before they can be migrated or synced, decide now whether that's the vendor's job, your internal team's job, or a separate line item — and get it in writing.
5. Treat "integration TBD, will scope during discovery" as a yellow flag in a proposal, not a normal placeholder. It usually means nobody has looked closely enough at the other system yet to know what they're committing to.

The takeaway

If a proposal prices the build in detail but handles integration with a sentence, that sentence is where your schedule and your change orders are going to come from. Before you sign, make the vendor name every system the new software touches and commit — in the contract, not in a verbal assurance — to how discovery on those systems gets scoped and paid for. The build was never the risky part. Finding out, mid-project, what your old systems will and won't let anyone do is.