The MVP Industrial Complex and Why I Keep Falling for It

April 25, 2025

TL;DR

  1. Anyone can slap together CRUD in a weekend. Congrats, you’re special.
  2. Crafting code that doesn’t implode at scale? That’s actual work.
  3. Real skill is knowing when to cowboy deploy and when to monk up. Most of you (and me) are bad at this.

Speed vs. Craft: Why I’m the Clown Who Ships

It has never been easier to ship a CRUD app in a day.

Next.js? Handles routing and SSR like a dream. Vercel? One-click deploys with preview branches that feel like magic. Supabase? Auth, Postgres, instant APIs, row-level security—all free until your idea gets too big (or your ambitions too delusional).

Give me caffeine and bad intentions, and I’ll have user auth, a database, and full CRUD before dinner. Maybe even dark mode. Maybe even tastefully animated hover states.

But here’s the thing: just because you can move this fast doesn’t mean you’re good at this. (And yes, I’m talking to myself.)

The Two Developer Classes (and Why Both Are Clowns)

In my totally correct opinion, there are two kinds of developers:

The Entrepreneur Dev (a.k.a. The Feature Goblin):

  • Ships fast, Googles the same Next.js doc every single time.
  • Adds auth, deploys to prod, and slaps on “Beta” as the testing strategy.
  • Loves phrases like “we’ll fix it in post” and “we’re just validating the idea.”
  • Will hand-wave away any architecture conversation by saying “bro, we’re pre-revenue.”
  • Core skill: Moving so fast they can’t hear the sound of their own tech debt piling up.

The Code Monk (a.k.a. The Enterprise Wizard):

  • Hasn’t looked at a doc in 5 years—because they are the doc.
  • Believes the only real CRUD app is the one with 98% test coverage and a GraphQL schema so strict it needs a lawyer.
  • Sees your Supabase free tier and raises you a Kubernetes cluster with observability baked into its soul.
  • Their PR reviews are two paragraphs of theory and one line of “maybe this should be a factory.”
  • Core skill: Knowing 14 ways to solve the problem—and implementing none of them, because they’re still designing the perfect solution.

So… Which One Am I?

I want to be The Code Monk. I respect the monk. I aspire to be the person who doesn’t need docs because they’ve absorbed the patterns into their bones.

But if I’m being honest? I’m 100% the Feature Goblin. I build fast, hack things together, ship the MVP, and hope no one asks about my testing strategy until at least v2.

And yeah… sometimes that makes me feel like an imposter.

I sit in meetings with the Monks, nodding along while they debate the best retry strategies for distributed queues. Meanwhile, my last pull request was literally titled “add loading spinner lol.”

But here’s the thing: I ship. And shipping is the only thing that moves the needle.

When to Move Fast (and When to Actually Care)

The dirty secret is that both approaches are valid—but only if you know when to use them.

  • Early-stage idea? Move fast. Break stuff. The best test is a user clicking a button.
  • Scaling product? Slow down. Add the tests. Add the observability. Refactor your sins.
  • Feeling clever? Probably time to simplify.
  • Feeling lazy? Probably time to optimize.

Good devs know how to do both. Great devs know when to switch modes.

Final Thought

The Feature Goblin gets things into the world. The Code Monk keeps those things from catching on fire.

Most of us are somewhere in between—and honestly, that’s fine. As long as you know which hat you’re wearing when you sit down at the keyboard.