Custom software vs off-the-shelf: an honest framework from someone who builds custom

Buy off-the-shelf software for problems every business has: accounting, email, payroll, project tracking, CRM in the early days. Build custom when the workflow is specific to how you make money, when per-seat pricing has grown past the value you get from the tool, or when your team spends hours every day moving data between systems that refuse to talk to each other. That one rule settles most cases. This article is for the rest: the framework I use on discovery calls, the three-year math, and the middle path that usually beats both extremes.

A disclosure that doubles as a credential: custom software is what I sell. I have built and maintained it since 2015, including one platform that has run the same business for a decade. And still, a good share of the people who contact me get the same advice: do not build yet. A custom system that should have been a $40-per-month subscription is a failure I would have to maintain, and it tends to come back around.

When off-the-shelf is the right call

Most of the time, honestly. Buy, do not build, when:

• The problem is a commodity. Accounting, payroll, email marketing, support tickets, document signing. Thousands of companies share your exact problem, so the SaaS products in these categories are polished by years of other people’s feedback you get for free.
• Your process is still changing. If how you work shifts every month, configuration changes in a SaaS tool cost minutes. Code changes cost more. Build after the process stabilizes, not before.
• A standard tool fits 90% of the way. Living with the missing 10% is usually cheaper than owning software. Adapt the process to the tool when the process is not what makes you win.
• Nobody owns the workflow internally. Custom software needs one person who can answer a builder’s questions and make decisions. If that person does not exist, the project stalls no matter who builds it.

When custom earns its cost

Build when at least one of these is true:

• The workflow is your edge. If the way you quote, schedule, fulfill or deliver is the reason customers pick you, generic tools flatten exactly the thing that makes you different. This was the case for Kapa, whose entire product is a workflow no off-the-shelf tool expressed.
• The per-seat math broke. SaaS pricing scales with headcount whether or not value does. At 30 users on $50-per-seat tools you are paying $18,000 a year, every year, for software that almost fits.
• Your team is the integration. When people re-type the same order into three systems daily, you are paying salaries to be middleware. Software that moves data automatically pays for itself fast, and it removes the copy-paste errors too.
• The tool now dictates your process. The moment you hear “we do it this way because that is how the system works,” the software owns you. Custom reverses that relationship.

What does the three-year math look like?

Two real-shaped scenarios, using the same ranges from my pricing guide.

Scenario A: 8-person team, standard project tracking. An off-the-shelf tool at $12 per seat costs about $3,500 over three years. A custom equivalent would run $15,000 to build plus roughly $2,000 a year to maintain. Off-the-shelf wins by a factor of six, and it is not close. This is most scenarios.

Scenario B: 30-person operation with a workflow-specific process, currently spread across three SaaS tools and daily manual copying between them:

Cost over 3 years	SaaS stack	Custom system
Subscriptions	$52,900 (30 × ~$49/mo)	$0
Build	$0	$35,000
Maintenance and hosting	$0	$17,500
Manual data-moving labor	~$39,000 (10 h/week)	~$4,000 (residual)
Total	~$92,000	~$56,500

Same company, three years, roughly $35,000 apart, and the custom system is an asset you own at the end instead of a subscription you still owe. The swing factor is almost never the license fees. It is the salaried hours spent working around tools that almost fit.

Run this table for your own numbers before believing anyone’s pitch, including mine. If SaaS wins, buy the SaaS.

The middle path: buy the commodity, build the glue

The best-performing projects I have delivered are not full platforms. They are small custom pieces connecting off-the-shelf tools that were never going to talk to each other: keep the CRM, keep the accounting software, and build the integration that moves data between them the way your operation needs.

My favorite example is from Kapa. Several agency clients loved Trello and did not want to leave it, while our operation ran on our own platform. Instead of forcing anyone to switch, we built a two-way sync. A card moved on their Trello board updated our system, and our updates appeared on their board. They kept their tool, we kept our workflow, and the sync cost a fraction of what losing those clients would have.

Glue projects land in the $2,000 to $8,000 range, ship in weeks, and are the cheapest way to find out what working with a particular engineer is like before you commit to anything bigger.

A decision checklist you can steal

Seven questions. Be strict with yourself:

1. Is this workflow part of how you win customers, or is it admin? Admin means buy.
2. Have you actually exhausted the configuration options of the tool you already pay for? Spend one afternoon confirming this. It is the cheapest afternoon in software.
3. Has the process been stable for six months or more? If it still changes monthly, it is too early to build.
4. Do people re-enter the same data into two or more systems every day?
5. Is the per-seat bill growing faster than the value per seat?
6. Is there one person who owns this process and can make decisions about it?
7. Can you fund maintenance at 10 to 20% of the build cost per year without it hurting?

Zero or one “yes” on questions 3 through 7: buy, or build a small glue piece at most. Four or more: run the three-year table, because you are probably paying the custom price already, just spread across subscriptions and salaries.

What I tell people who should not build yet

Some version of this happens on my calls every month. The signs I flag, and what I suggest instead:

• Total budget under $5,000 for a multi-workflow system. The math does not work. Automate the single most painful step instead, and revisit in a year.
• The process changes weekly. Stabilize first. Software freezes process decisions into code, and you do not want to freeze churn.
• No internal owner. Assign one before hiring anyone, or the project will die of unanswered questions.
• The plan depends on reselling the tool to peers. Building for your own operation and building a sellable product are different projects with different costs. Fund the decision with one goal, not both.

Telling someone not to hire me is also the cheapest marketing I do, because the ones who should build tend to come back when it is time.

If you are somewhere in the middle and want a second opinion on your specific stack, the free audit below is exactly that: you describe how you work today, I reply with buy, build or glue, and what it would realistically cost.