I’ve spent the last few months building custom tools instead of buying them.
Not because I’m stubborn about buying software. But because I kept running into the same problem: the thing I needed didn’t exist in a box.
People ask me constantly now: should I build or should I buy?
The answer is almost never obvious. It depends on what you’re actually trying to solve.
The problem
You have a workflow. It’s specific to how you work. You look for a tool to support it.
Two paths appear:
Path 1: Buy a SaaS tool that handles it (mostly). Adapt your workflow to fit the tool. Pay monthly. Hope the tool evolves the way you need.
Path 2: Build something custom. Invest time upfront. Own it forever. It does exactly what you need and nothing more.
Most people never consider Path 2. They assume building requires being a developer. It doesn’t. But it does require being clear about what you actually need.
The insight
The decision isn’t about price. It’s about fit.
A SaaS tool is perfect when your workflow is standard. When thousands of other people do the same thing the same way. The economics work. You pay a small amount and get a polished product built by a team.
But the moment your workflow is specific, the moment you have constraints that don’t fit the box, the math changes. A custom tool becomes cheaper and faster than forcing yourself into someone else’s system.
The key question isn’t: Can I build this? It’s: Does this tool actually fit how I work?
The approach: a framework
I’ve built three custom tools now. Here’s what I ask before building versus buying:
Buy SaaS if:
- Your workflow is standard (thousands of people do it the same way)
- The tool handles 90%+ of what you need
- You don’t have specific brand voice or UX requirements
- The monthly cost is acceptable and predictable
- The tool evolves with your needs
Build custom if:
- Your workflow is specific to your business
- You’ve outgrown or rejected multiple SaaS options
- You have tight budget constraints but not time constraints
- The tool only needs to do one thing, but needs to do it perfectly
- You have a specific voice, tone, or user experience requirement
- You’re willing to own the maintenance
Examples from my work:
Gallery and booking system: Built custom because Pixieset didn’t understand European VAT requirements, the booking flow needed to be maternity-specific, and I needed complete control over the client experience.
Blog tool: Built custom because I was paying across five subscriptions (ChatGPT + scheduler + calendar + drafting tool + WordPress integration) when I really just needed one integrated workflow.
Mercury Hunter: Built custom because no tool exists that consolidates campaign data from five different sources into one searchable interface designed exactly for how our team works.
In each case, the SaaS option existed. It just didn’t fit.
Why this matters
The metrics tell the story:
Gallery and booking:
- Pixieset: €18/month + €8/month for galleries + invoicing that didn’t work = abandonment
- Custom: Built once, owned forever, perfect fit
- Result: €0/month, 100% control, better client experience
Blog tool:
- SaaS subscriptions: €50-100/month across multiple tools
- Custom: €0.30 spent so far on API credits, 150+ hours per year saved
- Result: 75-80% time reduction, zero recurring costs
Mercury Hunter:
- No equivalent SaaS exists at any price
- Custom: Built to solve the exact problem
- Result: 98% time reduction on campaign analysis, changed how decisions get made
The real win isn’t just cost. It’s that custom tools eliminate friction. They do exactly what you need. Nothing more, nothing less.
The principle
Generic solutions are cheaper to build but expensive to use when they don’t fit. Custom solutions are expensive to build but free to use forever.
The breakeven point is usually around 6-12 months. If you’ll use the tool for longer than that, and it’s specific enough that no SaaS fits, building often wins on cost alone. Add in the improved workflow and better user experience, and it becomes obvious.
What I learned
Building three custom tools taught me that the barrier to entry is lower than people think. You don’t need to be a developer. You need:
- A very clear understanding of your problem
- Willingness to learn just enough to build it
- Patience to iterate
- AI to help you when you get stuck
What surprised me most: every tool I built solved a problem that someone else probably has. But because it was specific to my workflow, I built it for myself. The specificity is a feature, not a limitation.
The second insight: constraints force better design. When you’re building for one specific use case, you can’t add bloat. You can’t chase every feature request. You build exactly what’s needed.
The question
Before your next SaaS subscription, ask:
Is this tool solving my problem, or am I adapting my problem to fit the tool?
If it’s the latter, that subscription will always feel like friction. And that’s usually when building makes sense.