What Should You Prepare Before Estimating a Custom Software Project?

One of the first questions in any software project is what it will cost and how long it will take. It is a reasonable question, and organizations need an answer to plan budgets and priorities. The difficulty is that an estimate is only as reliable as the understanding behind it. When the problem is loosely defined, an early figure tends to be either padded to cover unknowns or optimistic in ways that surface later as change requests, delays or a system that does not quite fit.

A feature list is a common starting point, but it is rarely enough on its own. Two projects with the same features can differ greatly in effort depending on who uses the software, how the work actually flows, which systems it must connect to and what constraints apply. This article sets out what is worth preparing before asking for an estimate, so the conversation starts from the right information. It does not discuss prices or durations, which depend entirely on the specifics of each project.

Start with the business problem

Before describing a solution, describe what needs to change. Useful questions include:

What is not working today, and how does it show up: delays, errors, duplicated effort, missing visibility?
Who is affected, and what does it cost them in time or quality?
Why is this worth addressing now?
What has already been tried, and why did it not solve the problem?

A clear problem statement does two things for an estimate. It allows the people estimating to suggest simpler or different approaches where they exist, including configuring an existing product instead of building one. And it gives the project a reference point for deciding what is essential when scope has to be balanced against budget or time.

Identify the users

Software effort is shaped heavily by who uses it and how. Prepare a short description of:

User types: for example staff, managers, customers, partners or field teams.
Roles and permissions: what each type of user needs to see and do, and what they must not.
Frequency and context of use: whether people use the software all day at a desk, occasionally on a phone, or in places with poor connectivity.
Approximate numbers: a rough sense of how many users of each type there will be, and whether that is expected to grow.

Roles and permissions are often underestimated. Each distinct role can add screens, rules and testing, so knowing them early makes an estimate considerably more realistic.

Map the workflows

Describe how the work happens today and how it should happen once the software exists. A simple map is enough: the steps, who performs each one, what information passes between them and where decisions or approvals occur.

Pay particular attention to exceptions. Normal cases are usually straightforward to describe; much of the effort in software sits in what happens when a request is incomplete, an approval is rejected, a record needs correcting or a step has to be undone. If the current process relies on someone simply knowing how to handle these cases, that knowledge needs to be captured before it can be built.

The difference between the current and the desired workflow is, in practice, the scope of the project. Making it explicit is one of the most useful things an organization can prepare.

Identify integrations

Most business software exchanges information with other systems. List the systems the new software must connect to and what should flow between them. Common examples include:

an ERP or accounting system for orders, invoices or inventory;
a CRM for customer and sales information;
identity systems for sign-in and access control;
existing databases or internal applications;
third-party services such as payment, messaging or mapping providers.

For each connection, it helps to know whether the other system offers an API or other integration options, who administers it, whether data must flow one way or both ways, and how quickly. Integration requirements frequently shape the architecture more than the new software’s own features, and an integration discovered late is a common source of estimate changes. Where the work involves connecting several core platforms, it overlaps with enterprise systems work and should be scoped with that in mind.

Understand the data

Software creates, uses and moves data, and the state of that data affects effort directly. Prepare what you can about:

Sources: where the information the software needs lives today, including spreadsheets and email.
Ownership: which system or team is the authority for each kind of record.
Quality: whether existing data is complete, consistent and current, or will need cleaning.
Migration: whether existing records must move into the new system, and how much history is needed.
Sensitivity: whether personal, financial or confidential information is involved, which affects security and hosting decisions.

Data migration in particular is easy to leave out of early discussions and difficult to estimate without seeing the data. Even a small sample of representative records, shared through an appropriate channel, can make an estimate more reliable.

Define constraints

Constraints narrow the range of suitable solutions, and knowing them early avoids designing something that cannot be used. Typical constraints include:

Security requirements: internal policies, access rules and any review the software must pass.
Existing environment: legacy systems that must remain, hosting preferences and technical standards.
Devices and platforms: desktop browsers, mobile devices or both, and whether specific device features are needed.
Connectivity: whether users work offline or on weak connections.
Regulatory considerations: obligations that apply to the organization’s sector or data. These should be confirmed with the organization’s own advisers, so the software can be designed to support them.
Organizational constraints: budget range, key dates and the availability of the people who will answer questions and test.

Sharing a realistic budget range and any fixed dates early is helpful rather than limiting: it allows the scope to be shaped to fit, instead of designing first and discovering the mismatch later.

Separate required features from assumptions

Requirement lists tend to mix what is essential with what is assumed, inherited from another system or simply nice to have. Separating them makes both the estimate and the project more manageable. A practical approach is to sort each item into one of three groups:

Required for the first version: without it, the software does not solve the problem.
Valuable later: useful, but the first version can work without it.
Assumptions to test: items that seem necessary but have not been confirmed with the people who will use the software.

This sorting often reveals a smaller, clearer first version that can be built, used and improved, with later items estimated separately once real use has shown what matters.

Define what success means

Agree before development how the organization will judge whether the software is working. Success criteria should come from the problem statement: for example, which manual steps should disappear, which information should become visible, or which errors should no longer occur. They do not need to be precise figures at the outset, but they should be specific enough that people can agree whether they have been met.

Defining success early also improves the estimate itself, because it shows which parts of the software matter most and deserve the most care, and which can be simpler.

What a useful discovery process should produce

When the information above is incomplete, as it often is, a short discovery phase can fill the gaps before a full estimate is committed to. A useful discovery process should leave the organization with:

a clear statement of the problem and the requirements for a first version;
workflow maps covering normal cases and exceptions;
a map of integrations and data sources;
agreed priorities, separating essentials from later additions;
an architecture direction suited to the constraints;
the key risks and open questions, stated plainly.

These outputs are useful whatever is decided next. They make any estimate more reliable, and they remain valuable if the organization chooses a packaged product or a different approach entirely.

Project preparation checklist

Before requesting an estimate, try to have answers, even provisional ones, to the following:

What problem are we solving, and why now?
Who will use the software, in which roles, and how often?
What does the current workflow look like, including exceptions?
What should the workflow look like afterwards?
Which systems must the software connect to, and how can they be accessed?
Where does the data come from, who owns it and what condition is it in?
Does existing data need to be migrated?
Which security, device, connectivity or regulatory constraints apply?
What is essential for a first version, and what can wait?
How will we know the software is working?
What budget range and key dates should the scope respect?
Who on our side can answer questions and test as the project progresses?

Not every answer needs to be final. Marking an answer as uncertain is itself useful information for whoever prepares the estimate.

Conclusion

A better definition produces a better estimate. The organizations that receive the most useful estimates are rarely those with the longest feature lists; they are the ones that can explain the problem, the people involved, the workflows, the systems and the constraints. That preparation reduces surprises, improves the conversation about scope and makes it easier to decide what to build first.

Our custom software development work begins from these questions, and the same preparation applies when the need is a browser-based tool or portal through web application development, or an app for customers or field teams through mobile application development. If you are preparing a software initiative, we would be glad to review your requirements with you.