What Happens After Your Custom Software Is Built? Maintenance, Hosting, and Ownership Explained

The question nobody asks until it is too late

Most small business owners spend the discovery call asking about scope, timeline, and price. Those are the right questions for the build itself. They are not the questions that decide whether the software still earns its place in your business three years from now.

The questions that matter most come after launch. Where does the software live? Who fixes the bug a customer finds on a Tuesday morning? Who owns the code? What does it cost to add a feature once the project is officially done? And what happens if you and your developer part ways?

None of this is complicated. It is just usually skipped. This post is the plain-language version of every conversation that should be happening before the contract is signed — so you know what you are signing up for before the build starts, not after.

Hosting: where the software actually lives

Custom software has to run somewhere. For an internal tool, that usually means a cloud server — a slice of computing power you rent by the month from a provider like AWS, Vercel, Render, or DigitalOcean. The application code, the database, the file uploads, the background jobs all live there. When a user opens the URL, that server is what answers.

For most small business applications, the monthly hosting bill is small. A single-tenant business tool serving a team of twenty often runs on infrastructure that costs less than a single user seat on most enterprise SaaS platforms. The cost scales with how much the system is actually used — not with how many people are on your team.

The important question is not how much hosting costs. It is whose name is on the account. The cleanest setup is one where the hosting accounts (cloud provider, domain registrar, email service, database) all live in accounts you own and pay for directly. Your developer should have access to do their job, but the keys should be in your pocket. When the relationship changes for any reason, the software does not leave with the developer.

Ownership: the part most contracts get wrong

The question of who owns the finished code sounds like a legal detail. It is actually the single most important decision in the entire engagement, and it has to be decided before the first line of code is written.

There are three common arrangements, and only one of them is fair to the customer:

• You own the code. The repository lives in an account you control. The developer transfers everything at the end of the project. You can hand it to anyone — another developer, your nephew who codes, the team at a future agency — and they can pick up where the original left off. This is what you want.
• The developer owns the code and licenses it to you. You pay a monthly fee for the right to keep using software you paid to have built. The developer holds the keys and the leverage. If you want to leave, you do not have a path. Avoid this.
• You jointly own the code with some shared rights. Sounds reasonable. In practice, it almost always favors the developer because they wrote it and you cannot easily move it without their cooperation. Treat this as a softer version of the previous trap.

The phrase to look for in the contract is “work for hire” — the standard legal arrangement that says everything created during the engagement is yours from the moment it is created. If that language is missing, ask for it. If the developer pushes back, you have your answer.

Maintenance: what it actually means

“Maintenance” gets used as a single word, but it covers four genuinely different kinds of work — and most of the confusion in maintenance agreements comes from not separating them.

• Security patches. The libraries and frameworks your software is built on get updated regularly. Most updates are uneventful; some patch vulnerabilities that need to be applied within days. A maintenance plan covers the time to keep the foundation current. This is the work that protects you from headlines.
• Bug fixes. Something that worked yesterday stopped working today. A rare error condition. A browser change. A user finds an edge case that did not show up in testing. The work here is small and reactive — a few hours of investigation and a fix. Most months, there will not be much.
• Hosting and uptime. Someone needs to be watching whether the servers are running, whether backups are working, whether disk space is filling up, whether something looks unusual. For a small business application, this is mostly automated, but a real human needs to be on the other end of the alert when something does need attention.
• Small adjustments. The label on a button should change. A report needs an extra column. A new staff member needs an account. These are quick changes that do not require a project, but they are not free either. A good maintenance plan reserves a small block of time each month for this work without it turning into a separate engagement every time.

What “maintenance” should not cover is net-new feature work. If you decide six months after launch that the system should also handle a brand new workflow, that is a small project — not a maintenance ticket. Keeping those categories clean protects everyone. The maintenance bill stays predictable, and real new work gets the design attention it deserves.

Adding features after launch

The single best thing about owning custom software is that it can change with the business. A new line of work opens up. A regulation changes. A client asks for something none of your other clients need. With custom software, that is a conversation about scope and timeline. With off-the-shelf, that is a request sent into a roadmap that may never read it.

The healthy pattern for post-launch feature work is the same as the original build, just smaller: write down what the change should do, agree on a scope and a price, ship it, move on. A good developer can do this in days or weeks rather than months because the codebase already exists and the patterns are already established. You are not starting from scratch — you are extending what is already there.

This is where fixed-price work keeps showing its value. Every small change is a small scope with a known number. You decide what is worth it. You are never surprised by an invoice that grew because someone got lost in the code.

Backups, security, and the boring stuff that matters

The work that you should never have to think about — and absolutely should not skip — sits in three quiet categories:

• Automated backups. The database should be backed up on a schedule, and the backups should be stored somewhere other than where the live system lives. Restoring a backup should be a tested procedure, not a hope. Ask your developer when the last test restore happened.
• Access control and audit logs. Who can log in, what they can do, and what they did should all be answerable. When a staff member leaves, removing their access should take a minute. When something looks wrong, the logs should tell you who did it and when.
• Encryption and secret handling. Passwords stored properly. API keys kept out of the codebase. Connections over HTTPS. The standards here are well known, and a competent developer follows them by default. The question to ask is not whether they do this — it is to confirm in writing that they do.

What a healthy post-launch relationship looks like

The honest version of life after launch is quieter than the sales call would have you expect. The software runs. Your team uses it. Once a month, you and your developer talk for half an hour — what came up, what got patched, what is on the short list for next month. Once a quarter, you decide whether to invest in a new feature.

There should not be drama. There should not be a crisis call once a year. There should not be a quote that surprises you. If any of those become regular, you have the wrong arrangement — not the wrong software.

The single best test of a long-term software relationship is whether your developer is honest about whether a feature is worth building. The right answer to a feature request is sometimes “no, here is a simpler way to solve the same problem,” and a developer who is paid by the hour rarely says that. That is one of the reasons we work fixed-price — the incentives stay aligned with the business outcome, not the meter.

Questions to ask before you sign

Use these in your next conversation with any custom software developer. Their answers tell you what the next three years will actually look like:

• Who owns the source code, the design files, and the data — and is that in writing as work for hire?
• Whose accounts will the hosting, domain, and database live under after launch? Will I have administrator access?
• What does your maintenance plan cover, what does it not cover, and what is the rate for work outside it?
• How are security updates handled and how quickly are critical patches applied?
• What is your backup schedule, where are the backups stored, and when was the last test restore?
• If I needed to hand this codebase to another developer tomorrow, what would I be handing them — and would they be able to pick it up?
• What is the typical turnaround for a small post-launch change?
• How do you price net-new features after the original build is done?

A developer who answers all of these clearly and without hedging is one who has done this before and is comfortable with the customer being in control. A developer who deflects on more than one or two of them is showing you exactly what year two is going to feel like.

The Kairos approach to year two and beyond

Our standard build hands the customer the code, the design files, the database structure, and the hosting accounts at launch. The repository sits in an account you own from day one — not transferred at the end, never held hostage in between. Hosting runs on a cloud provider you set up with our help; the bill comes to you, not us.

Maintenance is a flat monthly arrangement that covers security patches, bug fixes, uptime monitoring, and a reserved block of small-change time each month. Net-new features are scoped and quoted as their own small fixed-price projects. You see the price before any work starts. You never get a surprise invoice.

And if you ever decide to take the codebase to another developer, you can. That is the point of owning it. Our job is to keep being the easiest choice — not to make leaving difficult.

Frequently asked questions

If you are thinking about custom software and want a straight answer about what life looks like after launch — tell us what you are building. We will walk you through the hosting, ownership, and maintenance picture before you commit to a single line of code.