·3 min read·9Tech Team
Shipping to Production in Week One: What Actually Has to Be True
A working deploy on day five is not a vanity target — it is the fastest feedback loop your project will ever get. Here is our week-one checklist.
Half the projects we take over have been in "internal dev" for months. No one outside the team has touched it. The first production deploy happens around the same time marketing gets involved, and by then, everything is theoretical.
We ship to a real production URL in week one. Not a demo environment. Not a password-gated preview. Production, with a real domain, real TLS, real logs, real backups.
This sounds aggressive. It is not. It is the cheapest feedback loop the project will ever have.
What must be true by Friday of week one
Not a demo. Not scaffolding. A real deploy:
- Real domain on HTTPS. Customer-facing name, valid cert, HSTS on.
- Automated deploy on merge to main. No one is SSHing into a box.
- Health check that alerts somewhere. A channel that a human reads.
- Rollback path known and tested. Usually: redeploy previous image, two-command max.
- Database migrations versioned. No "I ran this SQL by hand" Slack messages.
- Error tracking wired. Sentry, Logtail, or equivalent — not
console.error. - One real user flow works end-to-end. Usually sign-up and a single primary action.
That is it. Not comprehensive. Not feature-complete. Just alive.
What does not have to be true
You don't need the full feature set. You don't need production data. You don't need perfect UX. You don't need load testing. You don't need multi-region.
All of those are week-six problems. Do not do them in week one.
Why so early
Three reasons.
1. Deployment is infrastructure debt
Every week a project goes undeployed, the deploy pipeline gets harder. "Real" environment differences — DNS, secrets, CDN behavior, database networking — accumulate silently until someone tries to ship in month three and discovers that nothing works.
Deploying on day five means those problems surface when the codebase is small enough to fix them cheaply.
2. Feedback needs a real URL
A stakeholder reading a Figma file does not give you the same feedback as a stakeholder clicking a real button on a real phone. They notice different things. They raise different concerns. They commit to different decisions.
Give them the real URL early. Every week you delay is a week of "oh I didn't realize..." that will cost you in later refactors.
3. The team calibrates differently
Engineers who are shipping to production on day five write code differently than engineers who are not. Less hand-waving, more observability, tighter commits. The shipping discipline forms early and compounds.
Our default week-one stack
For a typical engagement, we stand up:
- Hosting: VPS (DigitalOcean, Hetzner) with EasyPanel or Coolify, or a PaaS like Railway/Fly for smaller projects
- CDN + WAF: Cloudflare Free tier — orange cloud on everything customer-facing
- Database: Managed Postgres (Supabase, Neon, or the VPS provider's offering)
- Error tracking: Sentry or Logtail
- Uptime: A simple cron-driven endpoint check — sometimes just a PostHog alert
- Analytics: PostHog or Plausible
- CI: GitHub Actions, deploy on push to main
None of this is fancy. All of it is proven. We reach for something fancier only when a specific requirement demands it.
What this is not
This is not about shipping a half-baked product to customers. It is about shipping a half-baked product to a production URL. Who sees that URL is a separate decision — you can gate behind auth, behind Cloudflare Access, behind a beta flag. The point is that the pipeline works.
By the time you are ready to let customers in, the infrastructure has been running and evolving for weeks. That is the state you want to be in.
Want help getting a real deploy by Friday? Send us the brief.