How much does custom software cost? What drives the price

What drives the price

The price is the time spent building the system. Anything that makes the build longer raises the price, and it can be counted before we start.

• Number of screens and roles. Every screen is work: list, card, form, filters. Every role is a different set of permissions and a different view. A system with three roles and ten screens costs a different amount than one with eight roles and forty.
• Connections to other programs. Accounting, couriers, payments, shop, supplier systems. Connecting to a program that has a ready-made way in for other programs costs many times less than building a workaround for one that does not.
• Data migration. Customers, products, jobs from spreadsheets or from an old program. The more years and files, the more tidying. How that goes is in the guide on moving data out of spreadsheets.
• Legal requirements. Personal data, accounting documents, contracts, regulated industries. More rules about who may see what, and more checking.
• Work in the field. A tablet on the shop floor, in a van, at a customer’s site, sometimes without signal. The screen has to behave differently from an office one and send its data once the connection is back.
• AI in the process. Reading documents, sorting requests, answering customer questions. Sometimes it pays off handsomely, sometimes plain automation is enough. Where the line runs is in the guide on AI in your company.

What brings the price down

Start with one module. A module is a self-contained part of the system, say job intake. The first module replaces what hurts most, and you add the next ones once the team is already working in the system and knows what is missing. Companies that order everything at once pay for features they never use.

Do not move everything. Current data and what you go back to, yes. Jobs from five years ago stay in the spreadsheet as an archive. Every column that goes into the system needs a screen.

Use ready-made where ready-made is good. Payments, courier labels and the accounting program you already have are things the custom system connects to rather than replaces. Which parts to leave ready-made is on the page custom or off the shelf.

Come with a description of the process, not a specification. A specification written without a developer usually lists features rather than the process, and some of them turn out to be unnecessary. What is worth having before the call is on the page how to prepare for a quote.

How billing works

You pay for a module after accepting it, usually at month end. You do not pay up front for the whole system. The first invoice arrives when the first module is running at your company. If you change your mind along the way or the money runs out, you keep the working part you paid for, and nothing more.

A change of scope during the build gets its own quote and date in writing before I start on it.

What a written quote contains

After the first call you get a document with:

• the process written down step by step, as you told it, with my questions wherever something is unclear;
• the system split into modules, with what each does and for whom;
• the order of the modules, starting from what hurts most;
• a date and a price separately for each module;
• a list of programs to connect and data to move;
• what you get at the end: code, documentation, credentials, server.

You can take that document to another vendor. If their offer is noticeably lower, ask what it leaves out.

Costs after launch

Three items. A server with a provider we choose together, paid monthly to that provider. Upkeep: backups, updates, keeping an eye on the system so it stays up. Changes when the process changes, quoted separately.

We agree the level of support after launch. One company needs changes once a quarter, another wants a standing agreement. I have looked after the kayak rental system this way for three seasons.

How to compare vendors’ offers

An offer with no written process and no split into parts is guesswork with your money. Check whether the offer includes:

• The process written down. If the vendor has not described how you work, they have priced something they do not know.
• Stages with separate prices. One price for the whole means you are paying up front for the vendor’s risk.
• Who owns the code. It must say the rights pass to you stage by stage. Without that, changing vendors means building from scratch.
• What happens after launch. Server, upkeep, changes, and what they cost.
• Who exactly will do the work. Names, not “our team”. If the vendor brings in people for specific tasks, it must be clear who answers for the whole.

What you get with a custom system and when it pays off at all is on the main page of the guide. If you want a scope and prices for your company, describe in the form below what the system should do. I will get back to you with questions or a suggestion which module to start with.