It works on my machine” is not infrastructure
Getting an application to run is one problem. Making sure it keeps running, can be changed safely and can be recovered when something goes wrong is another.
It means the application has a dependable way to run, deploy, observe, secure and recover. The exact architecture depends on the system; the basic responsibilities do not.
On a developer’s laptop, an application gets a lot of help. The right runtime is installed. The database is close by. Environment variables are already configured. Someone knows the one command that starts everything.
Then the application meets production, where “someone knows” is not really a system.
What does a small application actually need in production?
It needs somewhere reliable to run, configuration that can be managed safely, a repeatable deployment path, logs, monitoring, backups and sensible access controls.
A current production-readiness checklist from the UK Ministry of Justice, for example, explicitly calls out monitoring and logging, support ownership, backups with a restore strategy, least-privilege access and avoiding hard-coded secrets. MIT’s production guidance similarly covers health checks, CI/CD, monitoring and restorable backups.
Do you need separate development, staging and production environments?
You don’t need enormous copies of each environment. Separating development, testing, and production reduces avoidable surprises.
A staging environment is particularly useful when a change affects payments, data, integrations, or other behaviour. You can catch these problems before customers encounter them.
How should application secrets be managed?
Don’t store passwords, API keys, tokens, or credentials in source code or share them through chat messages. Instead, supply them through environment-specific configuration or a proper secrets-management system. Limit access to what each component needs.
This is not enterprise theatre. A leaked production credential can turn a small deployment problem into a much larger one.
Do you need CI/CD?
Not every small application needs a complicated pipeline. It does benefit from a repeatable way to test and deploy changes.
As the team grows, Automated checks and controlled promotion from development or staging into production reduce the tribal knowledge your team needs to ship software. MIT’s production-readiness guidance treats automated builds, a documented release process and staging-to-production promotion as part of a mature setup.
What monitoring does a small application need?
Start with the questions you would want answered if a customer called and said, “It isn’t working.”
- Is the service reachable?
- Are requests failing?
- Are response times becoming unusually slow?
- Is a dependency such as the database unavailable?
- Did the latest deployment cause the problem?
Logs explain what happened. Monitoring helps you spot problems as they happen. You generally want both.
How much cloud infrastructure does a startup need?
Usually less than it thinks.
A small application can often run comfortably on a straightforward managed setup. You do not need to introduce containers, Kubernetes, multiple regions and elaborate service meshes simply because larger companies use them.
The architecture should grow when the consequences of failure, traffic, team size, security requirements or operational complexity justify it.
When should you bring in an infrastructure specialist?
A few signs are fairly practical: nobody is confident about how the application is deployed, production changes require one particular person’s laptop, backups have never been tested, incidents are discovered by customers, credentials are scattered around, or the cloud bill keeps growing without anyone knowing why.
Those are not necessarily reasons to rebuild everything. Often they are reasons to spend a little time making the existing system understandable and repeatable.
Frequently Asked Questions
What is the difference between development and production?
Development is where software is changed. Production is where other people depend on it. Production therefore needs stronger controls around configuration, access, deployment, monitoring and recovery.
Do small applications really need monitoring?
Basic monitoring is useful even for small systems. You want to know about availability and major failures before the first customer reports them.
How often should production backups be tested?
There is no universal interval. The important part is that restoration is tested often enough for the business to trust the recovery process and after meaningful changes to the backup arrangement.
Does production-ready mean highly scalable?
No. A production-ready system can be small. It simply needs a dependable operational baseline appropriate to the consequences of failure and the needs of its users.
The boring parts are the product too
Users do not care which deployment pipeline you chose when everything works. They do care when a release breaks their workflow or their data disappears.
Good infrastructure keeps those moments uneventful. That is a fairly unglamorous goal, which is one reason it tends to be a good one.
Related Services
We can help you with these directly.