Essay · ~20 min read

Choose Boring Technology

Dan McKinley · mcfunley.com Free Intermediate

When you and your technical hire are arguing about the stack, this essay reframes the whole fight: the goal is not the best or newest tool, it is shipping a product and keeping the company alive. McKinley's idea that every team has only about three innovation tokens gives you a shared, honest test to settle most stack disagreements before they turn personal. It is the closest thing to a neutral referee both sides can respect.

  • Every team gets about three innovation tokens, so spend novelty only where it is core to the product, not on the database or the framework.
  • Prefer well understood technology, because its failure modes are documented and the long-term cost of keeping things running dwarfs any early convenience.
  • Adopting new tech should require a real conversation about the problem it solves, not one person's preference, which is exactly the frame a founder and hire need.
Open on mcfunley.com ↗

It answers 5 questions

  1. We ship fast but our codebase is turning into a mess. How much should a two-person startup care about tech debt?
  2. I built my MVP on no-code but my technical co-founder wants to rewrite it in real code. When is that migration actually worth it?
  3. Should I just copy the UI patterns of apps my users already use, or does that make my product forgettable?
  4. Who actually owns my data and code if I build my whole business on a no-code platform that could shut down or hike prices?
  5. When my technical hire and I disagree on the tech stack, whose call is it?

Read with it

  1. The permission slip to recruit users by hand, do things manually, and deliver 'insanely great' experiences to your first few... paulgraham.com Essay · ~15 min read Do Things That Don't Scale Paul Graham
  2. Basecamp's battle-tested, opinionated system for shipping meaningful work in fixed cycles without endless backlogs, a primary... Basecamp / 37signals Book · free online book Shape Up: Stop Running in Circles and Ship Work that Matters Ryan Singer
  3. Michael Seibel, who ran YC, makes the blunt case for shipping something almost embarrassingly simple and learning from real... Y Combinator Startup Library Video · ~10 min video How to Build an MVP Michael Seibel
  4. This is the canonical warning against throwing away working code and rebuilding from scratch, told through Netscape's rewrite... Joel on Software Essay · ~10 min read Things You Should Never Do, Part I Joel Spolsky
  5. This is the canonical explanation of what a reviewer actually means when they flag your inherited code as risky. Fowler frames... martinfowler.com Essay · About a 10 minute read Technical Debt Martin Fowler
  6. Concrete, field-tested advice on deciding which debt to pay and how to justify it. Orosz and Franco share practical rules of... The Pragmatic Engineer Article · 20 min read Paying down tech debt Gergely Orosz and Lou Franco
eChai Partner Brands The partnership →