How long custom software takes.

Treat a number quoted before anyone has seen your processes as a guess. A useful estimate names what is included, which systems are involved and what the team is assuming about your data and your decisions.

Three things set the length of almost every project. The first is breadth: how many separate jobs the software must do. The second is connection: how many other systems it must read from or write to. The third is pace: how fast questions get answered on your side.

A schedule is a sequence of milestones, each with a deliverable you can see, not a single date at the end. Every project is scoped and quoted after a discovery call. For how a build runs from start to finish, see custom software development.

1. Discovery call: you describe the problem, the people who use the process and the systems involved. Foxefy listens and asks questions.
2. Research: the team studies your current process, data and tools, so the plan rests on how work happens day to day.
3. Roadmap: the work is split into milestones, each with named deliverables, so you can see what arrives and in what order.
4. Agile build: the software is built in iterations, with regular check-ins where you see working screens and give feedback.
5. Testing: each part is tested thoroughly before it reaches your users, and again as the parts come together.
6. Launch and support: the system goes live, and Foxefy offers support and maintenance contracts for systems it has built.

The phases overlap more than a list suggests. Research continues into the build as questions surface, and testing runs alongside building, not only after it. What stays fixed is the order of decisions: scope before milestones, milestones before the build, and a tested release before launch.

Integrations and data are the two that surprise people most. The screens are the visible part of the software, but the work of reading and writing records in other systems is where unexpected cases appear. A short list of systems and a look at the data at the start of the project removes much of that risk.

• Phased rollout: start with one team, one process or one module, learn from daily use, then widen. Users see value sooner, and early problems stay small.
• Prioritized modules: rank the work by what hurts most today. The first release should fix that, and the rest can follow.
• Early data preparation: clean and export your records while the roadmap is being agreed, so migration does not hold up the build.
• Fast feedback: answer questions between check-ins, and let the people who will use the system see each iteration, not only the manager who ordered it.

The trade-off is scope, never quality. If you need an earlier launch, ask what can wait for a second release, and say so at the discovery call. A narrower first release that works is better than a broad one that arrives with gaps. For how the shape of the contract affects this, read fixed price vs time and materials.

1. Name one decision-maker, plus one person who will test the software with everyday tasks.
2. Write down the problems the software should solve, in plain sentences, and who feels each one.
3. List every system the software must connect to, with the person who can grant access to each.
4. Gather a sample of your data from each system, and note the known gaps and duplicates.
5. Note any legal, security or audit requirements, and who must sign off on them.
6. Rank your needs: what must work on day one, and what can wait for a later release.
7. Agree how quickly your team can answer questions during the build, and who covers when someone is away.

If writing these down feels like a lot, use the software project brief template, which puts your users, workflows, data, integrations and constraints into one document. Kickoff comes after the discovery call and the proposal, so the next step is to book a discovery call.