A few hundred years ago, if you needed a sword โ not a display piece, a sword you'd actually use โ you had two options. You could buy one off a shelf at the smithy. It would work. It might even be well-made. But it was built for no one in particular, which means it was built perfectly for no one.
Or you went to a blacksmith who sat down with you, measured your reach and your grip strength, watched how you moved, understood your fighting style โ and made you something that felt like an extension of your arm. Some warriors named their swords. When a weapon is that precisely yours, it earns a name.
The sword that fits
That wasn't craftsmanship for its own sake. A sword that doesn't fit the warrior is a liability โ too heavy, poorly balanced, tiring the arm before the fight is over. The fit wasn't aesthetic. It was strategic.
The same logic applies to software. Most businesses run on tools that were built for someone else. An accounting package designed for generic SMBs. A CRM that works well for the company in the sales deck but needs workarounds for how your team actually operates. An inventory system that almost tracks what you need to track, and requires a spreadsheet column on the side to handle the exception that is, actually, half your business.
It works. Sort of. Until it doesn't.
Some businesses don't need the best sword in the shop. They need the sword that was made for them.
Off the shelf and off the mark
Off-the-shelf software is built for the broadest possible audience. That's not a flaw โ it's the design intent. Every feature decision is made for an aggregate customer, not for your specific operation. The product needs to be general enough to sell broadly, which means it's constantly trading depth for width.
For many businesses, that's the right call. If your workflow is standard, your industry is well-served, and the tool does 90% of what you need โ buy it. There's no prize for custom software when a proven product already fits.
But some businesses aren't standard. Their operation is the differentiator. Their workflow, their logic, their specific way of doing things โ that's what makes them competitive. For those businesses, forcing the work into a generic tool doesn't just cause friction. It actively dilutes what makes them good.
A commission, not a product
Building a SaaS product and building custom software are not the same discipline. They share a technology stack and sometimes a vocabulary. The job is different.
A product company is building for the market. Every decision is a bet on what the largest slice of users will want. Features that some users love get cut because most users don't need them. Flows are designed for the most common path, not the edge case that happens to be your core workflow.
Custom software is a commission. The developer's job is to understand your operation deeply enough to build something that fits it precisely. That requires different questions, a longer discovery process, and a fundamentally different kind of attention. A good custom developer doesn't just ask what you want โ they ask why you work the way you do, where things break down, what you've tried before, and what the business will look like in three years.
There are no generic clients in custom development. There are only specific ones. If your developer is treating you like a generic client, they're doing product development, not custom work.
What to ask before you sign
If you're commissioning custom software, you're not buying a product off a shelf. Here's what's worth asking before you commit:
- Do they understand your business before they talk about technology? If the first conversation jumps straight to timelines and tech stacks, that's a flag. The technical decisions should follow the business understanding, not precede it.
- Have they worked in your industry or an adjacent one? Not a requirement โ but relevant. Someone who's worked in distribution or logistics or pharma will ask different questions than someone who hasn't.
- Who specifically will be writing your code? And can you talk to them before you sign? If the answer requires a follow-up meeting to find out, you know what you're dealing with.
- What does the relationship look like after go-live? Custom software lives in your business for years. It will need changes as your business changes. Ask what that looks like โ not as an afterthought, as a core part of the engagement.
- Can they put you in touch with previous clients? Any shop worth working with has businesses they've built for and stayed in touch with. If they can't, ask why.
Don't go cheap in battle
This is where most businesses get it wrong.
Custom software is an investment. The cost of doing it right is real. But the cost of doing it wrong compounds quietly โ slow systems, constant workarounds, a codebase that nobody but the original developer understands, and eventually a rewrite that costs more than the first build did. The cheapest quote is almost never the cheapest outcome.
The blacksmiths with the best reputations were not the cheapest ones in the market. They were the ones who'd made weapons that worked โ in actual use, over years, under pressure. Warriors who were serious about staying alive didn't haggle over that.
What you're looking for is a developer who has shipped things that still work. Clients they're still in contact with. A track record that holds up when you actually check it. Price is part of the equation, but it's not the lead variable โ reliability is.
A sword made to fit you, by someone who knew what they were doing, forged to last. That's what custom software is supposed to be. Don't settle for anything less just because it was cheaper.
