How to scope a custom software project before hiring a developer

Start with the work, not the feature list

A request such as 'we need an ERP' tells a developer very little. An inventory manager, a school administrator and a field-service team might all use the word ERP, but the work each team needs to do is different. Begin with one routine task that is difficult today.

Write down who starts that task, where its information comes from, which steps require approval and what counts as a successful result. If employees work around the current system using spreadsheets or messaging apps, include those workarounds. They often reveal the requirements that a clean diagram misses.

• Name the people using the system and the permissions each role needs.
• Describe the current workflow from first action to final confirmation.
• List the documents, notifications or reports produced along the way.
• Record the common mistakes and what should happen when they occur.

Separate the first release from later ideas

A useful first release completes a real workflow. It does not need every reporting screen and administrative option planned for the future. For example, a service-booking system may need requests, assignment and status updates before it needs a customer loyalty programme.

Ask what would make the software usable for a small group of people next month. Then keep the remaining ideas in a second list. This gives the development team a scope it can price and allows the business to test its assumptions before investing further.

Identify the integrations that could change the estimate

Projects often become complicated where new software meets an existing accounting tool, CRM, payment provider or database. An integration that looks simple on a diagram may depend on an old API, inconsistent data or approval from another vendor.

For each system, write down what information needs to move, in which direction, how often and who owns the account. Confirm that the existing vendor permits the connection. If access is uncertain, describe it as an open question instead of assuming the integration is available.

• Current software and its vendor or technical contact
• Available API documentation or export samples
• Which information can be edited and which is read-only
• What should happen when the other system is offline

Decide who is responsible after launch

A quote for writing application code may not include infrastructure, domain renewals, software subscriptions, app-store accounts, data migration or ongoing maintenance. Ask the developer to show these as separate items where relevant.

Discuss how the team will test the software, who signs off on acceptance and how problems are reported after release. Ownership of source code, deployment access and business data should be clear in the agreement. A business should be able to recover its own data if it later changes vendors.

What to send when requesting an estimate

A short brief is enough to start. Include the problem, the main user roles, the critical workflow, integrations, desired platforms and any budget or timing constraints. Mark requirements you are unsure about rather than making them sound final.

A good estimate explains its assumptions. If two proposals differ widely, compare the included testing, support, data migration and access controls before deciding which is cheaper. Ask each developer what would need to be clarified to make the estimate more reliable.