When to Stop Paying per Seat
How to run the break-even between per-seat software and a custom build.
Buy off-the-shelf software when a product covers most of what you need and the process is standard. Build custom software when the way you work is part of your advantage, when you are paying for seats to get one feature, or when your team spends real time working around a tool that does not fit. Most businesses end up doing some of both. This guide walks through how to tell which situation you are in.
Updated September 2026 · Stephen Backholm, Founder
| Buy Off-the-Shelf When | Build Custom When |
|---|---|
| A product covers 80 percent or more of what you need | The software does not fit your process, and your team works around it |
| The work is commodity, like accounting, payroll, or email | The way you do the work is part of what sets you apart |
| You need compliance certifications you cannot justify obtaining yourself | You are paying for many seats to get one feature |
| The process will change substantially within a year | Read-only users are paying for full seats |
| You need something working this week, with no build at all | A critical process depends on a spreadsheet only one person understands |
When you buy software you are renting more than features. You are renting a product roadmap, a support organization, a security team, a compliance posture somebody else paid to certify, and the accumulated result of thousands of other customers finding the bugs before you did. You can usually start the same day, and the cost is predictable.
The costs show up in three places. The first is fit: a product built for the widest possible market will not match your process exactly, and the gap gets filled with workarounds, spreadsheets, and manual steps. The second is scale: per-seat pricing is affordable at ten users and expensive at a hundred, and it keeps rising. The third is control: your data lives in someone else's system, the roadmap is theirs, and integrations go only as far as the product allows.
Custom software is built around the way you already work. You own it, there is no per-seat pricing, it connects to exactly the systems you need, and it can encode the part of your process that is genuinely yours.
It also comes with responsibilities. There is an upfront cost. It needs maintenance: budget roughly 5 to 20 percent of the build cost each year, plus hosting. The roadmap becomes yours, which means someone has to decide what comes next. And you have to be able to describe what the software should do; if nobody can, building is premature.
Custom software gives you exactly what you asked for and nothing you did not. That is its strength and its limit.
For years, custom software meant a team of five to seven people for three to six months, which put a moderate build well into six figures. Most of those hours went into implementation work that required care but not judgment: scaffolding, data layers, forms, test harnesses, integration glue.
AI-assisted development compresses that layer dramatically. It does not compress architecture, data modeling, security review, or knowing what to build, so experienced engineers still matter as much as ever. But a small team now produces what used to need a large one, on the work where the compression applies.
The practical consequence: if you priced a custom build a few years ago and walked away, the assumptions behind that quote may be obsolete. At True Cedar, a single-workflow web application costs under $10,000, and multi-role applications and client portals typically run $18,000 to $45,000. The pricing page sets out the full ladder, including where the savings do not apply.
True Cedar figures and commitments here are examples to help you plan, not a quote, an offer, or a contract. Every engagement is governed by its own written statement of work and agreement.
The most common good answer is neither pure build nor pure buy. Keep mature products for the commodity work, such as accounting, payroll, email, and often your CRM. Build the layer that is specific to your business on top of them, and connect the two so nobody re-keys data between them.
That is how most custom software actually gets used: a client portal that pulls documents from the systems you already run, an internal tool that replaces the spreadsheet between two products, or an AI agent that works inside the CRM your team lives in.
How to run the break-even between per-seat software and a custom build.
The signs a spreadsheet has become a business system.
When a flexible tool has turned into a workaround.
Four questions that tell you whether a software problem is worth revisiting.
What to ask before you hire anyone to build custom software.
What to check so the software you pay for is actually yours.
It can be, when the software replaces real recurring costs: per-seat subscriptions, hours of manual work, or errors from workarounds. A single-workflow web application can cost under $10,000, which puts custom software within reach of businesses that could not justify it a few years ago. If an off-the-shelf product already fits your process, buying is usually the better choice.
SaaS costs less to start and more over time as seats grow; custom software costs more to start and less over time. For example, forty users at $45 per seat cost $21,600 a year, while a $28,000 custom tool costing about $4,000 a year to maintain pays for itself in about nineteen months. These are illustrative figures, not a quote.
A single-workflow web application can be built in about five business days. Multi-role applications and client portals typically take two to five weeks, and projects with legacy data migration or compliance scope typically take five to ten weeks.
If you own the source code, the data, and the infrastructure accounts, and the software is built on a mainstream stack, any competent developer can pick it up and keep going. That is why ownership and technology choices matter as much as price when you hire a firm.
Usually buy. A CRM is a well-served category with mature products. Build the pieces around it that are specific to your business, such as a custom workflow, a client portal, or an agent that works inside the CRM, and connect them to the product you already run.
Tell us what the software needs to do. We will tell you whether to build it, buy it, or connect what you already have, including when the answer is to buy.