Launch day is the middle of the project, not the end. The costs and decisions that follow it are the ones people are least prepared for, mostly because nobody brings them up while the quote is being signed.
Key Takeaways
- Budget roughly 10 to 20% of the build cost per year to keep it running.
- Things break without anyone touching them, because the world moves underneath.
- Agree who answers the phone at 7am before you need to know.
- The handover list matters more than the final invoice.
What It Costs to Keep Running
Hosting and services. Usually modest for a small business app, from a few dollars a month to a couple of hundred depending on what it does. Text messages, email delivery and card processing are charged per use and scale with your success.
Fixes. Software that nobody touches still breaks, because the phones, browsers and services around it keep changing. An operating system update can break a screen you have not edited in a year.
Small changes. You will want them, and they are a sign it is being used. Budget for them rather than treating each one as a surprise.
Taken together, ten to twenty percent of the build cost per year is the planning number. A $10,000 build is roughly a $1,000 to $2,000 a year commitment after launch.
The Question to Settle Before Launch
Who answers when it breaks on a Saturday, how fast, and at what price.
The three usual answers are a retainer, hourly on request, or nothing. Nothing is a real choice for something non-critical. It is a terrible surprise for something your business runs on, discovered on the morning it matters.
The Handover List
Before the final payment, make sure you actually hold:
The code, in an account in your name. The hosting, database and domain, in your name. Every third party account, in your name with your card. A written note of how to deploy a change. And whatever documentation exists, however rough.
That list is the difference between owning software and renting it from whoever happens to have the passwords. Ask for it at the quote stage, not on the last day, because a firm that will not commit to it in writing has told you something useful early.
A Concrete Version
A clinic had a patient portal built and it worked well for fourteen months. Then the text message provider changed how it authenticated, reminders stopped going out, and nobody noticed for nine days because nobody was watching. The original developer had moved on.
The fix itself was a few hours of work. Finding someone, getting them access to accounts that were in the old developer's name, and letting them understand the code took three weeks. The nine days of missed reminders cost more than five years of a maintenance arrangement would have. Nothing about that was a coding failure. It was an ownership and monitoring failure, decided at launch by not deciding.
The Honest Counterpoint
Not everything deserves a maintenance retainer. A simple internal tool that five staff use and that could be replaced in a week does not need a support agreement, and paying monthly for it is waste. Match the arrangement to what an outage actually costs. The mistake is not skipping maintenance, it is skipping the conversation and then finding out which kind of software you had.
Frequently Asked Questions
Can I use a different developer for maintenance?
Yes, and it is easier when the code is clean and in your account. This is another reason to insist on the handover list. A new developer needs a week to find their feet, so allow for that.
How do I know if something is broken?
Ask for basic monitoring at build time. A simple alert when the app stops responding or an important job stops running costs very little to set up and is the difference between nine days and nine minutes.
Will it need rewriting eventually?
Parts of it. Well-built small business software runs for years with small changes. Plan for continuous small investment rather than a cliff.
How much should a maintenance arrangement cost?
For small business software it is usually a modest monthly amount that buys a response time rather than a number of hours. What you are paying for is that someone already knows the code when something breaks, which is worth more than the hours themselves. Compare it against what a day of downtime costs you, not against an hourly rate.
The Bottom Line
Decide who maintains it, what that costs, and that everything is in your name, before the final invoice. The running cost is small. Discovering you have no plan is not. For a free written read on your idea that includes what it takes to keep it alive, try the honest read. See also how to pay for custom software in milestones and how to take over an abandoned codebase.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and places pre-vetted senior LATAM engineers with US teams. Get a free honest read on your idea.
