Build vs Buy vs Fix
Most founders either over-invest in custom software or under-invest by patching broken tools. Here's a framework for making the right call.
When to Build
Custom software makes sense when your needs are genuinely unique. Not "I want it to feel unique" — but structurally, your business operates differently from what existing tools assume.
- → Your workflow is unique. You've tried 5 off-the-shelf tools and none of them fit how your team actually works.
- → Software is your competitive advantage. The way you operate is what makes you different — and you need a system that encodes that advantage.
- → Existing tools can't do what you need. Not "they don't have this feature" — but "the fundamental architecture doesn't support this workflow."
- → Arabic-first is critical. You need RTL as the primary experience, not a toggle. Your team works in Arabic and the software needs to match.
- → You're scaling beyond off-the-shelf. Your volume, complexity, or multi-location needs exceed what any SaaS can handle.
When to Buy
Existing tools are the right choice more often than most developers will admit. If a SaaS product does 80% of what you need, use it. The remaining 20% isn't worth a custom build.
- → Your workflows are standard. Invoicing, CRM, project management — these are solved problems. Don't reinvent them.
- → Your team is small. Under 20 people? You need simple tools, not enterprise architecture.
- → Budget is limited. $50/month for a SaaS vs. $5,000+ for custom software — the math is simple when you're starting out.
- → You need it fast. If the problem is costing you money today, a tool you can set up this week beats a custom build that takes 3 months.
When to Fix
The most overlooked option. You already have a system. It's not great, but it works — kind of. Before you burn it down, ask whether targeted repairs would get you where you need to be.
- → The core is solid. The fundamental job gets done. It's the surrounding experience that's painful.
- → Your team likes the system. They know it. They've built habits around it. A new system means retraining everyone.
- → Specific parts are broken. Not everything — just 2 or 3 things that cause 80% of the pain. Fix those and the system becomes usable.
- → You've already invested heavily. Data, integrations, processes, team training — the switching cost is real.
Still not sure?
Tell me about your problem and I'll give you an honest answer — whether that means building something new, recommending an existing tool, or fixing what you have. No sales pitch, just my honest take.
Or email [email protected]