TL;DR: focused custom tool $8,000-25,000, multi-workflow system $20,000-60,000, eight to sixteen weeks. But most businesses that think they need custom actually need the middle path: keep the tools, build only the layer between them. Read that section before the cost one.
The default advice is always to use off-the-shelf. It is cheaper, faster, and somebody else maintains it. That advice is right most of the time, and I give it regularly to people who came to us wanting something built.
There is a class of business where it stops being right, and the tell is not that a tool failed. It is that the workarounds have become their own system, and nobody can describe how the business runs without describing the workarounds.
What generic tools are genuinely good at
They shine when your workflow matches their assumptions: standard order management, ordinary project tracking, common financial processes, typical HR flows. If you sell standard products, ship them, and track normal inventory, an off-the-shelf stack handles it and will keep handling it. The tools were built for you, and no bespoke system will beat them on price or on the fact that someone else is patching them at 3am.
The signals you have actually outgrown them
Not a single failure. A pattern, and you will recognise more than one of these.
Three or more spreadsheets are the real source of truth for core operations, whatever the tools say
Someone exports from one system and imports into another every week, by hand
A tool is customised so heavily that its own updates break your configuration
New hires take three months to learn how the work is actually done, as distinct from how the software expects it to be done
You pay for six or more SaaS tools and the gaps between them are still manual
The person who understands the workarounds is a single point of failure and everyone knows it
That last one is the one that usually decides it, and it is rarely what people come in talking about. A process that lives in one person's head is a business risk regardless of software.
The middle path, which is what most people actually need
Between living with the mess and building an ERP there is an option that gets skipped, and it is cheaper than both.
Keep the tools that work. Build only the layer between them: the integration that moves data so nobody exports anything, plus one interface over the top for the few screens your team actually needs. Your accounting stays where it is. Your storefront stays where it is. What you build is the part that does not exist in any product, because it is specific to you.
Why this is usually the better trade:
A fraction of the cost: typically $3,000-10,000 against $20,000+ for a system
Weeks rather than months, so the pain stops sooner
You keep the vendors' maintenance, security patching and compliance work
It is reversible. A failed integration layer costs you the layer, not your operations.
We propose this more often than we propose a build, and it is a smaller invoice for us. The reason is simple: it is right more often, and a business that regrets a $40,000 system does not come back.
What custom actually means at this size
Not a multi-year enterprise implementation. For a business somewhere between half a million and ten million in revenue it means a web application built around your operations, your vocabulary and your edge cases, talking to what you already use over APIs, running in a browser. It should look like a simple internal tool, because that is what makes people use it.
Three we have built. For a construction company, a project tracker combining procurement requests, subcontractor timesheets, milestones and invoices, replacing four tools and a dozen spreadsheets. For a logistics operator, an invoice portal tracking shipments, generating invoices on contracted rates and pushing to accounting. For a confectionery studio, B2B ordering joined to production planning, so wholesale orders arrive online and the production team sees what to make that morning.
The costs nobody puts in the proposal
The build price is the part everybody quotes. These are the parts that decide whether you regret it.
Maintenance forever. Dependencies age, integrations change, browsers move. Budget something every year, not nothing.
The bus factor moves to you. With SaaS, the vendor employs the people who understand it. With custom, that knowledge is a document and a repository, and it decays.
Change requests are now a project. Adding a field in a SaaS tool is a click. In your system it is a ticket, a build and a deploy.
Compliance and security are yours. Whatever rules apply to your data, you now own the work of meeting them.
Hosting and infrastructure, small but permanent.
The honest comparison is not build price against SaaS subscriptions. It is build plus five years of the above against subscriptions plus the cost of the manual work you are doing today. Run it over five years and some projects that look obvious stop looking obvious.
What you must own when it is finished
Non-negotiable, and worth writing into the agreement before anyone starts.
The source code, in your repository, under your account
The infrastructure accounts, billed to you, not sitting inside an agency workspace
Your data, exportable in a format you can read without the application
Documentation good enough for a competent third party to take over
A written answer to what happens if the agency disappears
A builder who resists any of this is selling you a dependency rather than a system. The point of custom software is control; if you do not get control, you have bought the expensive option and kept the lock-in.
Cost and timeline
These sit at the top of the bands in our pricing article. One core workflow, built properly: $8,000-25,000. Three or four workflows: $20,000-60,000. Against six SaaS tools at $100-400 a month, which is $7,200-28,800 a year before counting the hours spent moving data between them.
Eight to sixteen weeks end to end: a fortnight documenting the process and designing, most of the middle building with regular check-ins, a few weeks testing and iterating, then deployment and training. Adoption tends to be fast for one reason: the people using it on day one are the people who specified it.
When not to build
Clearly and without hedging.
Your process is still changing. Encoding a process that will be different next quarter means paying twice.
Nobody can describe how the work is done today. Extract that first; it is a different and cheaper project.
The real problem is that two departments disagree about the process. Software will not settle that argument, it will just make it expensive.
You have not honestly tried the middle path.
Revenue is small enough that the money matters more than the hours. Below roughly half a million, live with the mess a while longer.
The test that settles it
Write out one core process step by step. Against each step, name the tool that handles it. Then count two things: gaps, where no tool fits and a person does it by hand, and handoffs, where data crosses from one tool to another.
More than five gaps or four handoffs in a single core process and the arithmetic for building usually works. Fewer, and you are looking at an integration problem wearing an ERP costume, which is the middle path and a tenth of the price.
Hitting the limits of your current tools? The audit at 2pizza.team/audit takes two minutes and no call. If the answer is that you need an integration rather than a system, it will say that.
Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.
Top comments (0)