Resume Driven Development

I’M TIRED OF THIS CONVERSATION

Every other week… “Why SvelteKit not React?” “Why Cloudflare instead of AWS?” “SQLite vs Postgres?”

It’s annoying at this point. But fine. One last time. Let’s end this discussion once and for all.

React isn’t a framework. It’s a UI library. Components. Virtual DOM. That’s it.

Need routing? React Router. State? Redux, Zustand, pick your poison. Forms? Hook Form or Formik. Data fetching? SWR or Query. SEO? Helmet.

Before one line of real code, you’ve mass installed a mountain of packages and cobbled together an architecture from blog posts and Stack Overflow scraps from 2019. Half those packages have different maintainers, different release cycles, different opinions.

That’s not a framework. That’s volunteering for tech debt before you have even deployed.

SvelteKit? Actual framework. Routing, state, forms, SSR, APIs, head tags. Built in. One dependency. One set of docs. One deploy.

No frontend/backend split. No two repos, two pipelines, no late night debug sessions from hell. Form actions hit server functions direct. APIs live next to the pages that use them.

Your client is running a 12 page site with 400 visitors a month… They’re not Netflix. They don’t need microservices.

Most clients don’t need Postgres.

50 users. 3 tables. Why are we billing them for a managed database?

SQLite handles tens of thousands of concurrent reads. Single file. No connection pooling headaches. No database server to babysit. No network latency between app and data.

Cloudflare D1? SQLite at the edge. Sub-millisecond queries. Zero cold starts. Free tier is a beast.

“But what about scaling?”, you ask.

Migrate. One day’s work. Data model stays the same.

And lets be honest they probably won’t need to scale past SQLite. It powers million-user applications. Been around longer than half the developers turning their noses up to it.

You know what doesn’t scale? Charging $50/month for RDS while the client is pre-revenue with 12 customers.

We’re selling infrastructure clients don’t need.

It’s not malicious. Just lazy and comfortable

The typical dev shop tech-stack: AWS because that’s what we know. React because that’s what we hire for. Express backend “just in case.” That’s not engineering. That’s resume driven development billed hourly.

Six months later: $50-100/month hosting bill. 3 second mobile loads. A codebase only we can touch.

Nobody asks the real question: “Does this client even have a dev team?”

Not a developer. A team.

AWS is 200+ services. EC2, RDS, Lambda, API Gateway, CloudFront, IAM, VPCs, Security Groups, CloudWatch. Each one its own unique pricing model, configuration nightmare, and failure mode.

Managing that properly is a full-time job..Multiple full-time jobs. If the client is a solo founder or small team? They’re either ignoring critical config or paying us forever to manage complexity we created.

And then there’s the bill.

AWS pricing is roulette.

S3 egress? Pay per byte. NAT Gateway sitting idle? $30-50/month for nothing. Forgot to kill that test EC2 instance? Been running six months. DDoS attack? Client pays for the attack traffic.

Every AWS horror story about a surprise $10k+ bill is usually the result of one misconfiguration. That complexity isn’t a bug. It’s AWS’s profit engine.

Cloudflare pricing? Transparent AF.

  • Workers: 10 million requests included, $0.30 per million after
  • D1: Clear per-row pricing
  • KV: Clear per-operation pricing
  • Egress: Free. Always.
  • Bandwidth: Free. Always.
  • DDoS: They absorb it. Literally their core business.

The comparison:

AWS: $50-150/month base. Surprise bills. Egress fees. Dev team required.

Cloudflare: $0-5/month. Predictable. Start up-friendly.

Worst case traffic spike on Cloudflare? $50. Same spike on AWS? Pray lord Bezos has mercy on your soul.

We’re handing clients AWS roulette and calling it engineering. That’s negligence.

Let’s talk about why startups actually fail.

Contrary to popular belief it’s not the tech stack.

90% of startups fail, and the autopsies are all the same boring story. Ran out of money. No product-market fit. Got outcompeted. Team fell apart. Couldn’t close sales.

You know what’s never in the post-mortem? “We chose Svelte instead of React and that killed us.”

That case study doesn’t exist.

Every dollar a client burns on infrastructure they don’t need is a dollar not spent on marketing, sales, or runway. Every hour fighting AWS config is an hour not shipping features.

That $50/month bill? Multiply by 24 months. $1,200. Could’ve been ad spend. Could’ve been a contractor. Could’ve been three more months of survival.

Startups die from running out of runway. Not from picking the wrong front-end framework.

“But the React ecosystem…”

What ecosystem?

Most npm packages aren’t React packages. They’re JavaScript libraries with React wrappers slapped on top.

Stripe, Google Maps, D3, Chart.js, Axios, date-fns. All framework agnostic. Work the same in Svelte.

The React “ecosystem” is mostly libraries solving problems SvelteKit doesn’t have in the first place.

“But React scales better…”

Scales what?

The frontend is static assets on a CDN. Framework doesn’t matter. It’s just JavaScript, HTML, and CSS getting served.

Svelte actually scales better. It compiles to vanilla JavaScript. No virtual DOM shipping to browsers. No runtime reconciliation. No diffing algorithm churning on every state change. The framework literally disappears at build time.

React ships the entire framework to every user on every page load. Then does work in the browser that Svelte already handled during compilation.

Smaller bundles. Less JavaScript. Faster loads. Better for users on garbage connections.

“But we need React for the exit…”

GitHub was built with Ruby on Rails… $7.5 billion.

Figma built with custom C++/WebGL… $20 billion.

WhatsApp built with Erlang… $19 billion.

Discord: Python and Elixir… you get the point

The future investors you are dreaming up don’t care about your framework. They care about revenue, retention, and whether the codebase is maintainable.

A clean SvelteKit app beats a rat’s nest of React components drowning in Redux boilerplate. EVERY SINGLE TIME.

You know what kills an acquisitions? Messy code and no revenue. Not your framework choice.

“Okay. When IS AWS the right call?”

Fair question, AWS isn’t a bad product. BUT before you commit yourself and your clients to funding Bezo’s next super yacht.

First ask yourself does your client have…

  • Long-running compute. Jobs over 10-15 minutes that don’t fit serverless architecture.
  • GPU workloads. ML inference, video transcoding, anything needing CUDA.
  • Compliance mandates. HIPAA, FedRAMP, specific certification requirements.
  • Dedicated dev team. A team of people whose entire job is infrastructure.
  • Specific managed services. They genuinely need Elasticsearch, SQS, Kinesis, Red…yadayadayada
  • Already drank the AWS kool-aid, and have existing IAM, VPCs, architecture in place.

If you can check three or more of these boxes…go forth into the AWS forest and frolic. Have fun, wish you nothing but the best.

Local business? Startup MVP? Under 10K users? Solo founder? Small team?

They don’t need AWS. They need to ship and survive.

Bottom line.

React + Express + AWS isn’t “industry standard.” It’s cargo-cult comfort. The path of least resistance for developers who learned one stack and apply it to everything regardless of fit. The ol’everything looks like a nail if you only know how to use a hammer cliche

We owe our clients better.

Right-size the infrastructure. Pick tools that fit the problem. Stop charging small businesses enterprise prices because we’re too comfortable to learn something new.

The goal isn’t padding invoices with complexity. The goal is building something that works, stays up, and doesn’t burn the client’s runway while they’re hunting for product-market fit.

If they succeed, they’ll come back for the bigger build. If they fail, at least we didn’t help bankrupt them.

Zach Holloway, Founder

Share