The Build Is the Cheap Part. Owning the Software Afterward Is Where the Budget Goes.

The number that's missing from most proposals

When an SMB or a school gets a quote for a custom dashboard or web app, the number on the page is almost always the build cost: design, development, launch. It's the number that gets compared across three vendors and the number that goes to the board or the owner for sign-off.

It's also the smallest number in the lifetime of that software.

Every piece of custom software keeps generating invoices after it ships — hosting, security patches, dependency upgrades, bug fixes, the inevitable "can we also add" requests from whoever uses it daily. None of that is optional, and almost none of it shows up in the initial quote unless you ask for it specifically. The vendor isn't hiding it — they just quoted what you asked for, which was the build.

What actually keeps costing money after launch

Hosting and infrastructure. Someone pays for the server, the database, the storage, the backups. For a small internal dashboard this might be trivial. For a web app with real traffic, file uploads, or scheduled jobs, it's a recurring line item that scales with usage, not a flat fee you negotiate once.

Dependency and security maintenance. The framework, the libraries, the authentication provider your app is built on all ship updates — some of them patching real vulnerabilities. Skip this for a year or two and you don't just fall behind; you accumulate a migration project, because the gap between your stack and current gets harder to close the longer it's ignored. This work produces no visible feature. It's also not optional if the app touches customer data, payment info, or student records.

Small changes that aren't covered by a warranty. Most contracts include a bug-fix window — 30, 60, 90 days where the vendor fixes things that don't match the original spec. That's not the same as "the sales team wants a new filter on the reports page" six months in. That's a change request, billed separately, and it's where a lot of the real year-two spend actually lives.

The person who answers when something breaks. If your internal champion who understood the system leaves, or the agency that built it stops returning calls, you're paying someone — maybe at a premium — just to get back to a baseline level of support. This is the cost nobody quotes because it only shows up when you need it.

Eventual re-platforming. Nothing lasts forever. A dashboard built on a framework or a data model that fit your business three years ago will eventually need rework as the business changes shape. That's a second build cost, not a maintenance fee, and it's worth knowing roughly when it's coming rather than being surprised by it.

Why this matters more for the build-vs-buy decision than the quote does

If you're comparing a $15,000 custom dashboard against a $50/month SaaS subscription, the sticker prices make the custom build look obviously better within a year. Add three to five years of hosting, patching, and change requests to the dashboard's side of the ledger, and the comparison usually looks different — sometimes still in favor of custom, sometimes not. The point isn't that custom software is a bad deal. It's that the decision made on build cost alone is being made with a number that understates the real commitment by a wide margin.

This is exactly where the build-vs-buy and spreadsheet-vs-dashboard questions actually get decided, and it's also where they get decided badly — because the build quote is concrete and in front of you, and the five-year ownership cost is abstract and has to be asked for.

What to ask before you sign

A vendor who's done this before should be able to answer these without hedging:

• What's the expected monthly hosting cost at our actual usage, not a generic estimate?
• What's included in ongoing maintenance, and what counts as a billable change request?
• Is there a maintenance retainer, and what response time does it actually guarantee?
• Who owns the code, the credentials, and the deployment pipeline if we switch vendors later? (If the answer is vague, that's the real red flag — not the hosting bill.)
• Roughly when will this need a significant rework, given the stack it's built on?

None of these questions are adversarial. A vendor that's planning to be around for your software's lifetime — not just its launch — will have straightforward answers, because they've already budgeted for exactly this with other clients.

The takeaway

Compare total cost of ownership over three to five years, not the build quote, before deciding between custom software and the simpler alternative — and get the ongoing maintenance terms in writing before you sign, not after the first "can we also add" request arrives.