Does a small startup with paying customers need a staging environment?
By the Keel team · Last checked · 4 min read
Short answer
A small startup with paying customers usually does need some form of staging, because it is where you check the problems you can predict before customers see them. It does not need to copy production exactly. A small, cheap environment built from the same code as production, plus tests, health checks and automatic rollback, covers most of the value. No staging catches the problems nobody predicted, so keep rollback ready either way.
2017
Year of the Increment article on staging best practices cited here
Source: Increment, Oct 2017
1 image
Built once, deployed to staging first, then promoted to production
Source: This guide
What is a staging environment for?
A staging environment is for checking a change in a place that looks like production before real customers depend on it.
In Increment's article on staging best practices, Alice Goldfuss describes staging as the place to validate the known-unknowns of your systems and build confidence in them by consensus.
The same article is clear about the limit: staging cannot reproduce unknown-unknowns such as real user behaviour and traffic. Only production shows those, which is why staging is a safety step and not a guarantee.
Can good tests replace staging?
Good tests help a great deal but do not replace staging, according to the Increment article, which rejects the argument that you do not need staging when you have good tests.
Tests catch what you thought to test for, while staging shows how the whole system, with its real configuration, behaves together.
The article also makes the point that the best time to build staging is early, before you have customers, when the application is still small and easy to move. A team that already has customers can still do it; it just takes a little more care.
What does a light staging environment look like on AWS?
A light staging environment is a smaller copy of production built from the same infrastructure code, so the two stay alike without extra effort.
It runs the same container images and the same deployment steps, with smaller sizes and test data rather than customer data.
- Build it from the same infrastructure code as production, with different sizes.
- Deploy the same image to staging first, then promote the same image to production.
- Use test data, not a copy of customer data.
- Run it through the same health checks and pipeline.
- Keep it small, and check its cost in your monthly review.
What are the downsides of staging for a small team?
The downsides are cost, upkeep and false confidence.
Increment's article warns that staging environments can sometimes make products less stable and reliable, and that they start out slick and end up stodgy when teams underinvest in them.
A staging environment that drifts away from production, runs on old data or is always broken teaches the team to ignore it. If you cannot keep it honest, a smaller, simpler version that you do keep honest is better than a grand one that you do not.
What should you rely on if you skip staging?
If you skip staging, rely on automatic checks and automatic rollback so a bad release reverts before customers notice.
On Amazon ECS the deployment circuit breaker can roll a failed deployment back, and load balancer health checks stop traffic reaching unhealthy tasks.
Rolling back an ECS deployment automatically from GitHub Actions and what a deployment health check should test show how to set that up. Database changes need extra care, as in rolling back after a database migration, because code can revert and data cannot.
How should a small team decide?
Decide by how costly a bad release would be and how well you can recover from one.
If a mistake touches payments, customer data or a contractual commitment, build a light staging environment. If your changes are small, behind flags and quick to undo, strong rollback may be enough for now.
Either way, make the choice on purpose and write it down. How small SaaS teams ship on AWS without breaking production gives the wider picture, and whether it is safe to deploy on a Friday covers timing.
Can a very small team get a safe release setup without hiring?
A very small team can get a safe release setup without hiring through Keel's Startup programme, a foundation-level service for small teams already live with paying customers.
It includes a deploy pipeline with rollback, tested backups, monitoring and monthly patching, in your own AWS account, with a monthly check-in with a Keel account manager.
It is for teams of fewer than 5 at pre-seed to Series A, live in production with at least one paying customer, on AWS with code on GitHub or GitLab. Places are limited and awarded on merit. If that sounds like you, apply for a place in the pricing section.
Is your release safety net strong enough?
Tick each item that is true today.
- Each change is checked somewhere before customers see it.
- Staging, if you have it, is built from the same code as production.
- Staging uses test data, not customer data.
- A failed deploy rolls back without a person.
- Database changes have a plan for going back.
- You have written down why you do or do not have staging.
Decision point: Five or six ticks: releases are well protected. Three or fewer: the next bad release will reach customers.
Sources
- Increment, Center stage: Best practices for staging environments (Alice Goldfuss, issue 3, October 2017) (October 2017)
- AWS docs, How the Amazon ECS deployment circuit breaker detects failures (checked October 2026)
- AWS docs, Health checks for Application Load Balancer target groups (checked October 2026)
Keep reading
Keel is an AWS release and recovery operations service for SaaS teams of 3 to 15 developers, provided by Bargainn Services Ltd, a UK company registered at Companies House (16497746). Registered office: 3rd Floor, 86-90 Paul Street, London, EC2A 4NE, United Kingdom.