A one-app startup does not need a DevOps hire. DevOps for startups at that size is 13 controls, from three environments and a check on every pull request to a rehearsed rollback. In at least 17 of the 21 third-party apps I audited in June and July 2026, every push ships straight to production with nothing checking it first.
What DevOps for startups covers when you have one app
DevOps for a startup with one app is 13 controls: three environments, a protected production branch, CI on every pull request, staging with a promotion gate, migration-aware deploys, a rehearsed rollback, preview deployments, a contribution guide, automated dependency updates, a timed deploy, a repository and hosting you own, feature flags, and domain, DNS and TLS hygiene.
Those 21 apps are a selected set of third-party apps I audited, not a random sample, so the 17 describes them and is no rate for AI-built apps in general. All 5 of my own apps had no deploy gate either. This area holds 13 of the 123 checks in production hardening, and it answers one of the questions every hardening pass asks: how fast you recover from a failed release.
For a startup, CI/CD is the part that runs on every push, and SaaS deployment is the moment the result reaches the people who pay you. Whatever deployment best practices a startup collects, from a vendor blog or a Reddit thread, each one is worth keeping only if you can test it against your own app, which is why every control below comes with a test. If you want the smallest version first, the staging article in the table’s first row ends with a minimum safe deploy pipeline for a one-person team, and I do not repeat it here.
| Control | What it is | Why it matters | Page to open |
|---|---|---|---|
| 1. Three environments | Development, staging and production, kept apart | Routine tests should not change real customer records or trigger live transactions | what is a staging environment |
| 2. Protected production branch | Nothing merges into main without passing checks | Unchecked changes can otherwise bypass the release process | GitHub branch protection |
| 3. Pull-request CI | Lint, typecheck, build and tests run on each change | Automated checks catch regressions before changes reach customers | CI/CD best practices |
| 4. Staging, then promotion | Staging updates on its own; production waits for a decision | A repeatable release path removes reliance on one person’s manual routine | release readiness checklist |
| 5. Migration-aware deploys | Schema changes ship with the code, in order | Application code can fail when its expected schema is missing or incompatible | how to run database migrations on deploy |
| 6. Rehearsed rollback | A way back that has been walked, data included | A failed release needs a recovery path the team has already practiced | what is a rollback plan |
| 7. Preview deployments | Its own browser URL for each pull request | Reviewers need to inspect a change before it joins the release branch | what are preview deployments |
| 8. Contribution guide and PR template | How to propose a change, written down | Consistent review information makes future development easier to assess | GitHub branch protection (row 2) |
| 9. Automated dependency updates | Package upgrades arrive as reviewable pull requests | Routine security and maintenance updates need a repeatable path to review | what is Renovate bot |
| 10. Timed deploy | A release with a known duration | A slow release process delays delivery of urgent fixes | how to speed up CI build times |
| 11. Your own repository and hosting | The app lives outside the tool that wrote it | An app that only exists inside the builder tool cannot be reviewed, rolled back, or handed to another engineer | how to self host an exported app |
| 12. Feature flags | A switch per risky feature | The fastest fix for a broken release is switching the feature off | open source feature flags |
| 13. Domain, DNS and TLS | The name and the certificate stay valid and owned | An expired domain or a misissued certificate is an outage no code fix repairs | add HTTPS to website |
What is DevOps in simple terms? The words for a team that ships one app
DevOps, in simple terms, means the people who write the code also ship and run it, with automation doing the repeatable steps. For a team with one app the tool chain is short, in my working list: a git host, a CI runner, a hosting platform, an error tracker and an uptime check.
That definition is mine, and it holds whether you ask what DevOps is in IT or what it means in software development: one habit, applied to one product. With these habits in place a release becomes a routine job on an ordinary weekday, one nobody has to be brave for, and that is why DevOps is worth the setup for a founder. The words below are the ones worth knowing, in the sense they carry for one app. The deploy words themselves (deploy, build, release) have their own page, what deploy means in software.
| Word | What it means for one app |
|---|---|
| DevOps | Whoever builds the app also releases and runs it, and the repeatable parts are automated |
| DevOps tools | The five in the answer above, one per job in my working list: code, checks, hosting, errors and uptime. The long list of DevOps tools you see elsewhere is, in my reading, for platform teams running many services |
| SRE | The reliability half. The difference between DevOps and SRE is that SRE treats uptime as its own engineering job with its own targets, in my reading, which a one-app team folds into DevOps; the role itself is a separate question: what is a site reliability engineer |
| DevSecOps | DevOps with security checks built into the pipeline; that is the whole difference in DevOps vs DevSecOps, covered in CI/CD security best practices |
| DevOps fundamentals | Three, in my reading: everything in git, every change checked, every release reversible |
| DevOps anti-patterns | The two worth naming: pushing straight to main, and changing production directly in a dashboard or console |
Which is an example of PaaS? IaaS, PaaS and SaaS for where your app runs
A PaaS runs your code while the provider manages the machines, and the host your app already deploys to is the likeliest example: Vercel, Railway, Render, Netlify or the builder’s own hosting. IaaS is a raw server where you also manage the operating system. The SaaS is the product you sell.
My definition of PaaS in cloud computing, and the meaning of PaaS used on this page, is a platform that takes your code and runs it while someone else keeps the servers patched and scaled. The table below sets examples for SaaS, PaaS and IaaS side by side for one app. Its examples of platform as a service in cloud computing are my classification, not the vendors’ own descriptions. Choosing where the app should run is covered in the deployment target comparison, what the bill buys in what the Vercel price actually covers, and what a hosting environment holds, its variables and its database, in environment variables explained.
| Model | Examples for one app | What you manage | What the provider manages |
|---|---|---|---|
| IaaS | A raw server or virtual machine you rent | The operating system and everything above it: runtime, web server, app, patches | The hardware and the network |
| PaaS | Vercel, Railway, Render, Netlify, the builder’s own hosting | Your code and its configuration | The servers, the operating system, the runtime and scaling |
| SaaS | The app you sell to your customers | Your customers’ accounts and data | For your customers, you are the provider: everything |
What does IaC stand for? Infrastructure as code, and why a managed-platform app has little of it
IaC stands for infrastructure as code: servers, networks and permissions written as files and applied by a tool. An app on Vercel and Supabase has little of that to manage. What it keeps in code instead is the CI workflow, the migrations, the environment inventory and a DNS export.
In practice, infrastructure as code means a server exists because a reviewed file says it should, with the same history and review as the application. IaC is one of the practices DevOps teams use, so it counts as part of DevOps; that is my reading.
The infrastructure as code tools people usually mean are Terraform and OpenTofu, whose docs each call them “an infrastructure as code tool”, Pulumi, whose docs describe an “open source infrastructure as code SDK”, and AWS CloudFormation, which its user guide describes as “a service that helps you model and set up your AWS resources” from a template. In my reading they are for the day an app leaves a managed platform. Until then there is little for IaC automation, or the IaC solutions built on those tools, to describe, and the one piece of infrastructure a Vercel plus Supabase app should still export is its DNS records, which is control 13.
What goes wrong without it
Every push goes straight to production
A small mistake reaches customers the moment it is pushed, and the first person to test it is someone who pays you. Without a protected branch and checks on each pull request, a change can skip every step between the editor and the live site, as rows 2 and 3 of the table put it. That was the state of at least 17 of the 21 apps in the opener. In the same audits, at least 18 of the 21 third-party apps had no working test anywhere: 17 with literally none, plus one app whose checkout “test suite” never executed the actual checkout code. So a gate would often have had nothing to run, in my reading. Start with the GitHub branch protection and CI/CD best practices pages, both linked in the table.
A migration runs before the code that needs it, or after
The deploy goes green, then every page that reads a new column throws an error, or the old code keeps running against a table that has already changed. The cause is ordering: code can break when the schema it expects is missing or no longer matches, which is the table’s fifth row. The order that works is a separate question, named in that row, and what undoing a schema change does and does not reverse is in what a Supabase migration rollback actually reverses.
The rollback has never been tried
A release breaks sign-in, someone asks how to go back, and nobody on the team has ever done it. A recovery path first walked during the outage is slower and riskier than one practiced on a quiet afternoon, which is the point of the table’s sixth row. The plan to write before you need it is on the rollback plan page in that same row. The host’s own steps, and why they leave the database where it is, are in how to roll back a deployment on Vercel or Netlify.
Previews and staging share the production database
A test signup made on a preview link shows up in the live customer table. In one app I audited, an AI coding workspace had one database project for everything. Its host made a preview per branch, but nothing pointed any preview at a separate database, so previews would share the one live database and schema changes had nowhere safe to fail first. The lesson I take from it: a preview is only as safe as the database it points at, so the first environment worth building is a second database, before the second pipeline. Rows 1 and 7 of the table name the two controls involved. The mechanics are on the preview deployments page from the table, and the settings to check are in what a preview isolates.
The app only deploys from inside the builder
The only way to ship a fix is the publish button inside the builder, and no one outside that tool can see the code. An app in that state cannot go through review, cannot be rolled back on your terms and cannot be handed to another engineer, as row 11 says. What each builder lets you take with you is in can you export your code from an AI app builder. Running the exported app on your own account is the subject of the self-hosting page in that row.
The certificate lapses and the browser says so
Visitors get a full-page security warning before your app loads, and nothing in the code has changed. A domain that expired or a certificate issued wrongly takes the site down in a way no deploy can fix, which is row 13’s point. Setting HTTPS up so it renews itself is on the HTTPS page it links to. Why a valid certificate matters to anyone listening on the connection is a separate topic: man in the middle prevention.
The 13 controls, one by one
1. Three environments, three databases
Development, staging and production each run with separate databases, credentials, and configuration. The test: verify service isolation and perform a staging action without a production side effect. On Supabase, the Free Plan grants “two free projects”, and development can run on “the locally running Supabase stack”, which needs the Supabase CLI and a container runtime, per Supabase’s billing page and its local development guide. So a Free Plan app keeps staging and production as its two projects, in my reading. The staging article linked in the table covers the setup.
2. The production branch is protected
The main branch takes merges only with required checks and controlled merge permissions. The test: attempt a failing merge and confirm the protection prevents it. GitHub’s page on protected branches says “Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations”, and in private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud and GitHub Enterprise Server; rulesets have the same split for private repositories. By default a rule’s restrictions “don’t apply to people with admin permissions to the repository”. On a one-person repository, apply the rule to administrators too, or the owner’s own account can still merge a failing change and the test fails; that is my reading of the default. And while the app still ships from the builder’s publish button, a protected branch gates nothing until control 11 moves deploys into the pipeline. The GitHub branch protection page has the settings.
3. Every pull request runs lint, typecheck, build and tests
The pipeline runs linting, type checks, builds, and tests on every pull request. The test: submit failing and passing changes and retain the CI results. Retaining them matters: keep the link to the red run and the green run, because a check you cannot show failing once has not been shown to work. A build step that switches off its own type or lint checks passes in name only, so read the build command as well as the result. The CI/CD best practices page covers the workflow, and CI/CD security best practices cover the secrets and permissions it runs with.
4. Staging deploys automatically; production is a promotion
Staging deployment is automated, and production requires an explicit promotion step. The test: deploy a change to staging, then demonstrate the production promotion gate. The gate can be small, one approval before a build that already ran on staging goes live; what matters, in my reading, is that production never receives a build staging has not seen. What to check before pressing it is in the release readiness checklist, and the full pre-release list is the production deployment checklist.
5. Migrations are part of the deploy, in the right order
Database migrations run inside the deployment process, with ordering and compatibility checks. The test: deploy a representative schema change and verify sequencing and failure handling. The safe order, in my reading, is additive first: add the new column, ship the code that uses it, and remove the old one in a later release, so the old and new code can both run against the schema for a while; the migration rollback article linked in the migration section above walks through this expand-contract sequence. A failed migration should stop the deploy before it leaves half a schema behind. The how to run database migrations on deploy page has the steps.
6. A rollback has been rehearsed, database half included
Release rollback is documented and rehearsed, including how database changes are handled safely. The test: roll back a test release and verify application behavior and retained data. In my reading, the code is the easier half; the data needs the thought, because rows written by the new release stay in the database after the old code returns. Rehearse on staging, write down what you did and how long it took, and keep that note next to the runbook. The rollback plan page has the template.
7. Every pull request gets a preview URL
Each pull request gets a browser-accessible preview deployment with isolated test configuration. The test: open a preview from a test pull request and verify its environment isolation. Isolation is what the test is for. A preview that reads the production database, or sends real emails with production keys, is a second production with no protection at all; the database half of that is the finding in the previews section above. Check which database URL and which API keys the preview actually loads. The preview deployments page walks through the settings.
8. There is a contribution guide and a PR template
The repository has a short contributing guide and a template covering the change, verification, and release considerations. The test: create a pull request using the template and follow the guide on a clean checkout. The clean checkout is the useful part: a guide that only works on the laptop that wrote it has not been tested. For a one-person team the template also works as a checklist for yourself, filled in before the merge. Branch rules that pair with it are on the GitHub branch protection page.
9. Dependency updates arrive as pull requests with checks
Renovate, Dependabot, or an equivalent proposes dependency updates with checks. The test: verify an update proposal triggers the appropriate CI checks and review requirements. An update pull request that skips CI is worse than none, because it looks reviewed. The point is that a security patch arrives as a change you can test and merge like any other. The page on what is Renovate bot covers the setup and the grouping rules.
10. The deploy has been timed
The deployment pipeline is optimized and documented to complete a representative release in under ten minutes. The test: time the agreed deployment path and record its start, finish, and included steps. Time the whole path from merge to live, the build included. A slow release is a slow fix, and the moment you need a fast one is the worst moment to learn how long it takes. How to speed up CI build times covers where the minutes usually go.
11. The repository and the hosting are yours
The application lives in a version-controlled repository and on a hosting account the founder controls, deployable through a documented pipeline, independent of the tool that generated it. The test: deploy a fresh clone to staging through the pipeline with no step that depends on the generating tool. This control comes first in practice, because every other test here needs a pipeline you own. What each builder lets you take out is in the export article linked in the builder section above, and how to self host an exported app covers the move.
12. Broken features can be switched off without a deploy
A flag mechanism covers risky features and third-party dependencies so any one of them can be turned off without a deployment. The test: disable a flagged feature in production and confirm the product stays usable with the feature hidden. The second half of that test is where flags fail: the feature disappears and takes the page with it. Flag the payment provider, the AI call and any new flow, and check each one off on staging first. The open source feature flags page compares the options.
13. Domain, DNS and TLS are in order
The setup enforces HTTPS everywhere with HSTS and a CAA record, locks the registrar, documents the DNS records, and confirms renewal ownership. The test: pass an external TLS scan at the top grade and file a DNS record export in the runbooks. The CAA record has to permit the certificate authority your host issues from, or the host’s next issuance or renewal is blocked; that is my reading, and Vercel’s guide puts its own case as “A CAA record that doesn’t permit Let’s Encrypt blocks issuance”. The add HTTPS to website page has the steps.
How to verify the whole area in an afternoon
Verifying this area takes 13 tests and, as my working estimate, about an afternoon. They include a fresh clone deployed without the builder, a staging action with no production side effect, a failing merge refused, a preview opened, a schema change deployed, a release rolled back, a feature switched off and a TLS scan.
This is my working order for a one-person team. Each line points back to its control above, where the full test is, and says what to keep as proof.
- 01 Control 11 first: a fresh clone deployed to staging with no builder step. Keep the pipeline run
- 02 Control 1: one staging action, with production checked unchanged afterwards. Keep what you did and what you checked
- 03 Control 2: a failing change refused when the owner's own account tries to merge it. Keep the refused merge
- 04 Control 3: a failing and a passing pull request. Keep both CI run links
- 05 Control 8: the template used on a clean checkout. Keep the pull request
- 06 Control 7: a preview from a test pull request, with its database and keys checked. Keep the preview's settings
- 07 Control 4: a change on staging, then the promotion gate. Keep the approval record
- 08 Control 5: a representative schema change through the deploy. Keep the deploy log
- 09 Control 10: the deploy timed from merge to live. Keep the start, the finish and the steps
- 10 Control 6: a test release rolled back with its data retained. Keep the timings and the row counts
- 11 Control 12: a flagged feature switched off in production. Keep the page as it looked with the feature hidden
- 12 Control 9: a dependency update pull request and the checks it triggered. Keep the pull request
- 13 Control 13 last: the TLS scan and the DNS export. File both in the runbooks
The same kind of list for every other area of the app is the full production readiness checklist.
Where the sprint stops
The Production Hardening Sprint covers one codebase. We work inside your existing codebase, and your app’s current framework and hosting setup are our starting point. Hosting, paid tools and API usage are paid through your accounts, and we explain any required costs before enabling them.
Where the sprint does this
Area 7 of the sprint is these 13 controls, 13 of its 123 deliverables. We deliver each one as its section above describes and check it with the test quoted there. Every result is recorded with its verification evidence in the production readiness report, which accounts for all 123 IDs, keeps failures visible until resolved and explains genuine non-applicable items. Each control’s entry is in area 7 of the published scope.
Common questions about shipping one app safely
What are the top 5 deployment strategies?
The five I would name are recreate, rolling, blue-green, canary and feature-flagged releases; the list is mine, and the names are general vocabulary rather than one vendor’s terms. Recreate stops the old version and starts the new one. Rolling replaces instances a few at a time. Blue-green runs two full copies and switches traffic between them. Canary sends a small share of traffic to the new version first. Feature-flagged releases ship the code dark and turn it on with a switch.
For one app on a managed host, my working rule is the host’s own deploy plus a flag for each risky feature, which is control 12. The choice between blue-green and canary is a question for the release readiness checklist page.
Is IaC part of CI CD?
IaC and CI/CD are related, and they do different jobs: CI/CD runs the checks and the release, and IaC describes the servers the release lands on. A pipeline can apply IaC files as one of its steps. An app on a managed platform often has no IaC files to apply, so its CI/CD is the whole story; that is my reading.
Is CI CD just GitHub?
No. GitHub Actions is one CI runner among several, and GitHub’s own description of GitHub Actions calls it “a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline”. The practice is control 3, checks on every pull request, and it is the same wherever the runner lives.
What are the four stages of CI CD?
In my words the four stages are build, test, deliver to staging and deploy to production. Build and test are control 3, run on every pull request. Delivery to staging and the deploy to production are control 4, with the promotion gate between them.
Is Kubernetes an IaC?
Not by its own description. The Kubernetes overview calls it “a portable, extensible, open source platform for managing containerized workloads and services that facilitate both declarative configuration and automation”, and the term infrastructure as code does not appear on that page. Its declarative configuration is close to IaC in spirit, and whether that counts is a naming question, in my reading. A one-app team on a managed host needs neither.
If you have a working app built with these tools and need it ready for real customers, this is what we do.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase