Why our stack runs on AWS
Earlier this fall we finished moving our own stack off Vercel and onto AWS. The marketing site, this blog, and our production apps now run on infrastructure we control end to end. It was not a dramatic migration. It was a deliberate one, and the reasons behind it are worth spelling out, because the same decision faces every builder who outgrows their first hosting setup.
What runs where
- Marketing site and blog: static HTML served from S3 behind CloudFront. A page is a file. There is no server to keep awake, no framework runtime to patch for a brochure page, and the cache does the heavy lifting.
- Production apps: AWS Amplify. Our CRM lives there, and it is where app deploys go.
- Data: Postgres hosted on AWS, reached through PostgREST clients. Migrations run when we ask for them, not automatically on every merge. That one rule has saved us from more than one bad morning.
- Content: Markdown in a repo, compiled to static pages. We own the words outright, and a post doubles as material for other channels.
Nothing here is exotic. That is the point.
Why we moved
One bill, one identity model, one place to look. When the site, the app, and the data live under one provider, there is one place to check when something breaks, one access model to get right, and one bill to read. Every extra platform is another dashboard, another set of credentials, and another vendor whose pricing change becomes your problem.
Static where static works. Most of a marketing site never changes between deploys. Paying for a server to re-render it on every visit is paying for work nobody asked for. S3 plus a CDN is boring, fast, and cheap at our scale, and boring is a feature when the page just needs to load.
Control over the deploy path. Our deploy is a checklist, not magic: build, upload, invalidate the cache, verify live. We can see every step, and when a step fails we know exactly which one. A platform that hides the deploy also hides the failure, and you find out about it from a customer instead of a log.
No lock-in on the content layer. If a hosting vendor changes its terms tomorrow, our pages are still files in a bucket and our posts are still Markdown in a repo. Portability is not a theory for us. It is the shape of the system.
What we gave up
Honesty requires the other side of the ledger. Vercel's developer experience is genuinely good. Instant previews, zero-config deploys, and a dashboard that stays out of your way are real conveniences, and we gave them up. AWS takes more setup up front. You own more knobs, which means you own more ways to misconfigure something. Our answer to that is checklists and staging proof before anything touches production, not pretending the knobs do not exist.
We also gave up the comfort of letting someone else own the hard parts. That trade only makes sense if you are willing to learn the parts you now own. We were, and our work is infrastructure-flavored anyway. A team that never wants to think about infrastructure should not copy this choice blindly.
The rule we use now
When we pick a home for something new, we ask in this order:
- Can it be a static file? If yes, it is a static file.
- Is it an app with users and state? Then it goes on Amplify, with data in Postgres we control.
- Does the tool earn its place by doing something we cannot do simply ourselves? If not, we do not add it.
That rule keeps the stack small. A small stack is one a two-person team can actually operate, secure, and debug at midnight, and that matters more to a service business than any single feature a platform advertises.
What this means if you are not a builder
You do not need to care about S3 or Amplify. Here is the version that applies to your business: pick infrastructure you, or someone you trust, fully understands, and be suspicious of any setup where you cannot explain where your website, your customer data, and your bill each live. The cheapest hosting decision is rarely the one with the lowest sticker price. It is the one you can operate without surprises.
We build client systems the same way we build our own: boring where boring works, managed where it earns it, and nothing added that we cannot explain and operate. That is not a philosophy. It is just what has held up in production.