Is custom more expensive than buying?

Almost always over the system's life: you carry the whole development cost, then the whole maintenance cost, and the question of who fixes it in three years.

What should we own at the end of a custom project?

The source code, documentation good enough for a different developer to work from, and no dependency on one individual. If you cannot hire someone else to continue the work, you have not bought a system, you have rented a person.

When a Package Will Not Do It

Most requests for custom software should end with buying a package. Building is slower, costs more over its life, and leaves you maintaining a system nobody else uses. But where no package fits, buying is expensive too.

The three bad reasons to build

Almost every custom project that should not have happened started with one of these.

"Our process is unique." Usually it is not — it is unexamined. The test is whether you can explain why the difference makes money. If you cannot, the package is offering you a cheaper process, not a worse one.
"The package does 80% of what we need." That argues for buying it. The question is whether the missing 20% is the part that makes you money or the part you are attached to.
"Licences are expensive at our headcount." Sometimes true, but the alternative is build plus maintenance plus the risk of a single developer holding the whole system.

Want to know how this works out for your company? Send us the question as you would ask it.

Ask on WhatsApp

The one good reason

Build when the thing you manage is not the thing packages are built to manage: accounting, CRM, HR, inventory. When your core object fits none of those shapes, every package makes you distort it into their nearest equivalent, and the distortion is where the errors live.

Rental packages manage contracts. The money is made or lost on the vehicle — condition at handover, distance driven, service done on time, which fine belongs to which renter, what is still uncollected. Those facts belong to the vehicle across many contracts, and a contract-shaped system has nowhere to put them.

What the vehicle-first system holds

None of it is exotic; a contract-first package just does not store it.

Inspection recorded at both ends of every hire, so damage has a before and an after
Odometer tracked per vehicle, so maintenance is scheduled by distance rather than by calendar
Traffic fines matched to whichever contract was live when the fine was issued
Collections and outstanding balances tied to the contract that generated them
Allocation across garages and branches, so a vehicle always has a known location

Build the narrow thing, buy the rest

Adding accounting to a build feels almost free. It is not: you would be maintaining an accounting system, a problem already solved. Build only the part with no packaged equivalent, and connect it to bought software for accounting, payroll and email.

Questions to ask before commissioning anything

If a developer gets vague on the last one, that is the useful signal.

Which packages did you evaluate, and specifically what could they not do?
What is the smallest version of this that is useful, and what does it cost?
Who maintains it, and what happens if that person is unavailable?

Contact Us