Most software decisions at a growing company start the same way: someone on the team says
“we need a system for this,” and within a week there are two camps. One wants to sign up for
whatever SaaS tool solves 80% of the problem today. The other wants to build something that
fits exactly. Both are usually right about something, and both are usually missing something too.
We get asked this question a lot at Kerss — sometimes explicitly (“should we build or buy?”),
more often indirectly, when a client comes to us frustrated with a platform they’ve outgrown, or
nervous about a six-figure custom build they’re not sure they need. So this post is less a
theoretical framework and more a writeup of how we actually think through it with clients.
What “off-the-shelf” actually buys you
Off-the-shelf software — think accounting platforms, CRMs, HR tools, e-commerce platforms —
exists because thousands of companies have nearly identical versions of the same problem.
Someone has already solved invoicing. Someone has already solved payroll compliance.
There’s rarely a good reason to re-solve it yourself.
The real advantage isn’t just cost, though the lower upfront price is what gets mentioned first.
It’s speed and maturity. A product that’s had five years and ten thousand customers pushing on
it has had its edge cases found and fixed by someone else’s support tickets, not yours. When
we’re advising a client with a fairly standard requirement — basic CRM functionality, project
tracking, email marketing — we almost always point them toward an existing product first.
Building that from scratch would be, frankly, a waste of their runway.
Off-the-shelf tends to be the right call when the requirement is common enough that mature
products already exist for it, when speed matters more than a perfect fit, when the team is still
validating how it wants to work rather than just what tool to use, or when the software supports
the business but isn’t part of what makes it competitive.
Where custom software earns its cost
Custom software gets a bad reputation partly because it’s often pitched — by agencies, not
always us — as the serious or professional option, as if buying SaaS is somehow cutting
corners. That’s not true. Custom makes sense in narrower, more specific situations, but in those
situations it’s not a luxury, it’s the only thing that actually works.
The clearest signal is when a team is spending real hours working around their software rather
than with it. We had a client whose ops team was pulling data out of their inventory system
every morning, cleaning it in a spreadsheet, and re-uploading it into a separate fulfillment tool by
hand, every single day. That’s not a training problem or a “use the software better” problem.
That’s two systems that were never designed to talk to each other, and no off-the-shelf product
was going to fix that without becoming, itself, a custom integration project.
We see a version of this constantly with inventory and fulfillment. A retail or distribution business
has one system for stock and a different one for order fulfillment, and the two were never built to
talk to each other. So someone on the team ends up as the human integration layer —
exporting a report every morning, cleaning it up, re-uploading it somewhere else, and hoping
nothing gets missed on a busy day. Multiply that by a few hours a day, every day, and it stops
looking like a minor inconvenience and starts looking like a part-time job that exists purely
because two tools don’t connect.
That’s the pattern worth watching for: not “do we like our software,” but how much of the week
goes into making the software behave like the business, rather than the other way around.
Custom also earns its place when the software is the business — a proprietary matching
algorithm, a customer portal that’s part of the product experience, an internal tool that gives your
team an edge competitors don’t have. In those cases you’re not buying infrastructure, you’re
building an asset.
Where each approach tends to go wrong
It’s easy to talk about both options in their best light. It’s more useful to talk about how they
actually fail, because that’s usually what determines which one was the right call in hindsight.
Off-the-shelf software tends to go wrong slowly. A platform that was a great fit at 10 employees
can start to strain at 50, not because it broke, but because the workarounds started piling up —
a spreadsheet here, a Zapier chain there, a “we just don’t use that feature” here. Pricing is the
other common failure mode: per-seat pricing that looked negligible during the sales call can turn
into one of the larger line items on the budget once the team doubles. And there’s a structural
risk too — you don’t control the roadmap. If the vendor deprioritizes a feature your workflow
depends on, or gets acquired and the product gets folded into something else, you’re along for
the ride whether you like it or not.
Custom software tends to go wrong quickly and visibly, which is part of why it has a worse
reputation. Scope creep is the most common one — a project that was supposed to take three
months stretches to eight because “while we’re in there” requests kept getting added. Under-
scoped discovery is another: a team commits to a build before anyone has actually mapped out
the edge cases, and those edge cases show up mid-development as expensive surprises. And
there’s a longer-term risk that doesn’t show up until later — what happens if you want to switch
development partners, or the original team moves on. Custom software is only as maintainable
as its documentation and architecture, and not every shop leaves those in good shape.
Neither list is a reason to avoid one approach entirely. They’re both reasons to go in with eyes
open about what you’re trading for what.
The cost question people ask wrong
Almost everyone asks “which one is cheaper,” meaning cheaper today. That’s the wrong
comparison. A subscription is cheap in month one and can get surprisingly expensive by year
three once you’ve added seats, premium tiers, and the three integrations you didn’t realize you’d
need. Custom software is the opposite curve — expensive up front, and then mostly just
maintenance.
Neither curve is automatically better. It depends on how long you expect to be using the thing
and how much your requirements are likely to change in that window. We usually push clients to
run the numbers out three to five years, subscriptions included, before deciding — because the
sticker shock of a custom quote next to a $49/month SaaS plan is misleading if you’re going to
be paying that $49 across forty seats within two years.
Time to launch is the one place off-the-shelf clearly wins
If a business needs a working CRM next week, that’s not really a build-vs-buy conversation —
buy wins, full stop. Custom development takes time because someone has to design, build, test,
and deploy it, and there’s no shortcut around that.
That said, “custom” doesn’t have to mean “built entirely from zero.” Most of what we build leans
heavily on existing frameworks, cloud infrastructure, and third-party APIs for anything that isn’t
the differentiated part of the product. A well-scoped MVP — the core workflow first, the nice-to-
haves later — can get a client to something usable a lot faster than people expect. The teams
that get burned on custom timelines are usually the ones that tried to build everything at once
instead of shipping the 20% that actually matters first.
Scalability isn’t automatic on either side
Both approaches can scale. Both can also fail to.
An established SaaS product has usually been stress-tested by customers much bigger than
you, which is reassuring — but you’re also at the mercy of its roadmap. If your needs outgrow
what the product’s roadmap supports, you’re stuck, no matter how well-architected the platform
is under the hood.
With custom software, scalability is a design decision, not a guarantee. We’ve inherited
codebases from other shops that were technically “custom” but built with no real architecture
behind them — which scales about as well as a spreadsheet duct-taped to a database. Custom
buys you the option to build for scale. It doesn’t hand it to you for free.
Who maintains it after launch
This part gets skipped in most build-vs-buy conversations, and it shouldn’t, because it’s where a
lot of the real long-term cost and risk actually lives.
With off-the-shelf software, maintenance is mostly someone else’s job. The vendor patches
security issues, ships updates, and keeps the infrastructure running. Your responsibility is
mostly configuration and keeping your team trained on changes — a real cost, but a bounded
and predictable one.
With custom software, maintenance is yours, one way or another, whether that means an in-
house developer, a retainer with the agency that built it, or a new team entirely if you decide to
switch partners. This is where documentation and code quality matter more than they get credit
for during the initial build. A well-documented, cleanly architected custom application can be
handed off to a new developer with a reasonable ramp-up period. A custom build with no
documentation and tangled architecture can effectively hold a business hostage to whoever built
it — which is a real risk worth asking about before signing a contract, not after.
This is also the question we’d encourage any business to ask a development partner directly:
what does handoff look like if we ever need to work with someone else? A good answer should
be specific — documentation practices, code ownership, deployment access — not just
reassurance.
The hybrid option people forget exists
The decision doesn’t have to be all-or-nothing, and honestly, most of the systems we build for
clients aren’t. A common pattern: a client keeps an established accounting platform and CRM,
and we build a custom layer that connects the two and handles the specific workflow that
neither product does natively. Another common one — Shopify (or similar) for the storefront,
custom-built for the customer portal, internal ops tooling, or reporting that the platform doesn’t
support out of the box.
We’ve also seen the reverse pattern work well: a client with a core custom platform — the thing
that’s actually their product — surrounded by off-the-shelf tools for everything that isn’t. Support
runs through a standard helpdesk tool rather than something custom-built. Internal comms run
through Slack, not an internal messaging system nobody asked for. The custom investment
goes entirely into the part of the business that’s actually differentiated, and everything else gets
bought, because building it would just be reinventing a wheel that’s already round.
The useful question isn’t “build or buy” as a single company-wide policy. It’s “which parts of what
we do are commodity, and which parts are ours.” Buy the commodity. Build the part that’s
actually yours.
Five questions worth asking before you commit
- Does an existing product cover 80–90% of what we actually need? If yes, that’s a strong signal toward buying — and toward not overvaluing the missing 10–20%
- How much are we bending our process to fit the software, versus the software fitting us? Minor configuration is normal. Daily manual workarounds are a warning sign.
- Is this system part of how we compete, or just how we operate? Infrastructure can usually be bought. Differentiators usually shouldn’t be.
- What does this cost over three to five years, not just this quarter? Include seats, tiers, integrations, migrations, and the hours your team spends working around limitations.
- Are our requirements stable enough to build for? If the process is still changing month to month, that’s a reason to wait, not a reason to rush into a custom build.
The honest answer
There isn’t a universal right answer here, and anyone who tells you there is — in either direction
— is usually selling something. For standard, well-solved problems, buying is almost always the
smarter move, and we tell clients that even when it means less work for us. For workflows that
are genuinely specific to how your business operates, or software that’s meant to be part of your
competitive edge, custom is where the investment actually pays off.
The useful first step isn’t deciding build-vs-buy in the abstract. It’s getting specific about what
your team is actually spending time on, and where the friction really lives. That’s usually where
the answer becomes obvious.
If you’re weighing this for your own business and want a second opinion before committing
either way, that’s a conversation we’re happy to have — no build required to start it.