When we will tell you not to build custom
A shop that always says yes is selling hours, not counsel. Here is when we tell SMEs not to build custom, what we offer instead, and what good clients do with a no.
Vinerals TechnologiesWorkshop notes
Custom software is what we do. Saying no to it is part of the job.
That sounds like bad business until you have watched a company spend six figures on software that solved the wrong problem, or rebuilt something that already existed as a subscription, or launched a system nobody inside the company would own after the agency left.
A shop that always says yes is selling hours, not counsel. This piece is about when we decline custom work, what we say instead, and what buyers who want an honest partner should expect from a good no.
When SaaS or a process fix should win
The most common reason we say no is simple: the job is already well served by software you can rent, and custom would be ego, not advantage.
Commodity back-office work.
Payroll, basic accounting, standard CRM, email marketing. Mature products exist. Buy them and spend your craft budget where you are different.
A good vertical fit you have not tried hard enough.
Sometimes the right answer is two more weeks evaluating existing tools, not six months building.
The pain is process, not software.
Four approvals for a two-minute task will hurt in any system. Fix the steps first, then see what tool fits.
The team is tiny and the need is generic.
Below a certain scale, subscriptions win on total cost and speed. Custom earns its keep when the workflow is specific and stable.
You need speed this quarter more than fit next year.
Renting a close-enough tool while you learn is valid. Custom is a commitment.
We have sent people back to off-the-shelf products with a short list of configuration choices and saved them a year. That is a successful meeting.
Projects that are really org problems
Software gets requested when the real issue is ownership, incentives, or departments that do not agree on what “the process” is.
No internal owner.
If nobody with authority will accept deliveries, prioritize fixes, or answer questions from users, the build will drift the moment we step back.
Competing definitions of success.
Operations wants speed. Finance wants control. Sales wants flexibility. Until leadership aligns on one primary job, software becomes a battlefield.
Change resistance treated as a UI problem.
If the floor will not use the current tool because they were never consulted, a prettier custom app repeats the same story.
Data nobody will maintain.
Custom systems need someone who cares about master data. Without that, you get a expensive empty database.
Politics dressed as requirements.
When every stakeholder adds a veto and nobody ranks priorities, the project is not ready for a build quote.
In these cases we might suggest facilitated process work, a smaller pilot, or fixing ownership before code. Building through organizational fog is how budgets die.
Budget, timeline, and ownership mismatches
Sometimes the idea is sound and the company is not in a position to carry it honestly yet.
Budget below the real job.
We would rather say so than deliver a cut scope that fails in production and poisons the well for later.
Timeline that only works if nothing goes wrong.
Fixed dates without room for discovery, integration surprises, or user testing are a prototype timeline, not an MVP timeline.
No plan for run costs.
If you cannot fund hosting, maintenance, and a human owner after launch, custom is not sustainable yet even if the build is financed.
Ownership expectations that do not match the contract.
If you need full code ownership, your repo, and clean handover but the budget assumes a hosted white-label product, we should stop before both sides are unhappy.
AI scope with data readiness nowhere in sight.
We will not sell a model project when the pre-flight checklist fails and nobody wants to fund the boring fixes first.
Mismatch is not moral judgment. It is fit. A no now can be a yes in twelve months when the budget, owner, and data catch up.
How we say no
A useful no is specific, early, and leaves you with a path. Not a vague “we are not a good fit” email.
We name the reason plainly.
SaaS fit, org readiness, budget, data, timeline. No corporate fog.
We say it before you pay for discovery.
First conversations are free for a reason. The no should land there when it is obvious.
We point to alternatives.
Products worth trying, process steps, a smaller engagement, another shop better suited to the stack you named.
We offer a narrower yes when it exists.
Sometimes the answer is not “no custom” but “not that custom.” A brief audit, a prototype, a integration fix, a data cleanup sprint.
We stay willing to revisit.
Circumstances change. A no today is not a blacklist. It is a snapshot.
You should leave the conversation understanding what would need to change for custom to make sense. If you do not, ask. Clarity is the product.
What good clients do after a no
The best responses we see are not arguments. They are curiosity.
They test the alternative.
Actually run the SaaS trial, tighten the process, assign an owner. See if the no was right.
They fix the named blocker.
Data cleanup, executive alignment, budget for run costs. Then they come back with evidence.
They narrow the ask.
One workflow, one integration, one quarter. Smaller honest scope often turns a no into a yes.
They keep counsel separate from ego.
Being told not to build is not being told you are wrong. It is being told where the money works harder.
They ask who else to talk to.
Sometimes the right answer is a different kind of partner. We are glad to say so when it is true.
Clients who treat a no as information tend to spend less overall, whether they build with us later or not.
Signs you want a shop that will refuse work
If you are buying custom software, you should want a partner who will push back. A few signals that you are talking to one.
They ask about SaaS before they ask about stack.
Curiosity about what you tried is a good sign.
They name risks in the first meeting.
Integrations, adoption, data, maintenance. Not only upside.
They tie quotes to scope you can verify.
Acceptance criteria, non-goals, handover. Not mood boards.
They have sent you away before.
Ask for an example. Shops with no stories are shops that never say no.
They are willing to lose the deal to keep trust.
That is the whole point.
Craft includes knowing what not to make. Custom software should earn its place in your business: where the workflow is yours, where rented tools bend you the wrong way, where ownership and five-year cost favour a build. Everywhere else, the honest answer is simpler and cheaper.
We are a Montréal solidarity cooperative that builds software by hand for SMEs. If you want counsel that includes a no when a no is right, we are glad to start with the job you have in mind and tell you what we would actually do. Book a consultation. No fee for the first conversation. Honest counsel, no obligation.
