Custom software has a reputation for being an enterprise thing: six-figure budgets, year-long projects, a developer who leaves halfway. For a small business the picture in 2026 is different. The tools to build have got cheaper and faster, the cost of not building (five half-fitting subscriptions glued together with manual work) has stayed the same, and the mistakes are the same ones they always were. This is the test we use before recommending a build, and the costs when we do.
The test: three questions
- Are you paying for several tools that each half-fit, and gluing them with people? If someone spends hours a week moving data between subscriptions, that labour is the budget for a build that removes it.
- Is the process yours, or everyone's? Invoicing is everyone's; buy it. The way your practice reviews client meetings, or your funeral home takes a family's keepsake order, is yours; nobody sells that, and the generic tool will always fight it.
- Will it still be the process in two years? Build for stable processes. Automate (more cheaply, more reversibly) the ones still changing.
Three yeses: build. One or two: automate around the tools you have. None: buy the subscription and move on.
What it costs, by tier
- An internal tool or dashboard that joins your existing systems into one screen: typically £5,000 to £15,000. The data already exists; the work is the connections and the interface.
- A client-facing portal or workflow app (a client submits, your team reviews, the system chases and tracks): £15,000 to £40,000 depending on roles, payments and integrations. The memorial-products platform we built for a funeral-products company, with a white-labelled portal per funeral home and a no-login page for families, sits in this tier and runs inside a consulting retainer.
- A native mobile app for the public: £40,000 and up, and this is the tier where budgets go wrong. A youth-sports app we project-managed came in around $45,000 after scope creep, which is the lesson in the next section.
- A product you intend to sell (SaaS): a different conversation about market, pricing and ownership, not a quote.
We also build smaller things that do not fit a tier: an AI email responder for enquiries was £3,000; meeting-intelligence software for an accountancy firm was £7,500. Scope decides the price, which is why we scope before we quote.
How scope creep actually happens
Not in one big change. In twenty small ones, each reasonable: "while you're in there, could it also…". Each adds a day. Nobody re-prices because each one is small. The project lands at 150% of the quote and everyone is unhappy. The fix is a rule, agreed before the first line of code: a change request is written down, priced, and either accepted at the new price or parked for phase two. It feels bureaucratic for a week and then it saves the relationship.
The other rules we build by
- Map the workflow first. You cannot build software for a process nobody has written down. The map is the spec.
- You own it. The code, the documentation, the data. No lock-in to us or to a platform. A build you cannot leave with is a subscription with a bigger deposit.
- Buy the commodity parts. Authentication, payments, email, file storage. Build only the part that is yours.
- Ship in phases. A working slice in weeks, used by real people, before the rest is built. Every big-bang build we have seen go wrong skipped this.
- Plan for the developer leaving. Documentation and a second pair of eyes from day one, because it happens on a third of projects.
When to say no
Two real builds, and what decided them
Permelo formats recruitment CVs into a client's house style in about twenty seconds and builds shortlists. Recruiters were spending hours a week reformatting by hand, and no tool on the market did the specific job. All three test questions were yeses: labour glued around half-fitting tools, a process that was the business's own, and stable for years. It was built, and it became a product.
The Family First Impression scan for a funeral-home coaching business takes a funeral home's name and returns a score out of 100 for how findable, trusted and easy to call it is, in under a minute, as a lead magnet at conventions. No tool did it; the rubric was the client's own; the process will not change. Built, with the deterministic scoring the client could stand behind. In both cases the alternative was a person doing it slowly, forever.
And one we talked out of: a founder who wanted a custom CRM because the off-the-shelf one "didn't quite fit". The fit problem was two missing fields and a report. Automated around in a week for a fraction of a build. The test said no, and the test was right.
The brief: what to write before you ask for a quote
- The process, as it happens today, step by step, including the workarounds. Not the ideal version.
- Who touches it: roles, how many people, inside and outside the business.
- The systems it must read from and write to, by name.
- What "done" means: the hours saved, the error removed, the thing clients will notice.
- What is out of scope, explicitly. This is the line that stops scope creep later.
- The budget range. A builder who knows the range designs to it; one who does not guesses high.
A page is enough. A builder who cannot quote from that page is going to discover the scope on your invoice.
If the process is still changing monthly, no. If an off-the-shelf tool does 90% and the 10% is tolerable, no. If the reason is "it would be nice to have our own", no. Building is for when the manual work around the tools is costing more than the build, and the process is yours and stable. The custom software page sets out how we scope, and the AI consultancy page covers the audit that decides build-or-automate before any money is spent.
Founder, Anco AI. Builds the systems this site talks about, and runs his own business on them.
