Why I Don't Use AWS, Bubble, or Replit — And Why That's Better for You

When I first started building software, my nephew — who's a software engineer — told me I should use AWS. It's what the real companies use, he said. Enterprise-grade. Scalable. The gold standard.

So I did what any finance professional would do: I researched it. And what I found was a platform that required real coding knowledge just to configure, a pricing model so complex it needed its own calculator (never a good sign), and horror stories from startups who woke up to surprise $4,000 monthly bills because they misconfigured a single setting. One founder described it as "trying to drive a Formula 1 car to pick up groceries." I love my nephew. He was not wrong — for his world. But for the businesses I serve, AWS is like bringing a fire truck to blow out birthday candles.

That research rabbit hole — and about twenty more like it over the past two years — is why I build the way I build. No buzzwords. No overengineered stacks designed to impress technical reviewers. Just tools that work, priced fairly, chosen for one reason: they're the best option available right now for the business problem at hand.

The buzzword stack vs. the honest stack

Here's a fun game. When someone pitches you a software project, count how many times they mention AWS, Kubernetes, Docker, microservices, or "cloud-native architecture." The number is directly proportional to how much they're going to charge you and inversely proportional to how much they've thought about whether you actually need any of it.

AWS is a phenomenal platform — for Netflix. For a company processing millions of concurrent requests across global regions with five nines of uptime requirements. For your SaaS product serving 500 customers? It's massive overkill with a pricing model that punishes you for not being a cloud infrastructure expert. I've talked to founders who couldn't predict their monthly AWS bill within $2,000. That's not a technology problem — that's a financial controls problem, and after 25 years in FP&A, unpredictable costs make me physically uncomfortable. Vercel gets you the same result for $20 a month, and the bill is the same every month. I like predictable.

Bubble is a no-code platform that lets you build apps without writing code. Sounds great until you need to do literally anything the drag-and-drop interface doesn't support — which happens approximately two weeks into any real project. Then you're stuck. You can't export your code (because there isn't any). You can't migrate to a real platform without rebuilding from scratch. You've built your business on someone else's toy, and now you're at the mercy of their product roadmap. I've seen this movie. It doesn't end well.

Replit is a browser-based coding environment that's become popular with the vibe coding crowd. Type a prompt, get an app. It's genuinely impressive for prototypes and learning. It is not where you run a production business that processes payments, stores user data, and needs to be online when your customers need it at 6 AM on a Tuesday. Different tools for different jobs. A Swiss Army knife is great for camping. You don't use one to build a house.

What I actually use (and why)

My stack isn't sexy. It doesn't look impressive on a pitch deck. It just works, it's affordable, and I can swap any piece of it tomorrow if something better comes along.

Total monthly cost: roughly $100-150. For the same capability that agencies package as a $150,000 "technology foundation." The tools aren't cheaper because they're worse. They're cheaper because cloud economics made enterprise-grade infrastructure available to everyone, and I don't add a 300% markup for the privilege of configuring them.

The Kaizen principle: nothing stays if something better exists

Here's where I'm different from most builders, and this is important: I treat my entire technology stack as temporary.

In Japanese manufacturing, there's a concept called Kaizen — continuous improvement. Not "big bang" overhauls every three years. Constant, incremental optimization. Every process, every tool, every decision is subject to the question: "Is there a better way to do this now?"

I apply this to everything I build. Every month, I evaluate whether the tools in my stack are still the best available option. Not out of boredom — out of discipline. The technology landscape moves fast, and the builder who married their stack two years ago is already falling behind.

Here's what this looks like in practice:

When a better AI model drops, I test it. I don't stay loyal to a vendor because we have history. I run blind quality comparisons, and if the new model outperforms on my specific use case, I switch. Loyalty is for friendships. Technology decisions should be ruthlessly pragmatic.

When a cheaper tool matches the quality, I switch. If Supabase doubled their prices tomorrow and PlanetScale offered the same capabilities for less, I'd migrate by next week. Nothing in my stack is sacred except the principle of using the best tool for the job at a fair price.

When a new capability becomes available, I integrate it. AI-powered testing tools didn't exist 18 months ago. Now they do. Video generation tools were laughable two years ago. Now they produce content that outperforms traditional production. I don't wait for the industry to tell me what's useful. I stay ahead of it, test constantly, and adopt what works.

This isn't a philosophy I talk about. It's a practice I do. Every project I touch gets better over time — not because I bill for "maintenance hours" but because improving the product improves the revenue I share with my clients. Kaizen with financial incentives built in.

The network behind the decisions

I don't figure this all out alone in a basement. I maintain relationships with extremely successful and technically competent people — venture capital fund managers at top-tier Silicon Valley firms, award-winning financial executives who advise companies through half-billion-dollar transactions, enterprise architects, and operators who've scaled products from zero to millions of users.

When I make a technology decision, it's informed by conversations with people who've seen what works and what doesn't at every scale. When I evaluate a business opportunity, I'm drawing on perspectives from people who do this at the highest levels. When a client needs more than I can provide alone — capital, exit advisory, specialized expertise — I know exactly who to call.

This network isn't something I built on LinkedIn. It's relationships developed over 25 years of operating at the intersection of finance and technology across six industries. The people in my network aren't connections — they're friends and colleagues who pick up the phone.

Why this matters for your project

If you hire an agency, you get the stack they standardized three years ago. They're not going to rewrite their internal tooling because a better option launched last month. They have training materials, onboarding docs, and twenty developers who all know the old way. Changing costs them money. Not changing costs you opportunity.

If you hire a vibe coder, you get whatever tool was trending on Twitter that week. No evaluation methodology. No understanding of trade-offs. Just vibes.

If you work with me, you get the best tools available today, evaluated by someone with 25 years of experience separating hype from value. And you get a commitment that the stack will evolve as the landscape evolves — because I'm financially incentivized to keep your product competitive, and because I genuinely believe that settling for "good enough" is how products die.

My stack isn't impressive because it has fancy names. It's impressive because every tool in it earned its place through performance, and every tool in it will be replaced the moment something earns that place more.

That's not a slogan. That's just how a finance guy with a Kaizen obsession builds things.