Why getting to production still takes too long

There is a particular kind of frustration that every product engineer has felt and few have named. The application works. The tests pass. The feature you have been building is done, sitting there on your machine, doing exactly what it is supposed to do. And it is still not in front of a single user, because now begins the part of the job that has nothing to do with the product you just built. Now you have to get it to production, and getting it to production has somehow become a project of its own.

If you are a product engineer with an application that is ready to ship, and you are staring down the work of standing up a production environment, or weighing AWS against Google Cloud and trying to plan out pipelines and databases and environments before you can deploy, this is written for you. If you are learning cloud infrastructure as a skill, or setting up a side project you are in no hurry to launch, it is not. I am talking to the people who have something real and finished, and cannot understand why shipping it is taking this long. The reason is worth stating plainly, because it is the whole problem. Getting to production takes too long because your team treats production as something you build before you can deploy, rather than something that already exists and you deploy into. Sevalla is built on that second idea, and the difference between the two is most of the delay you are feeling.

The gap between "it works" and "it is in production"#

Let me be precise about where the time actually goes, because it is easy to misattribute. When a launch slips, people assume the code took longer than expected. Sometimes it did. But on a great many teams, the code was done days or weeks before anything reached users, and the gap between "it works" and "it is in production" was filled entirely with infrastructure work.

Finishing the application is not what stands between you and your users. What stands there is everything you decided you must assemble before the application is allowed to run: the place for it to live, the services it depends on, the machinery to deploy it. None of that is the product, all of it is front-loaded, and every day it takes is a day a finished feature sits where no user can reach it.

Everything you build before you ship anything#

Walk through what "getting to production" actually asks of you the first time. You choose a cloud provider, which is itself a decision people agonize over for days. You provision compute, and now you are reasoning about instance types and regions. You set up the database, configure its networking, and lock down access. You work out how the application will be deployed, which means writing a pipeline, which means storing credentials, wiring build steps, and handling the difference between staging and production. You configure secrets. You define environments. You set up TLS. You arrange logging so that when something breaks you will be able to see it.

Look at that list and notice something. Not one item on it is your product. Every one is a precondition you imposed on yourself by deciding that production is a thing you build. You did not write that infrastructure to serve a user. You wrote it to earn the right to serve one, and the earning takes weeks.

To be fair, that is sometimes the right call. A team with strict compliance boundaries, genuinely unusual infrastructure needs, or a scale where the economics demand it may have real reasons to assemble and own its own production. But most product teams are not that team. Most are building a standard web application where the assembly buys nothing except delay, and the precondition they are paying for is one they invented rather than one the work required.

"Production ready" has quietly come to mean "infrastructure assembled"#

Somewhere along the way, a phrase got redefined, and the redefinition is doing quiet damage. "Production ready" should describe your application: the code is tested, the behavior is correct, the thing is fit for real users. That is a statement about the product. But listen to how teams actually use it. When an engineer says they are getting the application production ready, they usually mean they are building the infrastructure to run it, the pipeline, the environments, the provisioned services. Readiness stops being a property of the software you finished and becomes a property of a platform you have not built yet, so the launch waits on the platform.

The cost is not abstract. It is a launch that lands weeks late, the momentum lost while a finished feature sits idle, the thing you wanted to learn from real users going unlearned because real users cannot reach it yet. Time to value is the number that matters for a product team, and this redefinition runs it up before a single user has seen anything.

Getting faster at setup is not the fix#

Here is the move almost everyone reaches for once the delay becomes obvious, and it is worth seeing why it does not solve anything. The instinct is to get faster at the setup. Keep a starter template around. Build a reusable Terraform module. Copy last project's pipeline and adjust it. Bring in someone who can stand the whole thing up quickly. Each of these shortens the assembly, and none of them questions the assembly.

That is the trap. Making infrastructure setup faster still leaves you setting up infrastructure. The template goes stale and needs maintenance. The Terraform module becomes its own thing to own. The copied pipeline drags along assumptions from a project it was not written for. You have optimized the step instead of removing it, and the step was the problem. The delay does not come from assembling infrastructure slowly. It comes from assembling infrastructure at all. The only fix that actually changes the timeline is to remove the assembly, so that production is not a project you run before you ship, but a default you deploy into the moment your code is ready.

What it looks like when production already exists#

Here is what shipping looks like when production is a place rather than a project, a Laravel 13 application on PHP 8.5 deployed on Sevalla. This is the whole of what you provide:

app:
  name: my-laravel-app
  runtime: php
  version: "8.5"
 
build:
  buildpacks: true
  run:
    - composer install --no-dev --optimize-autoloader
    - php artisan config:cache
    - php artisan route:cache
    - php artisan view:cache
 
workers:
  - name: queue
    command: php artisan queue:work --sleep=3 --tries=3
 
crons:
  - name: scheduler
    schedule: "* * * * *"
    command: php artisan schedule:run
 
environment:
  - APP_ENV=production
  - LOG_CHANNEL=stderr

Notice what is not there. There is no cloud to choose, no compute to provision, no pipeline to write, no environments to define from scratch, no TLS to arrange, no networking to configure. Those things already exist, because the platform is production and you are deploying into it rather than building it. Your team deploys from Git. Sevalla handles runtime orchestration, networking, scaling, failover, observability, and deployment workflows behind the platform boundary. The managed database is there when you connect it. The pipeline is there the first time you push. The environments behave like production because they are production.

So the first deploy is not a project with a timeline and a set of decisions to agonize over. It is a Git push. The gap between "it works" and "it is in production" collapses to the length of a build, because there is no infrastructure to assemble in between. That is what it means for production to already exist. The precondition you used to spend weeks satisfying is simply gone, and the finished application goes to users the moment it is finished.

One thing worth being clear about, because it is the reasonable worry for any serious team: deploying into production rather than building it does not mean giving up visibility or control. You still see production. Logs and metrics are unified and built in, so you can watch how the application behaves under real traffic without assembling a stack to capture it, and the platform is drivable from a dashboard, a full CLI, and a REST API when you want to inspect or act on it directly. And you still control the things that are actually yours: your application's code and configuration, what it needs to scale, how it behaves in production. What you give up is not oversight of your product. It is the work of operating the infrastructure underneath it, which is the part you never wanted to be watching in the first place.

Stop building production. Deploy into it.#

Here is the reframe to carry out of this. The delay you have been treating as the natural cost of getting to production was never that. Production is not inherently slow to reach. What was slow was building production yourself, before you were allowed to ship. For a team that genuinely needs to own its infrastructure, that cost may be worth paying. For a standard product team, it is not a law of nature, it is a consequence of one assumption: that the environment to run your application is something your team assembles.

Drop that assumption and the timeline changes immediately. When production already exists, getting to it is a deploy, and a deploy is minutes. So the honest next step, the one that actually tests this, is to stop planning your infrastructure and deploy something into a platform where the infrastructure is already there. Take the application that is sitting finished on your machine, push it to Sevalla, and time how long it takes to reach a real URL serving real traffic. That number is what getting to production actually costs when you are not building production first. Measure it once, and you will not go back to assembling it by hand.