When the Right Answer Is "Don't Build This"

There's a version of this post that's self-congratulatory — the developer who talked a client out of a project and saved them a fortune. That's not what I'm writing. I'm writing about the tension I feel every time I'm being asked to build something that already exists, and why I've learned to name that tension out loud instead of staying quiet.

Custom software is expensive. Not just to build — to maintain, to scale, to hand off, to debug at 11pm when the wrong environment variable makes it to production. When someone hires a studio like mine, they're making a long-term commitment to a codebase. That commitment has real costs, and those costs compound over time in ways that aren't obvious up front.

Most founders and product owners understand this abstractly. What they don't always see is when it applies to their specific situation.

The Signs I Watch For

The clearest signal is when a client describes a problem and I recognize it as a solved problem — one with several mature, off-the-shelf solutions that weren't built yesterday. Scheduling, payments, notifications, document generation, email delivery, authentication, access control. The list is long. These are things where the edge cases have already been discovered, the security vulnerabilities have been patched, and the API has been designed by people who've thought about nothing else for years.

When a client wants to build any of these from scratch, my first question is: what's wrong with the existing options?

Sometimes the answer is legitimate. The existing tools don't fit the business model. The integration costs are prohibitive. There's a compliance or data-residency requirement that rules out the obvious choices. The workflow is genuinely unusual enough that every tool they've tried has bent badly around it.

But a lot of the time, the answer is: they haven't fully evaluated them, or they've made one attempt and hit a friction point that felt like a wall but wasn't.

The Seduction of Building

I understand why people want to build. Control is real. A custom solution can do exactly what you need, look exactly the way you want, and evolve in any direction you choose. There's no pricing tier that suddenly changes, no deprecation notice, no feature you're waiting on a roadmap for.

There's also something psychological about it. Founders who've built something tend to have a builder's instinct — they see problems and they want to make something. That instinct is why they got where they are. It doesn't always serve them when the problem is already solved.

I feel this pull myself. I work on a music licensing platform, and every time I run into a category of functionality — something like metadata normalization, or rights territory management — there's a part of me that wants to build it the right way, our way. Usually I can trace that impulse to a specific frustration with an existing tool. Sometimes the frustration is valid. Sometimes I'm just underestimating how much maintenance I'm about to sign myself up for.

The Actual Conversation

When I think a client is about to commission something they shouldn't, I say so. Not as a hard no — as a question. "Before we spec this out, have you looked seriously at X and Y? Here's what I'd want to know before ruling them out."

This conversation is better early. Once a project is scoped, priced, and emotionally committed to, the incentives shift. The client wants confirmation, not reconsideration. I want to start the work I've already planned. Neither of us is in the right frame of mind for an honest assessment.

What I'm trying to determine in that early conversation is whether the need to build is real or assumed. Real reasons exist: edge cases in the existing tools that genuinely don't bend, integration costs that make custom cheaper than a vendor over a two-year horizon, workflows specific enough that no existing product handles them without serious distortion.

Assumed reasons tend to sound like: "We want to own it," "We don't want to be locked in," "We could build something better." These are fine instincts, but they're not reasons. Owning it means maintaining it. Lock-in is real with vendors, but it's also real with custom code — you're locked in to your own architectural decisions and whoever knows the codebase. Building something better takes time and money and iteration that most projects don't have.

What Off-the-Shelf Actually Costs

I'm not naive about the tradeoffs. Third-party tools have real costs: the pricing changes, the APIs evolve, the support is impersonal, the feature you actually need is on the enterprise tier.

I work with third-party services constantly — authentication, storage, email, billing, search. I've been caught by all of those problems at some point. A provider raised prices significantly. An API changed in ways that required a rewrite of the integration layer. A feature disappeared from the plan I was on.

These are real costs. I factor them into decisions. But they're mostly survivable — you can swap providers, you can absorb a price increase, you can write your integration against a well-designed abstraction layer that makes replacement feasible. What's harder to survive is a year of engineering time spent building a system that, in retrospect, you didn't need to build.

The Times I Get It Wrong

I don't always call this right. I've talked clients out of building things that, with hindsight, they should have built — where the vendor relationship became a recurring drag on the product and the business would have been better served by owning that layer. I've also built things that I later wished I'd outsourced, where the ongoing maintenance cost was higher than I'd projected and the custom logic turned out to be less differentiated than it seemed.

The honest answer is that it's a judgment call with incomplete information. What I can do is make sure the right question gets asked before the first line is written: are we building this because we genuinely need to, or because building feels like the right thing to do?

Sometimes those are the same. A lot of the time, they're not.

---

The most useful skill I've developed isn't knowing how to build things. It's knowing when not to.