Developing management software: how a custom project really works
The five phases of a management software development project told from the perspective of the client: what happens in each phase, what determines the timeline, what your company needs to do while work progresses, and the seven questions to ask the vendor before signing.
A custom management software is not delivered finished: it is delivered one module at a time
The five phases of a management software development project told from the perspective of those who commission it: what happens, what is asked of your company, and how to spot early on if things are going wrong.
What really happens when you develop a custom management system?
Developing a custom management software is not a job that gets delivered finished at the end of the work. It is a phased journey in which the first process goes live while the others are still on paper: you start from the point that hurts the most, put it to work for real, and only then extend it to the rest.
This changes the way the project needs to be evaluated. You don't just have to compare quotes and then wait: you need to understand what happens at each phase, what is required of your company as the work progresses, and what the signs are that something is going wrong, while fixing it still costs little.
This guide describes a management software project from the perspective of the one who commissions it, not the one who writes the code. If you are one step back — if you are still evaluating whether you need custom software instead of an off-the-shelf one — the answer is on the page about custom management software. If you are two steps back and still need to figure out which process to start from, begin with the guide to business process digitalisation.
In summary
- A management project has five phases: analysis of the actual process, navigable prototype, first module in production, extension to other processes, handover.
- Duration does not depend on the number of features, but on how many exceptions the process has, how many systems need to be integrated, and what state the historical data archive is in.
- The work is not all on the supplier: an internal point of contact who can make decisions is needed, otherwise the project stalls on questions, not on code.
- The first module goes into production early, on a real process with real data: it is the only test that counts.
- Before signing, ask how the cost is calculated, who owns the code at delivery, and what happens if you change supplier one day.
What are the phases of a management software development project?
Five phases, always the same, in any sector. What changes from project to project is how long each one lasts, not what they are.
Analysis of the real process
How you actually work, not how it's supposed to work on paper
We interview the people who carry out the process every day, we collect the spreadsheets, forms and email chains that hold it together today. Above all, we map the exceptions: the cases that «rarely happen» and that are exactly the reason why no standard software is ever enough.
This is the phase that determines the cost of all the others. A rushed analysis doesn't show up straight away: it shows up at the third module, when adding a feature means rebuilding the foundations.
Navigable prototype
See the screens before paying for their development
The main screens become a clickable prototype, still with no logic behind them. It serves one purpose only: to get the people who will use the management system to say «no, there's a step missing here» while fixing it costs an hour instead of a week.
If a supplier skips this phase and goes straight to development, ask why. The answer tells you a lot about how they work.
First module in production
The most critical process, on real work
A single process is developed and put into use: the one that currently costs you the most time or causes the most mistakes. It goes into production with real data and real people, while everything else continues to work exactly as before.
This is not a trial version: it is the management system entering the company through a narrow door. From here on, every decision is made based on observed behaviour, not on assumptions gathered in a meeting.
Extension to other processes
One module at a time, never everything at once
The other processes are introduced one at a time, each following the same cycle: analysis, prototype, production. Historical data is migrated when the module that uses it is needed, not all at once at the beginning.
This is why a phased project does not halt operations: at any given moment, part of the work runs on the new system and part runs as before, and neither is ever suspended waiting for the other.
Handover
The code, the documentation and the house keys
At delivery you receive the repository with the complete history of changes, the technical documentation, the deploy and backup procedures, and training for those who will use the system. The intellectual property is yours: you can continue with us, with another supplier or with an internal team.
This is not a bureaucratic end-of-project formality. It is the difference between having a tailor-made management system and being the user of software that belongs to someone else.
How long does development take, and what does it really depend on?
No serious vendor can give you a timeline before the analysis, and anyone who does is just guessing. What can be said in advance is what it depends on, so you can get an idea of your own case as you read.
- How many exceptions the process has. A linear flow with three states is developed quickly. A flow with twelve edge cases, each with its own rule, is a whole different project — and exceptions only emerge by talking to the people who execute the process, never by reading the procedures.
- How many people need to be heard. A process that stays within a single department can be mapped in a few meetings. One that crosses sales, production, and administration requires reconciling three different versions of the same truth, and that work is project time.
- How many systems need to be integrated. An e-commerce platform, an accounting software, a legacy system still in use: every integration depends on how willing that system is to be queried from the outside. Some have documented interfaces, others don't, and between the two cases there is an enormous gap.
- What condition the historical data is in. Duplicate records, fields reused over time for different purposes, dates in three formats: data cleansing is the most systematically underestimated part of the project, and the software cannot do it alone.
- How available the internal point of contact is. This is the factor that weighs the most and the only one that depends entirely on you. A point of contact who responds the same day and one who responds every two weeks produce two projects of very different lengths, with the same amount of code to write.
The same principle applies to cost: it is calculated on the estimated hours at the end of the analysis, with a rate stated before starting. You can find ours and the way we build the quote on the custom management software page.
What should your company do while the management system is being developed?
It is the part that is almost never mentioned during the sales phase, and it is what separates successful projects from the rest. Developing a custom management software requires effort from the client's side too: not much, but at specific moments and by specific people.
-
Appoint a contact person who can make decisions
They don't need to be a technical figure: they need to know the process and have the authority to determine how a borderline case is handled. A contact person who has to ask for permission for every answer turns every question into two weeks of waiting.
-
Surface exceptions, don't hide them
"We usually do it this way, but when X happens then…": that "but" is the project. An exception described during analysis becomes a feature; the same exception discovered during testing becomes a rework.
-
Decide what to do with historical data
What to migrate, what to archive, and how to handle duplicates is a business decision, not a technical one. No one from outside can know whether two nearly identical records belong to the same customer or two different customers.
-
Test with real work
Testing carried out by the people who will actually use the system, on the cases from the current week, finds in two days what a formal test never finds. It must be factored in as working time for the people involved, because that is exactly what it is.
What to ask the developer of your management software before signing
Seven questions to ask in an interview, before there is a contract. No technical skills are needed to ask them: they serve to understand how the person in front of you works and what happens when something doesn't go according to plan.
Both approaches are legitimate, but they differ in who bears the risk. A fixed price gives you a certain number and shifts the risk to the supplier, who covers it with a safety margin built into the price. Time and materials billing means you pay for the actual work done, but requires that you can monitor progress.
What must not happen is a fixed price that then generates a change request at every variation. Explicitly ask how changes during the project are handled: the answer matters more than the figure.
The answer must be «you», put in writing, with delivery of the complete repository including the full change history. If the answer is «we'll give it to you if you ask» or «it's ours but you can use it freely», you are buying a usage licence, not a bespoke management system.
The difference only becomes apparent the day you want to change supplier, and that is too late to find out.
This is the question almost no one asks, yet it should be the first. A well-built project can be handed over to another team: readable code, standard and documented dependencies, a written deployment procedure, no piece running only on one person's machine.
Ask to see the technical documentation of an already-delivered project, even with names redacted. A supplier who has none to show does not produce any.
Ask whether you will be speaking with the people who write the code or with a commercial intermediary who relays information. This is not a matter of personal preference: every extra step between the person who understands the process and the person who implements it is a point where information is lost, and exceptions are exactly the type of information that gets lost first.
The right answer is not a list of names: it is a justification tied to your specific case and to the likelihood of finding someone who can work with those technologies in five years' time. A niche technology chosen out of personal taste is a risk you pay for, not the person who chose it.
If you do not understand the answer, ask for it to be rephrased without technical jargon. Someone who truly knows a choice can explain it in plain language.
A management system in use changes: regulations, processes and the systems it interacts with all evolve. Ask how bug fixes are distinguished from new features, what the response times are, and whether you are tied to a maintenance contract in order to keep using the software.
The answer to that last question must be no. A fee for support is normal; a fee to avoid losing access to your own software is not.
Infrastructure, backups, recovery, and the list of who holds the credentials. These are questions that seem trivial until you have to answer to a client, an auditor or a regulatory authority.
Ask for the backup and recovery procedure to be documented and, above all, that someone has actually tested it at least once: a backup that has never been restored is an assumption, not a guarantee.
At what points does a management project get stuck?
Almost never due to technical difficulties. Management projects almost always stall at the same three points, and all three can be recognized in advance.
The big bang
Everything is replaced all at once, with a go-live date. That day, the cases that no one had reported come to light, and the company finds itself without the old system and with a new one that does not yet handle them. This is why the first module must go into production on its own.
The stakeholder who can't decide
The project stalls on questions, not on code. Pending answers pile up, development continues on reasonable assumptions, and at the first review everything has to be undone. This costs more than any technical difficulty encountered along the way.
Historical data examined at the end
As long as the management system is empty, everything works. When years of misaligned records come in, duplicates emerge, fields reused for different purposes and histories that don't add up. Looking at the real data during the analysis, and not after, is what prevents the surprise.
Frequently asked questions about management software development
The duration is estimated at the end of the analysis, not before, because it depends on how many exceptions the process has, how many systems need to be integrated, and the state of the historical data. What can be established from the outset is the method: the first process goes into production well before the end of the project, so the benefits begin while the rest is still in development. Be wary of a timeline declared before anyone has looked at how you work.
Yes, and it's the approach we recommend. You choose the process that currently costs the most — in lost time or errors — bring it into production, and validate it on real work. Decisions about subsequent modules are then made based on observed behaviour rather than assumptions, and the investment is spread over time instead of being concentrated all at the beginning.
Based on the hours estimated during the analysis, at an hourly rate declared before work begins. There is no price list for 'a management system', because two projects that share the same name can require very different amounts of work. You can find our rate and the way we build the quote on the custom management system page.
In most projects, that is exactly what is needed: the management system does not replace accounting or e-commerce, it connects them. How straightforward this is depends on what those systems allow to be read and written from the outside, and it is one of the first things to verify during the analysis — before making commitments on features that depend on that integration.
No. A web-based management system is used through the browser and the infrastructure can remain managed by whoever develops it. Having someone in the company who knows the system helps a great deal, but it is a matter of future autonomy, not a prerequisite for getting started.
You do. You receive the complete repository with the history of changes, the technical documentation, and full intellectual property. You can continue development with us, hand it over to another supplier, or bring it to an internal team, without asking anyone's permission and without licence fees.
Do you have a process that no software covers?
Let's start with a technical consultation: we look together at how you work today and tell you whether a custom management system makes sense in your case — even when the answer is no.
