Why I Build My Own Tools Instead of Waiting for the Right SaaS

There's a moment most developers recognize. You have a specific problem. You do a quick search, find three SaaS tools that do something adjacent to what you need, price them out, realize none of them are quite right, and either pick the least wrong one or abandon the idea entirely.

I used to default to the first option. These days, I default to neither. I just build the thing.

What most people do

The instinct to reach for an existing tool is rational. SaaS products are polished, maintained, and someone else's problem to keep running. If you need scheduling, you grab Calendly. Database, you grab a platform. A simple dashboard, someone's sold a template for that.

The problem isn't any single tool. The problem is that the instinct compounds. You end up stitching together five or six services, each with their own pricing tier, API quirk, and rate limit. The integration layer becomes its own project. You've outsourced the work but kept all the complexity.

And you still can't get the tool to do exactly what you want.

What builders do instead

At some point I started timing myself. How long does it actually take to build a stripped-down version of what I need?

For a simple vote-tracking feature - something that would cost $20-50/month if I found a tool for it, assuming the tool existed at all - the answer was a few hours. A database table, a couple of API routes, a UI that fits how I actually think about the problem. Done.

No integration overhead. No "upgrade to the Business plan for this feature." No wondering what happens to my data if the company pivots or shuts down.

The build felt faster than the evaluation.

Real examples from this site

This portfolio site is running things I could not have bought cheaply, if at all:

• Vote Room - a real-time async polling tool. I needed something lightweight enough to share in a message, with no forced sign-up friction. Nothing on the market fit. Built it in an afternoon.
• AI agent task management - the blog posts you're reading were assigned, drafted, and tracked by a small company of AI agents I built. The closest commercial equivalent would be expensive, rigid, and not designed for my exact workflow.
• Auth flow - I replaced a third-party auth service with an in-house magic link system. Fewer dependencies, full control over the session model, zero monthly fees.

None of these were built to be impressive. They were built because the alternative - finding and wiring together external tools - was slower, more expensive, and would have produced a worse result.

The hidden cost nobody talks about

SaaS sprawl has a tax that doesn't show up in the invoice: cognitive overhead.

Every external service you integrate is a surface area you have to understand, maintain, and update against. API changes break things. Pricing changes force decisions. The service gets acquired, goes down, or deprecates the endpoint you depend on. You carry all of that in your head as background noise.

Custom code is also overhead - but it's overhead you understand completely. You know exactly why it works and how to change it. There's no support ticket queue between you and a fix.

For recurring work that grows in complexity, that clarity compounds. You can move fast because you're not fighting the tool.

Where SaaS still wins

This is not a manifesto against buying software. There are categories where building is the wrong call:

• Anything with serious compliance requirements. Payment processing, data privacy, healthcare data. The regulatory surface area is too large and too dangerous to roll your own.
• Commodity infrastructure. Email delivery, DNS, CDN. These are solved problems with deep operational expertise behind them. Build on them, don't compete with them.
• Things that are genuinely complex and not differentiated. If a tool does exactly what you need, charges a reasonable price, and the integration is clean - use it. The build/buy question isn't ideological, it's practical.

The calculus changes when the tool doesn't exist, doesn't fit, or when owning the solution is itself the point.

Technical literacy as a career asset

There's a version of this argument that sounds like "real programmers write everything from scratch." That's not what I'm saying.

What I'm saying is that the ability to build your own tools - quickly, cleanly, without drama - is a professional advantage that compounds over time. You solve problems other people have to wait for. You own the things that matter. You understand your stack deeply enough to move fast when the stakes are high.

It's not a hobby habit. It's a skill that keeps paying out.

The builder mindset is not about avoiding tools. It's about knowing the difference between a tool that serves you and a subscription you're trapped in.

---

This post was drafted by the CMO agent and reviewed by Martin before publication.