Solved: Why do people still start restaurants if they fail 90% of the time?

#devops #programming #tutorial #cloud

🚀 Executive Summary

TL;DR: Tech projects frequently fail by prioritizing complex, bleeding-edge solutions over delivering customer value, driven by factors like Resume-Driven Development and underestimating operational complexity. To succeed, teams should embrace pragmatic approaches such as PaaS for rapid validation, “Boring Technology” for stable development, or highly opinionated managed serverless ecosystems for scalable delivery.

🎯 Key Takeaways

Tech project failures often stem from Resume-Driven Development (RDD), FAANG Cargo Culting, and underestimating the operational complexity of distributed systems.
Pragmatic approaches to shipping product include using Platform-as-a-Service (PaaS) for rapid validation, “Boring Technology” for stable development, and highly opinionated managed serverless ecosystems for scalable delivery.
“Boring Technology” stacks (e.g., Ruby on Rails, Django) offer significant advantages in time-to-production, hiring pool size, cognitive load, and available tooling compared to “Hype Stacks.”

Just like restaurants, tech projects often fail by chasing complex dreams over simple, profitable realities. Learn why choosing ‘boring’ technology is often the smartest move and how to pick a stack that actually ships product instead of just technical debt.

Our Industry’s 90% Failure Rate: Stop Building Restaurants, Start Making Pizza

I remember a project codenamed ‘Odyssey’. We had a team of some of the sharpest engineers I’ve ever worked with. The mission? A greenfield B2B platform. The tech stack chosen? A beautiful, terrifying tapestry of bleeding-edge tech: a polyglot microservices architecture running on a self-managed Kubernetes cluster, a brand-new service mesh, and a data layer that looked more like a particle physics diagram than a database schema. We spent 14 months building the most elegant, scalable, and resilient “platform” imaginable. We had CI/CD pipelines that were a work of art. The problem? We never shipped a single feature the customer could use. The company ran out of runway chasing a technical dream, and the whole thing imploded. We were so obsessed with building a three-Michelin-star kitchen that we forgot we were supposed to be serving food.

The Seductive Allure of the Empty Kitchen

I saw this question on Reddit the other day: “Why do people still start restaurants if they fail 90% of the time?”. The answers all boiled down to passion, ego, and a tragic underestimation of the non-glamorous work. This is our industry in a nutshell. We do the same thing, just with code.

The root cause isn’t incompetence; it’s a mix of good intentions and bad incentives:

Resume-Driven Development (RDD): Let’s be honest. Nobody gets excited to put “Maintained a 10-year-old PHP monolith” on their resume. Engineers want to learn the hot new thing—Go, Rust, Kubernetes, eBPF—and the best way to do that is on the company’s dime. The project’s success becomes secondary to personal development.
The “FAANG” Cargo Cult: We read a blog post from Netflix or Google about how they solved a planetary-scale problem with a custom-built tool, and we think, “We need that, too!” We forget that our user base is 500 concurrent users, not 500 million. We’re trying to use a sledgehammer to hang a picture frame because that’s what the big guys use.
Underestimating Operational Complexity: A simple monolith on a single VM is easy to reason about. A dozen microservices with a service mesh, distributed tracing, and multiple databases is an operational beast. The cognitive load on the team skyrockets, and your velocity grinds to a halt because half your time is spent debugging the plumbing, not building features.

We’re chasing the passion of creation, but we’re ignoring the business reality: we exist to solve a customer’s problem and get paid for it. That’s it.

Three Ways to Actually Ship Product

So how do we break the cycle? How do we stop building restaurants that are doomed to fail and start building profitable pizzerias? It comes down to deliberately choosing the right level of complexity for the job.

1. The Quick Fix: The “Cloud Kitchen” Approach

This is my go-to for any new project or startup that needs to validate an idea, fast. You don’t build a kitchen; you rent one. Use a Platform-as-a-Service (PaaS) like Vercel, Render, or the old reliable, Heroku. You give them your code, a credit card, and they handle the rest.

Yes, it’s “hacky” in the sense that you’re not controlling every knob and dial. But you can go from a git repo to a publicly accessible URL in minutes. You’re shipping. You’re getting feedback. You’re focusing on the product, not on whether prod-worker-3 has a memory leak.

Imagine you have a simple Node.js Express app. Getting it live on a PaaS is often as simple as this:

# Install the platform's CLI
npm install -g vercel

# Deploy from your project directory
cd my-cool-app
vercel --prod

Done. You have a URL. You’re in business. You can worry about migrating to your own Kubernetes cluster when you have the revenue and the traffic to justify it.

Pro Tip: This approach gets expensive at scale. A PaaS is a great incubator, but be prepared for a hefty bill once you have significant traffic. Plan an “off-ramp” strategy for when you hit that inflection point, but not before.

2. The Permanent Fix: The “Profitable Pizzeria” Method

This is about embracing Boring Technology. Pick a mature, stable, well-documented framework and stick with it. Think Ruby on Rails, Django, Laravel. The tech is battle-tested, the community is massive, and you can hire developers who can be productive on day one.

A pizzeria has a simple menu: dough, sauce, cheese, toppings. It’s not fancy, but it’s reliable, and everyone knows how it works. That’s what a “boring” stack gives you. You spend your creative energy on your “specialty pizza” (your core business logic), not on reinventing how the oven works.

Consider the trade-offs when a team is choosing a stack:

Metric	Hype Stack (e.g., Rust Microservices on self-hosted K8s)	Boring Stack (e.g., Django on RDS/EC2)
Time to “Hello World” in Prod	Weeks, or even months.	Hours, or a day at most.
Hiring Pool	Small, expensive, and highly competitive.	Large, diverse, and affordable.
Cognitive Load	Extremely high. Need to understand distributed systems, networking, containers, etc.	Low. A single codebase, a clear request/response cycle.
Available Tooling	Immature. You’re often building your own tools.	Vast ecosystem of plugins, libraries, and managed services.

The “Boring” stack wins on every metric that matters for getting a product to market. It’s not about being unadventurous; it’s about being pragmatic.

3. The ‘Nuclear’ Option: The “Franchise Model”

Sometimes, you need scale and reliability from day one, but you still don’t want the operational headache of managing it yourself. The answer is to go all-in on a highly opinionated, managed ecosystem. I’m talking about building your application entirely on something like AWS Serverless (Lambda, API Gateway, DynamoDB, SQS).

This is like buying a McDonald’s franchise. You don’t get to design the kitchen or the menu. You get a strict playbook, a pre-approved supply chain, and a rigid set of rules. It’s restrictive, but it’s also incredibly efficient and scales almost infinitely without you having to provision a single server.

You define your entire infrastructure as code, and the cloud provider handles the rest. A simple API endpoint might look like this in a serverless.yml file:

service: user-api

provider:
  name: aws
  runtime: nodejs18.x

functions:
  getUser:
    handler: handler.getUser
    events:
      - http:
          path: users/{id}
          method: get

This is powerful, but it’s called the “nuclear” option for a reason. Once you’re in, you’re in. Your code, your architecture, and your team’s skills become deeply intertwined with a single vendor’s ecosystem.

Warning: This is a one-way door. Migrating a deeply integrated serverless application off of a cloud provider is not a project; it’s a multi-year, company-defining epic. Be absolutely certain you are committed to the platform before you go down this path.

At the end of the day, our job isn’t to build beautiful kitchens. It’s to serve food that people want to eat. Whether that’s a quick slice from a cloud kitchen, a reliable pie from a local pizzeria, or a consistent burger from a global franchise, the goal is the same: deliver value. Stop idolizing the complexity and start celebrating the delivery.