In short: Good custom software doesn’t start with an eighty-page specification. It starts with a day spent next to the people who will use it. Then comes a prototype you can try, followed by short releases, each one used and corrected by your team. Below are the stages, what you prepare at each one and what you should receive at the end, whoever you work with.
When custom software is worth it
If an off-the-shelf product covers your process with a few settings, choose the product: it costs less and you can use it tomorrow. Custom software starts to pay off when you see signs like these:
- your team works around the software, with parallel Excel sheets and approvals lost in e-mail threads;
- the way you work is your edge over competitors, and you don’t want to change it to fit a program;
- you run two or three programs that don’t talk to each other, and someone copies data between them every day;
- you have audit, traceability or signature requirements that generic products only half cover.
The full comparison, with the benefits and risks of each option, is in Custom software or off-the-shelf product?
Stage 1: analysis
Good analysis happens where the work is done, not only in a meeting room. The development team looks at the real process, with its shortcuts and exceptions, not just the one written in the procedure. It follows a document from the moment it arrives until it is archived and notes who touches it, what they check and where it waits.
What you prepare: the steps of today’s process, even on a single sheet, the documents and reports you use, the programs the application will have to talk to, and two or three people who know the daily work well. You don’t need a complete specification; it actually comes out of the analysis.
What you get: a description of the process, a list of what goes into the first version and what is left for later, and a written estimate of time and cost for the first version.
Stage 2: the prototype
Before the actual development you see the main screens and the path of a document through the application. This is where corrections are cheapest: a missing field, an approval in the wrong place, a report nobody would read. When the application starts from an existing platform, the prototype isn’t a drawing but a working application with test data.
Stage 3: development in iterations
The rest is built in short steps. Each one ends with a version your people try out and a list of corrections for the next step. That way you learn early whether the direction is right, not after months of work. Ask your supplier how they test: every change should go through automated tests and a code review by a second developer.
Stage 4: data and links to other software
Two things are almost always underestimated. The first is migrating data from old systems: item lists, customers, open documents. The second is the connection to the programs you keep, usually the invoicing software or the ERP. These links work through an API, directly with the database or through Excel/CSV files. Agree from the start which program is the “source of truth” for each type of data.
Stage 5: training and go-live
Go-live works better with a single department or site for a few weeks, then the rest. People learn on their own real data, with written guides and short videos, and the first days need someone from the supplier who can respond quickly.
After launch
Custom software doesn’t end at launch. Processes change, legislation changes, and the people using it come up with new ideas. What matters is a clear support contract: who answers, how fast, how changes are requested and how their cost is agreed.
What drives time and cost
No two processes are alike, which is why a serious estimate comes after the analysis, not before. Effort grows with:
- the number of roles and different approval workflows;
- integrations with programs that have no API;
- compliance requirements: audit, electronic signatures, validation;
- migrating data from old systems;
- mobile apps that must also work without a signal.
Effort goes down when the first version is limited to the main process, when the people who will use the application give feedback after every step, and when you start from components that already exist: forms, approvals, documents, roles.
What you should receive at the end
- the application installed where you agreed, in the cloud or on your own server, with role-based access;
- an audit log: who changed what and when;
- automatic backups, checked regularly by restoring them;
- a way to export your data;
- user guides and training for each role;
- a support and further-development contract with clear response times.
What starting from a platform changes
A large part of any business application repeats from one project to the next: users and roles, forms, approval workflows, documents generated from templates, an audit log, two-factor authentication, an API. If the supplier already has these, tested in production, your time and budget go into what is specific to your process. That is how we work too: custom software built on the DataFlows platform.
Frequently asked questions
How long does a custom software project take?
It depends on the process, but a first usable version should appear after a few iterations, not after months of specifications. The written estimate comes after the analysis.
How much does custom software cost?
There is no list price. Cost depends on the number of workflows and roles, on integrations, on compliance requirements and on how much of the application can be built from existing components. Ask for an estimate for the first version, not for everything you might ever want.
Do I need a specification before we start?
No. A description of today’s process and a list of the documents and programs you use are enough. The specification is written together, during the analysis.
What if we want changes after launch?
You request them through the support channel; they are estimated and delivered in the next versions. Changes are normal: they show the application is being used.
If you have a process that doesn’t fit an off-the-shelf product, get in touch. We’ll come and look at it and tell you honestly whether a custom application is worth it or an existing product is enough.
