THE EVOLUTION OF AN AGE-OLD TRADE-OFF: BUILD, BUY, DITCH
Written by Jessica Murray
I recently scanned a headline that caught my attention: The Idiot Index for Code.
The article was a guest post by Evan Armstrong, founder of The Leverage and tech-trend writer. In it, he addresses shifting conversations about software and the re-examination of well-known principles, particularly with the rise of AI coding tools. It’s a timely and relevant post for entrepreneurs, given the technology trade-offs that will present themselves along the business-building journey.
The Idiot Index defined
If, like me, you haven’t memorized Elon Musk’s working principles, the “Idiot Index” concept might be new to you, so let’s start there, given it was the title of Armstrong’s article.
This concept, coined by Musk, measures the ratio of a component’s cost to its raw material. This piece uses the example: “A $1,000 part made from $100 aluminum has an idiot index of 10.” The higher the number, the bigger “the idiot” because someone can extract more margin from ignorance.
Historically, this ratio was high for software businesses because code was hard to write, maintain and deploy, plus the skilled talent was expensive.
Generative AI and new coding tools lowered that barrier fast. But we’ll get to that shortly.
Build, buy or ditch?
When trying to obtain a new capability, there’s the operational question of how to best acquire it:
Do I build?
Do I buy?
General rule of thumb: Build (or own) what differentiates your product, and buy everything from someone else.
As Armstrong highlights, a beer company isn’t going to become a billion-dollar company based on its CRM software. It’s better to purchase that and use the time toward building the thing(s) that will make the core product, beer, taste best to consumers.
Sometimes, the best option is the third question:
Do I ditch?
Not everything that exists should. Be ruthless about that.
Intuitively, all of this makes sense, but AI muddies the conversation.
Why?
The barrier to building software has decreased significantly in a short period.
The paradigm shift
When everyone’s feeds are filled with people talking about the latest app they vibe-coded or agent they spun up on Claude Code or Cursor, it’s tempting to hop straight to:
“Let’s build.”
“Let’s automate that clunky process.”
“SaaS no more.”
But skipping from idea straight to building misses critical questions:
Why does this need to exist?
Will building truly simplify, or will I introduce unnecessary complexity?
What’s the opportunity cost of building and maintaining bespoke software?
I get it, I spent eight hours last week vibe coding a personal project. It’s both fun and addictive. You quickly come to realize how much more is possible than just a few years ago, especially for those, like yours truly, who are non-technical.
While I feel more empowered and capable of building than ever before, the work required to develop new apps, agents or agentic workflows is still, well, work. You need to:
Write clear requirements.
Get to a functional prototype.
Structure the back-end.
QA and ensure you’re production-ready.
Maintain post-launch.
Is it easier and more approachable than before?
Yes.
Does it still take effort?
Yes.
There’s no magic switch now that’s made it a no-brainer to build everything. So, before jumping into the deep end, come back to that build vs. buy vs. ditch crossroads.
If for no other reason than:
Time is still your most limited resource. AI doesn’t change that.
So when code becomes cheap, what becomes expensive?
For early-stage founders, the answer is obvious.
It’s your time.
- Evan Armstrong
Keep the focus & simplify
What are the most important things to spend your most valuable asset —time— on in the early stages?
Talking to customers.
Core product development.
Closing new business.
Staying solvent.
If there are agents or applications:
You can effectively build and maintain.
For which the payback period on your time is reasonable.
Yielding outcomes directly tied to the four bullets above.
There may very well be a strong argument for the build.
If those things aren’t true, seriously pause.
As Armstrong suggests, ask these five questions before opening [insert favorite AI-coding tool]:
Does this need to exist?
Can I do it manually at 70% before finding product-market fit?
Is there a $30/month SaaS alternative that already does this job well, with strong adoption?
Who will maintain this “thing” I want to build in six months?
What else could I do with these [insert #] hours?
If you can’t defend the build, don’t waste cycles right now.
This is all about leveraging your time. Use it where it counts.