Deployments

Most teams we meet have “deployment” in the sense of “the code runs in production,” but don’t have the supporting apparatus that turns that into a system somebody would want to operate. CI that catches regressions before they ship. Alerts that fire on things that actually matter. An on-call rotation that doesn’t punish the same engineer every weekend. A security posture that won’t embarrass the company when a customer’s procurement team finally asks.

We set that apparatus up, scoped to where the team actually is. A seed-stage product with three engineers doesn’t need Kubernetes; it needs Vercel previews, a single-region Postgres, Sentry with tuned alerts, and a runbook document that fits on one page. A post-Series-B team probably needs something more involved, but still less involved than the industry narrative implies.

Our default stack skews toward the boring end: Vercel or AWS depending on the problem, Postgres almost always, Cloudflare in front of anything that faces the public internet, GitHub Actions for CI, Terraform for anything we want to reproduce. We’ll work in GCP or Azure when the client’s already there — we don’t migrate for the sake of migrating — but we’re upfront that our depth is deepest on AWS and Vercel.

The engagement ends with a handover, not a dependency. We document what we set up, we train whoever’s going to operate it, and we leave a runbook that explains why each alert exists and what to do when it fires. If you want us to keep operating it, that’s a retainer conversation — but the ship state is always “your team can run this without us.”