Why I bet my client work on an all-AWS stack

Most posts about picking a cloud start with a benchmark. This one starts with an honest admission. I went all-in on AWS because it was the option I could actually hold in my head.

I run a studio of one. The client work goes out under WestCo App Studio, the umbrella is Castaneda Networks, and on any given week I’m the architect, the developer, the person on call, and the person reconciling the books. When you’re wearing all of those hats, the thing that kills you isn’t a hard problem. It’s a hundred small ones spread across a dozen accounts.

One roof, one bill

The real reason I went full AWS is unglamorous. The ecosystem is easy to understand when everything is under one roof. I’m not juggling a host here, a database somewhere else, an auth provider on a third platform, and a queue on a fourth. Compute, data, auth, email, storage, networking. It all lives in one console, described in one CDK app, deployed with one CLI.

And at the end of the month, it’s one bill.

That last part sounds like an accounting footnote, but it isn’t. A single unified invoice means I can actually tell, per project, what infrastructure costs. When a client asks “what am I paying to run this?”, I have a real answer, not a scavenger hunt across five billing portals with five different billing cycles.

There’s a newer reason too, one I didn’t expect to matter as much as it does. The AWS CLI is legible to my tooling. When I let an AI coding assistant help me stand up or change infrastructure, it can drive aws and the CDK directly, and I review the result and manage it from there. A coherent, well-documented, single-vendor surface turns out to be exactly what an agent is good at working against. Five bespoke dashboards are not.

The tax I was actually paying

People assume the case against a sprawl of services is some dramatic outage. It wasn’t. For me it was a low-grade tax I paid every single day: keeping five different platforms patched, logged into, and talking to each other.

And, only half joking, five more logins, each with its own MFA prompt.

That’s five more places a credential can leak. Five more dashboards to check when something looks off. Five more vendors whose pricing, terms, and uptime I have to track. None of it is hard. All of it is friction, and friction is the one thing a team of one cannot afford to accumulate. Consolidating onto AWS didn’t make any single task easier. It made the number of things smaller.

Why not the easy buttons

The standard advice for a solo dev is to just use Vercel, or Netlify, or Supabase, on the theory that AWS is too complex for one person. I went the other way, and the reason is scaling and cost.

The easy platforms are easy right up until they aren’t. They’re priced and shaped for the happy path, and the moment one of your apps starts to take off, you hit a pricing cliff or a ceiling on what the platform will let you do. Then you’re re-platforming onto AWS anyway, and you’re doing it mid-success, which is the worst possible time to be ripping out your foundation.

If any of my applications begins to scale, AWS is the proper fit. So I’d rather start there. The thing that scales is the thing I already built. There’s no rewrite waiting for me on the other side of things going well.

What it looks like in a real app

Musicyaa is the clearest example. It’s a talent marketplace, with artists and vendors on one side and the people hiring them on the other, plus a web app and native iOS and Android clients on top. Here’s what’s actually under it:

Lambda is the compute, everywhere. Bookings, payouts, messaging, reviews, reminders, the works. Each one is a serverless function that runs on demand and scales from nothing to a spike without me provisioning or patching a single server.
DynamoDB stores everything. Fully managed, no database box to babysit, and it scales alongside the Lambdas instead of becoming the bottleneck they all wait on.
Cognito handles auth and identity.
S3 holds the media. SES sends the email. API Gateway and a Lambda Function URL expose the endpoints. SNS, SQS, and EventBridge move the asynchronous work around, and CloudFront serves it all at the edge.

One CDK app describes the whole thing. One bill pays for it.

The two things I deliberately kept off AWS

Here’s where honesty beats purity. “Everything under one roof” has two deliberate exceptions in Musicyaa, and the exceptions are the point.

Money goes to Stripe. I’m not going to reinvent payments and payouts, and I’m not going to pretend a homegrown alternative would be safer or simpler than the company that does this for a living.

AI goes to Anthropic directly. Musicyaa has an AI support chat, and it calls Claude through Anthropic’s API rather than through Bedrock. The API key lives in AWS Secrets Manager alongside the Stripe keys, so it’s still managed inside the same account, but the inference itself happens off-cloud, on purpose. Calling the API directly is the simplest path that works today, and simple wins.

The lesson isn’t “AWS for everything, no matter what.” It’s “AWS for the infrastructure, and a clear-eyed exception when a specialist does it better.” Two exceptions, made on purpose, that I can explain in a sentence each. That’s different from accidental sprawl.

The thing I stay paranoid about

If there’s a part of this I lose sleep over, it isn’t downtime. It’s a public, AI-backed endpoint running up a bill.

The support chat is open to the world, and the world includes people pointing scripts at it. The nightmare isn’t the app going down. It’s waking up to a five-figure invoice because someone found my chat endpoint and decided to hammer it. So before that could ever happen, I put a fail-closed cost cap on it, fronted it with a WAF, and added throttling. If usage crosses the line, it shuts itself off rather than spending my money.

That’s the real version of “what I would change.” Nothing about the stack itself, but a standing reminder that anything public and metered needs a hard ceiling before you ship it, not after the bill arrives.

Why this matters for client work

All of this would just be personal preference if it stopped at my own products. But this is client work, and going all-AWS changes three things for the people who hire me.

It helps the pitch. “It runs on AWS” carries weight, even with a non-technical founder. It signals that the thing I’m building for them is on the same infrastructure the serious companies run on, not a hobby host that disappears when it gets popular.

It makes costs legible. Because everything’s on one bill, I can show a client exactly what their app costs to run, clearly, monthly, line by line. No estimating across a pile of subscriptions.

And it gives them clean ownership. If I set a client up in their own AWS account from the start, instead of parking their app inside mine, then they own everything from day one. If they ever want to take it in-house or move on from me, they walk away with the whole thing. No proprietary platform, and no vendor (me) holding their business hostage. For a founder deciding whether to trust a studio of one, that’s not a technical detail. That’s the difference between a partner and a dependency.

That’s the bet. One roof, one bill, two honest exceptions, and a client who owns what they paid for. For a team of one, it’s the only stack I can run without dropping something, and it’s the one I’d build on again tomorrow.