Technical Decisions
The engineering choices that shape a startup’s trajectory. Most founders obsess over technology; the best founders treat technology as a means to a business end. PG’s mistake #7: “Choosing the wrong platform” — technical decisions have outsized consequences, but not in the way most founders think.
The Only Technical Decision That Matters Early
Ship fast. That’s it.
Pre-PMF, the only technical metric is speed of iteration. The lean-startup Build-Measure-Learn loop runs at the speed of your engineering cycle. Everything that accelerates learning is good; everything that slows it is bad.
Altman: “Launch earlier than instinct suggests.” PG: “Nothing is truly finished till it’s released.”
Practical implications:
- Use boring, well-understood technology (not cutting-edge)
- Optimize for developer speed, not system performance
- Monolith > microservices at this stage
- One database, one framework, one language
- If it takes more than a week to ship a feature, your architecture is wrong for this stage
Technical Debt: When It’s Fine and When It Kills
Technical Debt Is Fine When:
- You’re pre-PMF and learning speed is the priority
- The debt is in code that might be thrown away after a pivot
- You know the debt exists and can quantify it
- The shortcut lets you test a hypothesis this week instead of next month
- Altman: “Growing fast while disorganized usually succeeds; optimize later”
Technical Debt Kills When:
- It slows iteration speed (the thing it was supposed to accelerate)
- New engineers can’t onboard because the codebase is incomprehensible
- You can’t deploy safely because there are no tests and everything is coupled
- Customer-facing bugs erode trust and increase churn
- You’re scaling and the architecture can’t handle the load
The Rewrite Question
“Should we rewrite?” Almost always: no.
Rewrites are the #1 technical time sink. They take 2-3x longer than estimated, the old system must be maintained during the rewrite, and the rewrite often introduces its own bugs. The businesses that die during rewrites die because they stopped iterating on the product.
When to actually rewrite:
- The existing system literally cannot scale to meet demand (not “might not scale someday”)
- The codebase prevents you from shipping any new features (not “makes it harder”)
- You’re hiring engineers who refuse to work on the existing stack
- A rewrite can be done incrementally (strangler pattern), not all-at-once
Choosing a Tech Stack
For Most Startups (Pre-PMF)
Pick whatever your founding team already knows. Period.
The best tech stack is the one your team ships fastest with. Rails, Django, Next.js, Laravel — they all work. The difference between frameworks is nothing compared to the difference between shipping this week and shipping next month.
What Actually Matters
| Matters | Doesn’t Matter |
|---|---|
| Team familiarity | Theoretical performance |
| Hiring pool size | HackerNews hype |
| Ecosystem maturity (libraries, docs) | Architecture purity |
| Speed of development | Scalability to millions (premature) |
| Ease of deployment | Language benchmarks |
PG’s mistake #7 warns about platform choice, but the real mistake is usually choosing something exotic that slows you down, not choosing something “uncool” that works.
The AI-Era Technical Shift
- AI coding assistants accelerate development in any stack
- The choice of language/framework matters less when AI handles boilerplate
- AI is better at popular stacks (more training data) — another reason to choose boring technology
- Solo founders can build what previously required a team, in any stack they know
Hiring Engineers
From PG’s mistake #6: non-technical founders “can’t tell which are the good programmers.”
If you’re a non-technical founder:
- Find a technical cofounder (cofounder-dynamics) — don’t try to hire engineers without one
- If you must hire without a tech cofounder, have a trusted technical advisor evaluate candidates
- Value shipping speed over credentials — the engineer who ships a working feature in a week beats the one with a perfect resume who ships in a month
- Rabois’ barrels framework applies: a 10x engineer who ships end-to-end is worth 10 engineers who need direction
When to Invest in Infrastructure
| Stage | Infrastructure Investment | Why |
|---|---|---|
| Pre-PMF | Minimal. Ship fast. | You might pivot; don’t build infrastructure for the wrong product |
| Post-PMF (early) | Testing, CI/CD, monitoring | You need to ship reliably now, not just fast |
| Scaling | Horizontal scaling, caching, CDN | Real load demands real infrastructure |
| Growth | Platform, APIs, developer tools | If you’re building network-effects, infrastructure IS the product |
The pattern: invest in infrastructure one stage before you need it, not two stages before.
See Also
- product-development
- execution
- scaling
- minimum-viable-product
- hiring
- operations
- ai-era-entrepreneurship
Sources
- Startup Playbook — Sam Altman
- 18 Mistakes That Kill Startups — Paul Graham
- Do Things That Don’t Scale — Paul Graham
- How to Operate — Keith Rabois