For a long time, the rule fit in one sentence: never build what you can rent. Writing software took months, and a SaaS subscription delivered something close the next day, maintained by somebody else. For a small business, having custom software built was a luxury, kept for the cases where nothing on the market fit.
Half of that calculation has changed. AI-assisted development tools have collapsed the cost of a first version. The other half has not moved: software in production has to be hosted, patched and backed up, and someone has to answer when it breaks.
This article offers four tests for deciding, with both halves on the table.
The short answer, for the busy
A small business should have its own software built when the process in question sets it apart from competitors, when a SaaS tool's per-seat price climbs with headcount for features nobody uses, when staff retype data from one tool into another, or when the business wants to decide for itself where its data lives. It should rent everything else: accounting, payroll, email, a CRM for a standard sales process. In our own work, AI has brought the cost of writing a simple first version down to a few days. It has not reduced the cost of owning software: hosting, security patches, backups, support, data migration. Quebec's Law 25 does not decide for you: section 3.3 requires a privacy impact assessment whether you acquire or develop a system that handles personal information. Often the right answer is a hybrid: keep the standard SaaS tools and build the thin layer that belongs to you.
What AI changed, and what it did not
Alongside our clients' websites, we build and run our own software. Caribooks, a connector between QuickBooks and an AI assistant, went from idea to a live product taking payments in a single working day. Type Parts, a parametric CAD part generator, was built in four days. Those are our observations, not an industry statistic, but they are enough to break the old rule.
The piece on why we build our own software also covers the other extreme. ForgeMRP, our production planning software, has been running for two years on real data. There, the cost comes from the mistakes you find once people work in it every day, on data you cannot afford to lose. Writing it has become the cheap part.
Owning software means paying for five things a subscription hid inside its price. Hosting, every month. Security patches for the components it depends on, which arrive unannounced. Backups, and the test that proves you can restore them. A person who answers when it breaks, on a Tuesday at 7 a.m. And migrating the data out of the system you are leaving, almost always the line item people underestimate. AI speeds each of these up a little without removing any of them.
To "can we afford to build it?", the answer is now often yes. The useful question becomes: "do we want to own this for five years?"
Test one: does this process set you apart?
A SaaS product is an average. It encodes how thousands of companies do the same thing, which is exactly what you want for payroll, accounting or email.
The math changes for the process your reputation rests on: how you put together a quote from your real costs, how you schedule a shop floor, how you keep a client informed about their file. If your team has already bent a SaaS tool every which way to fit that process, with repurposed custom fields and a spreadsheet on the side, that is a signal. The software is imposing its average on the one thing where you are not average.
The opposite trap exists too. Plenty of processes that feel unique are not. A simple test: if a client would notice the difference, the process sets you apart. If only your accountant would notice, rent.
Test two: per-seat pricing, at your headcount
Most business SaaS bills per user. Painless at three people, the model hurts a lot more at twenty: the bill tracks headcount, not the value the tool gives you.
A real example, read on HubSpot's pricing page on September 24, 2026: Sales Hub Professional starts at CA$117 per seat per month billed annually (CA$130 paying monthly on an annual commitment), plus a required one-time onboarding fee of CA$1,950. For ten salespeople, billed annually, that is CA$14,040 a year, and CA$15,990 in the first year with the onboarding fee. For twenty, CA$28,080. The price is not outrageous; the question is how much of the tool you actually use.
Add up your per-seat subscriptions over three years, at the headcount you expect rather than today's. Then underline the features your team really uses. If the underlined list fits on a few screens and the total is high, a custom tool deserves at least a conversation. If the list is long, or you rely on what the vendor improves every quarter, stay put.
Custom software has a different cost curve, not necessarily a lower one: it follows complexity, not the number of people logging in. Adding an employee costs almost nothing. Adding a feature does.
Test three: how many tools do you retype between?
The most reliable symptom hides in your team's time. An order comes in through the online store, someone re-enters it in the production system, then in QuickBooks, then emails the client to say where it stands. Each tool is fine on its own. The cost is in the seams.
That is often where custom work pays off most, and rarely by replacing a SaaS product. You keep QuickBooks, the CRM and Stripe, and build the thin layer that connects them and carries your way of working: an integration that syncs, an internal tool that replaces the shared spreadsheet, a portal where clients check the status of their file instead of emailing you. That layer is small, it belongs to you, and the vendors keep doing the work they do well.
Before writing a line of code, check whether an automation tool will do. For a linear, predictable flow, a no-code tool gets the job done; we covered where the limit sits in our no-code versus custom comparison. Inside the Microsoft ecosystem, Copilot Studio also covers part of the need.
Test four: where your data lives, and how you get it out
Quebec's Law 25 is more neutral on this than people assume. Section 3.3 of the Act respecting the protection of personal information in the private sector requires a privacy impact assessment for "any project to acquire, develop or overhaul an information system" involving personal information. Buying a SaaS product and commissioning a custom tool trigger the same obligation. The same section adds a lesser-known requirement: the project must allow computerized personal information collected from a person to be communicated to them "in a structured, commonly used technological format." Rented or built, the system has to export a person's data cleanly.
The difference is control. With SaaS, you assess the vendor: where it hosts, which subcontractors it hands your data to, and whether it keeps that data outside Quebec, in which case the law requires a prior assessment and a written agreement (s. 17). With a custom tool, you choose the host and the region yourself, and the assessment covers decisions you made.
That leaves the exit cost, the line item both sides forget. When leaving a SaaS product, check what actually exports: raw data, often; history, attachments and automations, not always. When hiring a developer, ask the mirror-image questions: who owns the code, whose name the hosting and database accounts are in, and who else could take over the system tomorrow. Custom software whose code and accounts you do not control is a SaaS product with a single customer, and fewer guarantees.
When renting is still the right answer
Most small businesses should rent most of their software. Three situations lean clearly toward the subscription.
The function is regulated and changes often: payroll, sales tax, accounting. The vendor absorbs rule changes for thousands of customers at once. In e-commerce the reasoning is the same, and we covered it in Shopify or a custom store: as long as your need is standard, the platform wins.
Nobody in the business can own the tool. Custom software needs an internal owner who decides what it should do and notices when it stops doing it. Without that person, even a good tool drifts.
The process is not stable yet. If the way you work changes every three months, freezing it in code is premature. A flexible SaaS tool, or a well-kept spreadsheet, lets you learn before you build.
Where to start
Run the four tests on a single process, not the whole company. Pick the one that generates the most retyping or follow-up emails, work out what you pay in subscriptions to support it, and note where its data lives today. If three of the four tests point toward custom, skip the forty-page specification: build a small first version and put it in front of the people who will use it.
That is the work we do at Peich: client portals, internal tools and integrations with the systems you already use, delivered in two-week cycles, then hosted and maintained by the team that wrote them. Bring us the process that costs you the most retyping: we will run the four tests with you, and tell you when the answer is to rent.
→ Let's talk about your project
Written byXavier Peich