Why Crappy Code is Profitable

Startups don’t deserve clean architecture. They deserve to ship before the lights go out.

They tell you about excellence.

Clean code. Scalable systems. Architecture that would make Knuth himself nod in approval. They say these words like prayers. Like incantations that might conjure funding from the ether.

You listen. You believe. You shouldn't.

This is how it begins. Always the same script. They've read the articles. They know the buzzwords. They speak of technical debt like it's cancer. Of best practices like commandments carved in stone.

But watch their eyes when you quote them proper rates for proper work.

Watch how quickly excellence becomes optional.

They want Google's infrastructure on a garage sale budget. They want Netflix's reliability with intern-level resources. They want what took Amazon twenty years to build, and they want it by Thursday.

Here's what they don't tell you in those late-night Slack messages filled with rocket emojis and "quick questions": you are not building software. You are building theater.

A performance designed to fool investors. To seduce customers. To convince everyone—including themselves—that their napkin sketch deserves fifty million in Series A funding.

Your job is to make the performance believable.

Not with perfect code. With convincing code.

I learned this the hard way. Project after project. Client after client. Each one promising to be different. Each one ending the same way.

They hire you because you care about craft. Because you test your functions. Because you document your APIs. Because you believe code should be readable by humans, not just compilers.

Then they ask you to skip the tests. To hardcode the configurations. To fake the data connections because the real API won't be ready for months.

"Just for now," they say. "Just to get us through the demo."

Just.

That word should trigger alarm bells. It never does.

Because here's the negotiation they never tell you about: excellence versus survival. Quality versus speed. Your reputation versus their runway.

Guess who wins.

They point to Facebook. To Twitter. To every unicorn that started in a dorm room with duct tape and dreams. "Look how far they came," they say. "Look what they built."

They never mention the armies of engineers those companies hired to rebuild everything. The billions spent unwinding technical debt. The years of performance issues and security breaches that became features, not bugs.

They see the outcome. They ignore the process.

So you build what they want. Not what they need. What they want.

Static pages that look dynamic. Buttons that trigger loading spinners but nothing else. Forms that collect data and store it nowhere. Dashboard charts that display the same numbers regardless of what you click.

Smoke and mirrors dressed up as minimum viable product.

And it works.

The investors ooh and ahh at the seamless user experience. The advisor board nods approvingly at the clean interface. The potential customers click through the demo and ask about pricing.

Nobody looks under the hood. Nobody asks about scalability. Nobody questions why the database queries return instantly or why the app never seems to crash.

This is the dirty secret of startup success: perception beats reality. Always.

Your beautifully architected, properly tested, thoroughly documented codebase means nothing if the company runs out of money before launch. Your commitment to best practices is irrelevant if the product never finds product-market fit.

But your willingness to fake it until they make it? That might save them.

So embrace the theater. Master the performance.

Build the facade first. The parts that photograph well for TechCrunch articles. The screens that demo smoothly for investor meetings. The features that look impressive in beta user testimonials.

Make it beautiful. Make it fast. Make it now.

The real infrastructure can wait. Proper error handling can wait. Data validation can wait. Security audits can wait.

Their next funding round cannot.

This isn't about compromising your values. It's about understanding theirs.

They value survival over perfection. Progress over polish. Revenue over reputation.

At least until they're safe.

Here's the framework I use: Version One is a movie set. It looks real from the front. The back is held up with two-by-fours and prayer.

Tell them this upfront. Use their language. "We're building an MVP to validate product-market fit. We'll iterate based on user feedback and scale based on traction."

They nod. They understand. They've read the same startup blogs you have.

Most clients accept this reality. They know that startups are built on compromises. That perfect is the enemy of shipped. That iteration beats ideation every time.

Some push back. They insist on doing it right from day one. They want enterprise-grade everything despite having twelve users and six months of runway.

These clients fire themselves. Let them.

The ones who survive understand the game. They know that fake progress beats real problems. That working code beats working architecture. That paying customers don't care about your test coverage.

They also know something else: if the theater works, if the performance succeeds, if the fake becomes real—they'll hire you to rebuild it properly.

With proper budgets. Proper timelines. Proper respect for your expertise.

But only if you help them survive the performance first.

Build what gets funded, not what gets graded. Build what ships, not what scales. Build what pays, not what impresses other engineers.

Because here's what they don't teach in computer science programs: the best code in the world is worthless if nobody sees it.

Crappy code that launches beats perfect code that doesn't.

Every single time.

Your pricing should reflect this reality. Charge for results, not processes. For outcomes, not outputs. For survival, not satisfaction.

If they make it, you make it.

If they don't, you still got paid.

The market rewards working over perfect.

Your invoices should too.