The founder made a decision that would cost him eighteen months of work. A decision that, from the outside, seemed obviously wrong.
But I understood why he'd made it. I'd seen it before.
Pressure. Deadlines. The feeling that he needed to ship. The belief that he could fix it later.
He couldn't fix it later. But in the moment, he truly believed he could.
The Anatomy of a Bad Decision
Bad technical decisions aren't made by stupid people. They're made by smart people under pressure.
The pressure is real. Runway is finite. Investors are asking for progress. Competitors are moving. The founder feels the weight of all that pressure every time they make a decision.
And under pressure, we optimize for the immediate. We choose solutions that solve today's problem, even if they create tomorrow's problems.
The Decision-Making Environment
Founders operate in an environment that actively works against good decisions:
Time Pressure: Every day costs money. The clock is always ticking. This creates urgency that overrides careful analysis.
Information Asymmetry: Founders often lack the technical knowledge to evaluate options properly. They must rely on others, who may have their own agendas.
Uncertainty: The future is unknown. Decisions must be made with incomplete information. Hindsight makes it easy to judge; foresight makes it impossible to know.
Feedback Delays: The consequences of technical decisions often take months to appear. By then, it's too late to easily change course.
Competing Priorities: Technical decisions compete with sales, fundraising, hiring, and product decisions for attention. Technical often loses.
Understanding this environment helps explain why good founders make bad decisions—and why avoiding them requires deliberate strategy.
The Patterns I've Seen Again and Again
Across hundreds of startups, I've observed the same bad decisions made repeatedly. Recognizing these patterns is the first step to avoiding them.
Pattern #1: The "Ship Now, Fix Later" Decision
The founder knows the architecture isn't right. But they need to ship. They convince themselves they'll They never do.
refactor later.Why it happens:
- You have a deadline (investor demo, launch date, competitor pressure)
- The "right" solution would take longer
- You believe you'll have time to fix it later
- The current solution works well enough for now
Why it's problematic:
- "Later" never comes—you're always onto the next crisis
- Technical debt compounds—each new feature on top of fragile foundations is harder to build
- Rewriting becomes harder over time, not easier
- The cost of fixing it later is always higher than fixing it now
The real cost: According to research by Steve McConnell, the cost of repairing a defect increases by a factor of 10 for each phase it slips past. A decision made in hour one that costs $100 to fix becomes a $1,000 fix in week one, $10,000 in month one, and potentially $100,000+ if it reaches production.
Pattern #2: The "Copy What Works" Decision
The founder sees how a big company solved a problem. They copy the solution without understanding if it fits their context. It doesn't.
Why it happens:
- Big companies seem successful—their solutions must be good
- You don't have time to design something custom
- It feels safer to follow a proven approach
- You believe you'll scale into this solution eventually
Why it's problematic:
- Big companies solved problems for their scale, not yours
- Their solution may be designed for teams of 50, not 2
- You inherit complexity you don't need
- What works at scale often doesn't work at the beginning
Real-world example: A startup I worked with adopted a microservices architecture because "that's what Netflix does." They had three developers. Every deployment required coordinating multiple services. A simple feature took weeks. They eventually spent six months consolidating back to a monolith—the architecture that would have served them well from the start.
Pattern #3: The "Trust the Expert" Decision
The founder defers to a technical person who turns out to have their own agenda. The decision looks technical but is actually political.
Why it happens:
- You don't have the technical expertise to evaluate
- You want to trust your team
- The expert sounds confident
- It seems inappropriate to question technical judgments
Why it's problematic:
- Technical people have their own biases and agendas
- "Best" technical solutions aren't always best for the business
- You lose ownership of decisions that affect your company
- The expert may be optimizing for their career, not your success
Warning signs:
- The expert dismisses alternatives without thorough analysis
- The solution requires significant ongoing dependency on the expert
- The decision is presented as purely technical when it has business implications
- You're asked to trust without understanding
Pattern #4: The "Avoid the Hard Conversation" Decision
The founder knows the team isn't working well together. They avoid addressing it. The problem grows.
Why it happens:
- Difficult conversations are... difficult
- You hope the problem will resolve itself
- You're focused on product and fundraising
- Team dynamics feel less urgent than other priorities
Why it's problematic:
- Small problems become big problems
- High performers leave; problem performers stay
- Culture erodes when dysfunction is tolerated
- The cost of fixing it later is always higher
Pattern #5: The "Over-Engineering for Future Scale" Decision
The founder builds for a level of scale they'll reach "someday." That day never comes, but the complexity remains.
Why it happens:
- You want to be prepared for success
- It feels professional to build for scale
- You're worried about needing to rewrite later
- The technical challenge is exciting
Why it's problematic:
- Most startups don't scale to the levels they imagine
- Complex systems are harder to build and maintain
- You delay shipping while building for scenarios that may never happen
- Simple systems can be made complex; complex systems rarely become simple
The rule of thumb: Build for 10x your current scale, not 1000x. When you actually reach 10x, you'll have the resources to handle the next scaling challenge.
The Root Causes
These patterns share common root causes:
Short-Term Thinking Under Pressure
When runway is limited and deadlines are pressing, the future becomes abstract. You can't feel the weight of a decision that will cost you months of work next year. But you can feel the pressure to ship this week.
The solution: Make future costs concrete. Before making a decision, write down what it will cost to fix later. Put a dollar figure on it. Make it real.
Confirmation Bias
You see what you want to see. When you've decided to ship, you notice evidence that supports that decision and dismiss evidence against it.
The solution: Seek out disconfirming evidence. Ask specifically what could go wrong. Appoint a "devil's advocate" whose job is to challenge the decision.
Overconfidence in Future You
You believe that future you will have more time, more money, more resources. Future you will definitely fix this problem.
The solution: Recognize that future you has the same constraints as present you, plus more. Future you will also be busy, also under pressure, also deferring difficult tasks.
Authority Bias
When an "expert" speaks, you defer. But experts have blind spots too.
The solution: Ask questions. Ask for alternatives. Ask for trade-offs. Ask what they would do if they had your constraints. Don't accept "this is the way" as an answer.
The Fix: Building Decision Protection Systems
The fix isn't to become technical (though that helps). It's to build systems that protect you from yourself:
System #1: Get Outside Perspective
Someone who's seen this before can spot patterns you can't. Use advisors, consultants, other founders.
How to do it:
- Join a community of founders (Indie Hackers, On Deck, direct.slack)
- Hire consultants for major decisions
- Talk to founders who've solved similar problems
- Seek adversarial views deliberately
The value of outside perspective: Someone who's made the same mistake can help you avoid it. They've seen the downstream effects you can't yet imagine. They can ask "what happens when X happens?" and you've never considered X.
System #2: Write Down the Decision
Before you commit, write down why you're making this choice.
Include in your decision document:
- What problem you're solving
- What options you considered
- Why you chose this option over others
- What might go wrong
- What will you do if it fails
- When you will evaluate whether it worked
The power of writing: Writing forces clarity. Vague thinking produces vague decisions. When you have to articulate your reasoning, you discover gaps you hadn't noticed.
System #3: Time-Box Experiments
If you're not sure, treat it as an experiment. Set a date to evaluate.
How to do it:
- Choose a limited scope for the experiment
- Set a specific date to evaluate results
- Define what success looks like
- Have a contingency plan if it fails
Example: "We'll use this approach for three months. If our development velocity hasn't improved or we've spent more than 20 hours on infrastructure, we'll revisit the decision."
The benefit: This gives you permission to try things while limiting downside. You're not committing forever. You're committing to a trial period.
System #4: Create Safety for Truth
People should be able to tell you when you're wrong. If they can't, you'll keep making mistakes.
How to create safety:
- Reward people who bring bad news
- Don't punish messengers
- Ask specifically for concerns before making decisions
- Model receptivity to feedback
The founder's role: As a founder, your behavior sets the norms. If you react badly to bad news, you stop receiving it. If you react constructively, you create a culture where truth flows freely.
System #5: Build Technical Literacy
You don't need to be able to code, but you need to be able to evaluate technical decisions.
How to build literacy:
- Ask "why" repeatedly until you understand
- Learn the basics of the technologies you're using
- Understand the trade-offs, not just the features
- Read about technical decisions at other companies
The goal: You don't need to make technical decisions. You need to be able to evaluate whether the people making technical decisions are doing a good job.
A Decision Framework for Technical Choices
When facing a technical decision, work through this framework:
Step 1: Define the Problem
What problem are you trying to solve? Be specific.
Bad: "We need better infrastructure" Good: "Our current deployment process takes 2 hours and fails 30% of the time"
Step 2: Identify Options
What are the reasonable approaches? List at least three.
- Do nothing (baseline)
- Quick fix (low effort, partial solution)
- Robust solution (higher effort, better outcome)
- Gold standard (best outcome, highest investment)
Step 3: Evaluate Each Option
For each option, assess:
Factor | Do Nothing | Quick Fix | Robust | Gold Standard |
|---|---|---|---|---|
Time to implement | 0 | 1 week | 1 month | 3 months |
| Cost | $0 | $1,000 | $10,000 | $50,000 |
| Risk | High (decline continues) | Low | Medium | High |
Long-term cost | Increases | Moderate | Low | Lowest |
Flexibility | Decreases | Some | Good | Variable |
Step 4: Make the Decision
Choose based on your constraints:
- Time-constrained? Go with quick fix, time-box evaluation
- Quality-constrained? Invest in robust solution
- Resource-constrained? Find the most cost-effective option
- Risk-averse? Avoid extremes; favor middle options
Step 5: Document and Communicate
Write down the decision and share it. Include:
- The problem you solved
- The approach you chose
- Why you rejected alternatives
- Expected outcomes
- Warning signs to watch for
Step 6: Review and Iterate
Set a date to revisit the decision. Ask:
- Is this working as expected?
- What have we learned?
- Should we continue, adjust, or change course?
Common Decision Traps to Avoid
The Sunk Cost Trap
You've already invested in a bad decision. You continue because you've already spent the money/time/effort.
The fix: Evaluate decisions based on future value, not past investment. Ask: "If we hadn't made this decision yet, would we make it today?"
The Default Trap
Doing nothing is a decision. Often the worst one.
The fix: Explicitly evaluate the "do nothing" option. What happens if you continue as is? What are the costs of inaction?
The Shiny Object Trap
A new technology or approach looks exciting. You abandon what works for what looks cool.
The fix: Be skeptical of excitement. Ask: "What problem does this solve that our current approach doesn't? What's the real cost of switching?"
The Consensus Trap
Everyone agrees, so it must be right. But sometimes everyone is wrong together.
The fix: Deliberately seek dissent. Appoint someone to argue against the consensus. Make it safe to disagree.
When to Get Help
Some decisions are too important to make alone:
When the cost of being wrong is high: If a bad decision would cost more than the price of help, get help.
When you lack expertise: If you've never made this type of decision before, find someone who has.
When emotions are running high: Pressure and stress impair judgment. Get outside perspective when you're feeling overwhelmed.
When the decision is irreversible: Some decisions can't be undone. Get help before committing.
The Bottom Line
Bad decisions are made by good people. The question is whether you have systems to catch them early.
The patterns are predictable. The root causes are addressable. The solutions are available.
What separates successful founders from unsuccessful ones isn't making perfect decisions. It's having the humility to know they need help, the discipline to build decision protection systems, and the courage to change course when the evidence demands it.
Need Help Avoiding Bad Decisions?
At Startupbricks, we help founders see around corners. We've made (and observed) enough bad decisions to recognize the patterns. We can help you:
- Evaluate major technical decisions before you commit
- Identify hidden risks in your current approach
- Build decision frameworks that protect you from yourself
- Create a technical strategy aligned with your business goals
If you're making a big technical decision and want perspective, let's talk.