Common Myths About Custom Software

None of these are made up. Each one started as something true and then hardened into a rule. Here is what is true in each, and where it stops being true.

1. “It’s too expensive.”

True enough: custom software costs more up front than a subscription does. There is no version of it that does not.

Where it breaks: expensive is a comparison, and the usual comparison is the wrong one. It is not the build against one monthly fee. It is the build against every subscription that touches the same process, plus the extra product bought to cover the gap between two of them, plus the hours your people spend doing the steps nothing covers.

We can give you our own numbers, not the industry’s. Discovery starts at $1,500, a fixed fee that is credited against the build if you go ahead. A build starts at $15,000, with the scope and the price signed before work begins. Support is optional, from $1,000 a month. Whether that is expensive depends on the column we cannot see, which is what your current setup costs you in fees and in time. Add that up first.

2. “It takes forever.”

True enough: software projects do run long, and anyone who gives you a date before they have looked at how your work runs is guessing.

Where it breaks: the timeline is set by how much you ask for in version one, not by the technology. A first version that covers one process, for the people who do that process, is far smaller than what most people picture when they hear the words custom software. Ask for everything at once and you get a long project. Ask for one process and you get a short one.

Ask for the smallest version that would be worth using on Monday morning. Put it in front of the people who do the work. Let what they run into decide what gets built next.

3. “Only big companies can afford it.”

True enough: a large company can absorb a project that does not work out. You cannot. Being careful about this is correct.

Where it breaks: what sets the cost is scope, not the size of the company paying for it. A big company builds a big system because it has a big process to cover.

The work usually looks like this: a wrap shop’s quotes and which vehicles are in the bay, a repair shop’s work orders, a forensic engineering firm’s case files. Each of those is one process, built once. None of them are company-wide systems.

What protects you from a failed project is not being large. It is a scope small enough to describe on one page, a price agreed before anyone starts, and owning what gets built.

4. “SaaS tools do the same thing.”

True enough: very often they do. When a product covers your job, buy the product. Building your own accounting or payroll would be a waste of money.

Where it breaks: the question is not whether a product exists. It is what you are doing around it. If the process needs a spreadsheet between two products, or one person who retypes the same information into a second screen, then the product is doing most of the job and you are doing the rest by hand, every day.

That daily remainder is the real comparison, and it has its own article in this series.

5. “I would be stuck with whoever builds it.”

True enough: this one is not a myth by default. It depends completely on what you sign. Software you cannot run without the people who wrote it is a real thing that happens.

Where it breaks: it is avoidable, and avoiding it takes a question rather than a leap of faith. Before you sign: who owns the code when the final invoice is paid? Whose account does it run in? Could another developer take it over? Ask for those answers in the contract.

Ours: you own all deliverables on final payment, and you get the repository and the documentation for deploying it. No lock-in.

6. “I need to know exactly what I want before I start.”

True enough: you do need to know the problem. A vague project produces vague software, and that costs money and patience.

Where it breaks: knowing the problem is not the same as knowing the answer. You are not expected to arrive with screens, a feature list or any opinion about the technology. You are expected to be able to describe how the work runs today, where it goes wrong, and what it costs you when it does.

Turning that into a specification is the job of whoever you hire, and it should happen before anyone writes the software. That is what a discovery step is for. Ours produces a working prototype, a written scope and a firm price for the build, so the build starts from a document instead of a conversation.

7. “It will be obsolete in a couple of years.”

True enough: software needs upkeep. Dependencies get security updates, browsers change, and your own business changes. Anyone telling you it is finished forever is wrong.

Where it breaks: needing maintenance is not the same as going obsolete. Rented software also changes underneath you, and you do not get to choose when. When you own the code, it changes when your business changes.

Budget for the upkeep instead of hoping to avoid it. Ours is optional and starts at $1,000 a month. The point is less the number than that it is a planned line rather than a surprise.

What all seven have in common

Every one of them turns into a question you can ask out loud. What does my current setup cost me, in fees and in hours? What is the smallest version worth using? Who owns the code? What happens if we stop working together? Anyone who cannot answer those plainly has told you something useful.