Custom software project: stages from discovery to production

The system proposal arrived, it was approved, and now the operations manager has a question nobody answered in the meeting: what happens next? How much of his team's time will the project take, who needs to be in the conversations, when do field staff start using it and what happens to the spreadsheet that runs the operation today. People who have never hired software development usually find these answers halfway through, when changing course costs more.

This article describes the stages of a custom software project, from discovery to production, and what your company provides and decides at each one. At the end there is a roadmap to follow the project, which works with any vendor. If you are still deciding whether to build or buy, start with custom software vs. off-the-shelf.

What is a custom software project?

A custom software project is the work of turning a specific process in your company into a system that runs in production, with people using it every day. It starts by understanding the problem, goes through building in parts and continues after go-live, because the operation changes and the system follows.

The first stage goes by different names: requirements gathering, discovery, assessment. The UK government's digital service manual, one of the most detailed public references on the subject, calls it discovery and sums up the goal this way: before you commit to building a service, you need to understand the problem that needs to be solved. The same text says you should not start building in discovery, and that teams often arrive with a predefined solution ("we need an interactive map") when the job is to reframe it as a problem ("how do people find their nearest office?").

In our projects, discovery starts with a conversation with the people who decide and the people who operate, and ends with scope, priorities and a proposal. That is how we describe the process on the custom web systems page.

Why do so many software projects stall before production?

Most projects that stall skip understanding the problem or push the first real use too far out. When the scope is born from a list of screens, the system reproduces what someone imagined instead of what the operation does. When delivery happens all at the end, misunderstandings surface all at once, close to the deadline.

The principles behind the Agile Manifesto, written in 2001 by a group of software developers, address exactly these two points. One asks for working software delivered frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. Another says working software is the primary measure of progress. A third says business people and developers must work together daily throughout the project.

In operations-heavy companies there is a third reason, more concrete: the person who approves the project is rarely the person who uses the system. The director signs off, but the person opening the phone at the quay, at the gatehouse or inside a tank is someone else. If that person does not take part, the everyday exceptions (the night shift, the contractor who shows up without documents, the area with no signal) only appear once the system is already built.

What are the stages from discovery to production?

There are five stages: discovery, scope and proposal, first version, rollout and evolution. The table shows what happens at each one and what falls to the client company.

Two notes on the table. First, the column "what your company provides" is never empty. A vendor can write code alone, but it cannot learn alone how your operation works. Second, the evolution stage has no fixed end. The oldest system we maintain, the operations platform for a port support base, started with the safety processes and gained modules as the operation asked for them. Today its database has more than 160 tables, and every module uses the same register of people, companies and locations.

How do you follow the project stage by stage?

The simplest way is to check, at the end of each stage, whether what depended on your company was provided and decided. The roadmap below gathers those points in the order they come up.

Use the roadmap as the agenda for progress meetings. In discovery, the items most often forgotten are the exceptions and the neighbouring systems. Ask each area to describe the worst day of the month, because that is when the process shows the rules nobody wrote down. In the first version, the item that weighs most is the owner with time set aside. Without that person, each cycle ends without validation and adjustments pile up for the end.

The item about what stays out also deserves attention. A proposal that only lists what goes in leaves room for each side to imagine something different. When the exclusion is written down ("ERP integration moves to phase two"), the priority conversation happens at the start, calmly.

How do you put the first version into use?

The first version goes into use with one process and a small group of users, with the old way still available for an agreed period.

1. Pick the process that hurts most and has a clear owner. At the port support base, the platform started with safety processes such as the permit to work, before reaching maintenance and overtime.
2. Define the pilot group: one team, one shift or one site, with someone who likes testing and whose colleagues listen to them.
3. Migrate only the data the pilot needs. Registers of people, companies and locations usually come first, because the next modules will reuse them.
4. Set up access roles with someone who knows the jobs. Each role sees and changes only what it needs.
5. Train on the real process, with this week's cases, instead of sample data.
6. Follow the first weeks closely and adjust. Repeated user questions usually point to a screen that needs to change.
7. Agree the date when the paper or the spreadsheet stops counting, and keep it. Two open paths with no end date pull the team back to the old one.

In the field ERP for industrial tank cleaning, the whole flow revolves around a single reference number that follows the job from the request to the reports. That detail ended the confusion between internal codes and the number the client knows, and it is the kind of thing that only surfaces when the people who operate take part in the project.

What if the project depends on an integration, a legacy system or an area with no signal?

When the project depends on another system, the integration needs to be checked during discovery, before it goes into the proposal. The system on the other side often exposes less than expected, and that is where timelines tend to slip. On the port platform, dashboards read the warehouse management system (WMS) data straight from its SQL Server database, without replacing the WMS. In the command center for environmental emergency response, team working hours integrate with the client's field project management platform.

When there is already an old system, the first question is whether it still serves the operation. If it does, modernizing in parts is usually the safest path, with the operation using the system the whole time. If another company started the system, the project begins with an assessment of the code and the infrastructure. We cover this under support and modernization. In the offshore passenger transport case study, a system built for a single operator is being redesigned as a platform for several operators, without stopping the operation that already uses the first version.

When work happens on vessels, in isolated industrial areas or inside tanks, offline use belongs in the scope from the start. What has to work disconnected and how data syncs when the connection returns is a design decision made in discovery. The article on PWA vs. native app compares both paths for field teams.

What happens after the system goes live?

After go-live, the system moves into support: fixes, version updates, monitoring, backups and the adjustments the operation asks for. The UK manual covers this transition in the beta phase, which starts with a limited number of users and recommends keeping the legacy service running until the new one is ready to take over. The text also asks that the team has the capacity to keep learning and iterating during that period, and that support staff can cope with users who struggle in ways nobody foresaw.

Two points belong in the contract before the switch-over. The first is who answers for failures and through which channel. The second is your company's access to the code, the infrastructure and the data. It is also the moment to check personal data protection. Brazil's general data protection law, the LGPD, says in article 46 that security measures, technical and administrative, must protect personal data, and paragraph 2 says they must be observed from the design stage of the product or service through its execution. In practice, access roles, masking of data such as the CPF (the Brazilian individual taxpayer number) and logging of sensitive actions belong in the scope from the start.

Evolution follows the pace of the operation. In the emergency command center, stages and template tasks are configured by incident type, and the interface exists in Portuguese, English and Spanish because teams that speak different languages use the same system. Requirements like these often appear after the system is already in use, and the project needs room for them.

When is a custom project the wrong path?

A custom project is the wrong path when the process is not defined yet. If each team does it differently and nobody can say which way is right, the system will only record the confusion. In that case the first job is to design the process with the people who run it. The UK manual itself says it is not a failure to stop at the end of discovery when the research shows that is the best thing to do.

It is also the wrong path when the process is the same as in any other company, such as payroll or accounting. For those, an off-the-shelf product solves it with less cost and less risk. And it is worth waiting when the decision depends on something software does not change, such as a contract under renegotiation or a standard under review.

If your process lives today on paper, in spreadsheets or in message threads and you want to know what a project for it would look like, boosting.tech is a custom software company that builds and maintains systems around the operation you already have. The initial conversation is free: we set a day and time, understand the process and what needs to change, and then send a proposal with scope and timeline. Details are under custom web systems.