How long does it take to build custom software?

"How long will it take to develop our tool?" It is a fair question. The honest answer is: it depends. A small internal tool and a platform connected to several systems are not comparable at all. Rather than a general figure, here are the stages of a project and the factors that lengthen or shorten it.

The stages of a custom software project

A well-run project generally follows these phases. They sometimes overlap, especially with an iterative approach.

1. Scoping. We define the problem to be solved, the users, the essential features and those that can wait. We identify the existing tools to connect and the data concerned. This is the most cost-effective stage: every ambiguity cleared up here avoids back-and-forth later.
2. Design. User journeys, screen mock-ups, data structure, technical choices, security and hosting rules. Mock-ups make it possible to validate usability before writing any code.
3. Iterative development. The software is built in functional blocks. At the end of each iteration, a usable version is presented and discussed. You see the product progress and can change course.
4. Testing and acceptance. Technical tests, then tests by real users in conditions close to reality. Fixes are made before go-live.
5. Go-live. Deployment to production, migration of existing data where needed, user training, documentation.
6. Follow-up and evolution. Fixes, adjustments after initial feedback, security updates, new features.

Factors that affect the duration

Several elements weigh heavily on the schedule:

• Scope. The number of features, screens and user types is the first factor. Each feature added requires design, development and testing.
• Clarity of requirements. Written, approved business rules speed everything up. Requirements that change along the way lengthen the project.
• Integrations. Connecting to existing software, an e-mail system, a calendar or an accounting tool takes time, especially if the documentation for these tools is incomplete. See data integration.
• Data migration. Importing years of history from Excel files or an old system often requires cleaning up first.
• Security and compliance requirements. Health data, financial data or sensitive documents involve additional measures, in connection with the nFADP (new Swiss Federal Act on Data Protection).
• The platform. A web app on its own is quicker than a web app accompanied by iOS and Android mobile apps, which also add app store review times.
• Availability on the client side. A contact person who responds quickly and can make decisions saves a considerable amount of time.

How to move faster without sacrificing quality

A few good practices:

• Start with a useful first version, limited to the essential features. It allows the tool to be tested in real conditions and steers what follows on concrete feedback rather than assumptions.
• Appoint a point of contact who knows the business and can approve choices.
• Prepare the data and access to the tools to be connected from the start.
• Accept postponing "nice-to-have" features to a later phase.
• Test early with real users, even on an incomplete version.

Be wary of very short timelines announced without scoping: they often result in delays or rushed features.

How we work

At LYL Software, we start with a scoping conversation to understand your business and your tools. We then give you a breakdown into stages, with an estimated duration for each phase and the assumptions it is based on. Development proceeds in short iterations, with regular demonstrations. At any moment, you know what has been done, what remains to be done and what could shift the schedule. To find out more, see our custom software page, our method and our article website or web app.