Commissioning custom software: questions to ask before the estimate

Two proposals describe a “complete system”, yet one includes migration and the other only interfaces. Comparing prices without responsibilities leaves uncertainty for implementation. Prepare the objective and ask questions that make delivery verifiable. You do not need framework expertise to understand the scope and acceptance process.

Bring one task and one constraint

Explain who performs the task, which information it uses, the expected result and an exception. Include a real constraint such as a required integration, several access roles or an operation that cannot stop. A clear workflow is more useful than a long suggested technology list.

In a hypothetical order application, “manage orders” might mean viewing them or also pricing, approval, inventory and documents. Each interpretation changes scope. Resolve the operation before comparing timing and investment.

Ask how scope changes are evaluated. A backlog does not mean every future idea is included. Intellectual property, licensing and repository access require explicit terms rather than assumptions.

Establish acceptance criteria by workflow

For example: an authorised user saves a request, incomplete information produces a useful error and history explains a change. These are observable behaviours. “Beautiful interface” and “fast system” need context and conditions to become testable requirements.

Security is not a single item guaranteeing complete protection. Roles, data, recovery and integrations need application-specific assessment. Use anonymised examples rather than sharing credentials or personal datasets during the first discussion.

Identify uncertainty requiring discovery

Unknown code, undocumented rules and inaccessible integrations may justify an initial assessment with its own deliverables. It can produce a map, alternatives and an implementation boundary without promising perfect estimates.

My custom software service can organise discovery and a deliverable-based proposal. For technology decisions, see evaluating your stack. Engagement should rest on rules and responsibilities you can check, not fabricated prices or deadlines.