You are expecting this article to end in a pitch. It will not. Anito builds custom software for a living, and this page exists to name the four situations where you should not buy it from us, because a buyer who knows where custom pays is the only buyer worth quoting.
There is also a number behind this: the industry itself split. CIO.com’s June 2026 analysis reports the two-decade habit of “buy software by default” eroding as AI tooling cuts build costs, with the advice landing on a split: buy for commodity workflows, build for the ones that differentiate you. The risk, they write, has shifted “from can we build it to can we govern what we build.” Gartner separately forecasts the low-code market (tools that build software with visual assembly instead of code) reaching $58.2 billion by 2029. The tools are not the enemy. Paying custom prices for a commodity job is the enemy, and it cuts both directions.
The four cases where the cheaper tool wins
- A standard online store. Products, cart, checkout, standard shipping. Established store platforms do this better and cheaper than a custom build, with payments, taxes, and security already handled. Custom earns back its price only when the selling rules themselves are yours (configurable industrial products, quote-based ordering, price lists that fight the platform’s model).
- A brochure site whose job is to exist and be found. A good template on fast hosting, real text, real photos, and basic performance care gets you there for a fraction. You upgrade to custom when the site has to do work: intake, quoting, accounts, scheduling.
- Commodity back office. Payroll, bookkeeping, email, standard documents. Buy. Nobody’s differentiation lives in payroll, and the compliance surface changes constantly. CIO.com’s split says exactly this: commodity workflows stay bought.
- An internal tool for five people. Low-code tools are built for this and priced for this. Gartner’s forecast exists because that demand is real. The upgrade trigger is scale or surface: the tool starts touching customers, or the workaround list grows longer than the tool.
If a tool does your job verbatim, buy the tool. Anything else is paying custom prices to own a worse copy of something that already exists.
Where custom earns its price
The dividing line is not complexity. It is ownership of the workflow. When the way you intake, quote, dispatch, follow up, or manufacture is itself the competitive advantage, the off-the-shelf model becomes the ceiling: you bend your operation to match the tool, and the difference between you and your competitor (who bought the same tool) rounds to zero.
That is the honest answer to “why custom”: not newer, not shinier. The software should match the workflow that makes you money, and the workflow should never be edited to fit a package.
How we say this in practice
Our own portfolio carries the labels. Milyon Digital is a live client website we designed and built custom (Next.js with a decoupled CMS), and you can open it today: the site does work a template could not, which is what made custom the right call. Our other projects are labeled demonstrations, not clients. And the honest-no page on our site lists the situations where we tell a visitor not to hire us, this article’s argument in first person.
The check, whichever way you lean
- Write the workflow on one page. If a tool you can name does 80% of it verbatim, the tool wins; budget the remaining 20% as accepted manual work before you call a developer.
- Price both directions for three years. The template’s monthly fee compounds; the custom build’s cost is front-loaded. Run your real numbers, not a rule of thumb from either side.
- Whichever you buy, ask for the exclusions list in writing. A price with no exclusions is an opening position, and this is true for a $40-a-month tool and a $40,000 build alike.
If you wrote the one-page workflow and it did not match any tool verbatim, you are the buyer custom is for. Read our build versus buy guide for the full decision framework, look at what we build, and when you want the range and assumptions in writing, discuss your project. The reply will tell you what it depends on, and it will say so when the answer is a template.
Common questions
You are an agency publishing “do not hire an agency”. Why?
Because a builder who cannot name when their product is wrong cannot be trusted on when it is right. The honest-no is the strongest page we keep: it costs us quotes, which is exactly why competitors who need those quotes cannot copy it. If your job fits a template, this page just saved you money, and that is the reputation we would rather build on.
Can we start on a template and move to custom later?
Often yes, and the migration cost depends on decisions made early, mostly about data: keep your customer, order, and product data clean and exportable from day one. What does not transfer well is workflow logic embedded in a no-code tool; document your business rules outside the tool so the next system inherits the rules, not just the records. Ask any builder (tool or custom) what the exit looks like before you buy, and the answer will tell you how the exit was priced.
Is low-code the same as a template?
Close enough for a buying decision, with one distinction: a template is a finished product you configure (a store theme, a site design); a low-code tool is a visual assembly kit for building small applications without code. Both win on standard needs and both hit the same ceiling: the moment your workflow stops matching what the assembly kit models. Gartner’s $58.2 billion forecast for 2029 says the kit market is real; the ceiling is equally real.
How much does custom software cost, honestly?
It depends on scope, which is why we publish how the number gets made instead of a single figure: scope first, price second, milestones rather than lump sums, and a written exclusions list with every quote. Ask any developer for the assumptions behind their range. A range with stated assumptions is checkable; a single number with none is a negotiation opening.