Should the Agency That Builds Your Software Also Host It?
Launch day is when the real question arrives: who runs this now? Here are the three answers, what breaks in each, and the questions that tell you whether an agency can actually run what it built. Our own setup is the worked example.
Oct 10, 2026
The application works. The team that will use it has tried it on staging and likes it. Then someone asks the question nobody put in the specification: where does it live, and who looks after it?
Most buyers treat this as a hosting decision, a line item somewhere between the domain name and the support contract. It is the decision that determines whether the software is still healthy in two years. Almost everything that goes wrong with business software goes wrong after launch, and very little of it is about code.
Should the agency that built it also host it? Sometimes yes, sometimes clearly not. Here is how to tell.
What are the options after launch?
There are three, and every arrangement you will be offered is one of them.
- You take the code and run it yourself. The agency hands over the repository, a deployment guide and, ideally, the infrastructure configuration. Your team, or your IT provider, deploys it and keeps it running.
- A generic hosting or managed-service provider runs it. They keep the servers alive. They did not write the application and will not change it.
- The team that built it runs it. Hosting, monitoring, security updates and changes stay with the people who know the code.
None of these is the right answer by default. The right answer depends on who in your company would notice, at 7 a.m. on a Tuesday, that something is wrong, and who could fix it.
What actually goes wrong after launch?
Not the code. In the projects we inherit, the failures that hurt are almost always operational:
- A credential leaks. An API key sits in a config file that ended up in a repository, a shared drive or an email thread. It worked for two years, so nobody rotated it.
- The backup nobody tested. Backups were switched on at launch. Nobody has ever restored one, so nobody knows whether they work.
- A change reaches production untested. A quick fix is deployed straight to the live system on a Friday afternoon, because there was never a staging environment that matched production.
- Nobody is watching. The database disk fills up over three weeks. The first alert is a customer email.
- The one person who knew leaves. The setup lived in someone's head, or on a server someone configured by hand. Now it is archaeology.
Each of these is cheap to prevent and expensive to recover from. The question is whose job it is to prevent them.
When should you host it yourself?
Take the code and run it yourself if all of these are true:
- You have an operations team, or an IT provider, who already runs production systems and has someone on call.
- Your security or regulatory constraints require the software to live in your own cloud account or data center.
- You plan to bring development in-house, so the people running it will soon be the people changing it.
If that is you, the most important thing to demand from the agency is infrastructure as code: the servers, databases, networks and secrets configuration written as files your team can read and re-run, not a 40-page PDF of screenshots. Without it, "handover" means your team rebuilding the setup by guesswork.
When should the builder run it?
Let the team that built it run it if:
- Nobody in-house runs production systems, and you do not want to hire for it.
- You expect to keep changing the software. The people who wrote the code are the ones who can change it safely, and splitting "who changes it" from "who runs it" creates a gap that problems fall into.
- You want one party to be accountable when something breaks, rather than a hosting provider and a developer each explaining why it is the other's fault.
The risk in this option is lock-in, and it is a real risk. It is also easy to neutralize, with the last question on the list below.
The 8 questions to ask any agency that offers to host your software
These separate an agency that runs software from one that rents a server and hopes. For each, here is the answer we give, as one example of what a good answer looks like.
1. Is the infrastructure written as code?
Ask to see it. If the setup exists only as a server someone configured by hand, it cannot be reviewed, reproduced or handed over.
How we do it: all of our infrastructure is Terraform, with separate staging and production environments, and it changes only through reviewed pull requests. The history shows who changed what, and when.
2. Where do the passwords and API keys live?
The only acceptable answer is a secrets manager. Not environment files on a server, not the repository, not a shared password document.
How we do it: credentials live in HashiCorp Vault inside the cluster, unsealed with Google Cloud KMS, and in Google Secret Manager. They are mounted into the application at runtime. Services authenticate to Google Cloud with Workload Identity, so there are no long-lived key files to leak.
3. How do people reach the admin tools and the database?
If the answer involves a database port open to the internet, or a shared admin password, stop there.
How we do it: cluster nodes have no public IP addresses, and admin tools and database access are reachable only from inside our private Tailscale network. The network policy is kept in a repository and applied by CI, so it cannot drift from what was reviewed. When a client's security review needs it, we narrow access to named people and named services; that is a change to the policy file, not a project.
4. How does a change get to production?
You want to hear "staging first, automatically checked, then promoted", not "we deploy when it's ready".
How we do it: every pull request runs linting with security rules, a dependency vulnerability scan, and an automated security review that blocks the merge when it finds a concern. A release promotes to production the exact image that already ran on staging, and end-to-end tests run against staging every day. Rolling back means redeploying the previous image.
5. How are backups done, and when did you last restore one?
The second half of the question is the one that matters. A backup nobody has restored is a hope, not a backup.
How we do it: databases are managed PostgreSQL on Google Cloud SQL, with automated daily backups kept for seven days. Where a project needs a tighter recovery point, we enable point-in-time recovery on that database, so it can be restored to a specific minute rather than to last night.
6. Who is watching, and how do they find out?
"We check it regularly" is not monitoring. Ask what triggers an alert and who receives it.
How we do it: Google Cloud Monitoring alert policies, defined in the same infrastructure code, watch the production databases for CPU, memory and disk pressure, and for runaway disk growth, and notify us. Application errors are tracked with their context.
7. Where is the data, physically?
This matters for GDPR in Europe, for data-residency clauses in US contracts, and for your own customers' questions.
How we do it: by default our platform runs on Google Cloud in the europe-west1 region, in Belgium. For a project that needs its data in the US, or in a Google Cloud account you own, we set that region or that account up for the project, and it goes into the scope and the price from the start.
8. If we leave, what do we take with us?
This is the question that neutralizes lock-in. The answer you want: the source code, the infrastructure code and the documentation, written into the contract as yours.
How we do it: you own all three, contractually. Because the infrastructure is code, the whole platform can be redeployed into your own cloud account, or run by your team or another firm, without reverse-engineering anything.
What if the agency is not SOC 2 certified?
Most small development firms are not, us included. Certification is a useful shortcut for a procurement team, but it is not the same thing as running software well, and an uncertified team can answer every question above with evidence.
What you should expect instead is a straight answer to your security questionnaire, item by item, from the actual systems rather than from a policy template, including the items where they do not meet your bar. If your procurement requires a SOC 2 report from every vendor, say so in the first conversation. A good agency will tell you right away whether it fits. We wrote up how we answer enterprise security questionnaires in detail.
The short version
If you have a team that runs production systems, take the code, and insist on infrastructure as code so the handover is real. If you do not, let the builder run it, and use the eight questions to check that they can:
- Is the infrastructure written as code?
- Where do the passwords and API keys live?
- How do people reach the admin tools and the database?
- How does a change get to production?
- How are backups done, and when did you last restore one?
- Who is watching, and how do they find out?
- Where is the data, physically?
- If we leave, what do we take with us?
Our own answers, in full and including what we don't claim, are on our security page. If you are a US company weighing a team in France, this page covers hours, contracts and pricing in dollars.