Custom Software Discovery Checklist: Questions to Answer Before Development

Before approving a custom software proposal, make sure the team understands the business problem, the people and processes involved, and what a successful first release must do. A clear discovery process helps you compare proposals on more than price and reduce misunderstandings about scope, integrations, data, and delivery.

Use this checklist in stakeholder interviews or a discovery workshop. It is a planning tool, not a complete software requirements specification (SRS): its purpose is to help your business and prospective development partner agree what needs exploring before development is estimated or started.

When is custom software worth exploring?

Custom software may be worth investigating when an important process is difficult to run with your existing tools, workarounds are creating measurable cost or risk, or several systems need to support a workflow that off-the-shelf products do not handle well. It can also make sense when the software must fit a distinctive operating model or support a capability central to your business.

It is not automatically the better choice. Compare the cost and responsibility of building, operating, maintaining, and improving a custom product with the cost and limitations of configuring an existing one. Consider whether a standard product, a small integration, or a process change would solve the underlying problem first. For a fuller comparison, read custom software development vs off-the-shelf software.

Problem and process discovery

Start with the work the business needs to improve, not a list of screens or features. Document how the process works today, including exceptions and handoffs. A simple swimlane diagram, annotated screenshots, or a step-by-step workflow can be enough to reveal missing steps and conflicting assumptions.

• What problem are we trying to solve? Describe it in business terms: delays, errors, duplicated work, poor visibility, missed opportunities, or another specific outcome.
• Who experiences the problem, and how often? Identify teams, locations, customers, transaction volumes, and peak periods.
• What triggers the process, and what marks completion? Include approvals, exceptions, cancellations, and rework.
• What happens today? Record each step, the person or system responsible, information used, decisions made, and handoffs.
• Where does work get stuck or fail? Gather real examples of delays, duplicate entry, errors, and manual workarounds.
• What should improve? Choose a small set of outcomes the business can measure, such as turnaround time or error rate. Confirm the baseline and who will track the result.

Separate the business need from a proposed solution. For example, “we need faster approvals” states an outcome; “we need an approval dashboard” is one possible solution. Keeping that distinction open gives the team room to investigate simpler or more effective options.

Users, roles, and workflows

Do not assume one representative user can speak for everyone. Include people who do the work, approve it, support it, and are affected by its results. If the product is customer-facing, include the customers or partners who will use it.

• Which user groups need access, and what does each group need to accomplish?
• What can each role view, create, change, approve, export, or delete?
• Who can grant or remove access, and how are staff changes handled?
• Which tasks are frequent, urgent, or especially error-prone?
• Do users work on mobile devices, in low-connectivity settings, or with assistive technology?
• What notifications, reports, or audit history do different roles need?
• Who resolves exceptions, and what should happen when an owner is unavailable?

Ask frontline users to walk through real examples, not just describe an ideal process. This often surfaces informal rules, missing data, and approval steps that are easy to miss in a management-only discussion.

MVP and scope boundaries

An MVP (minimum viable product) should test a valuable, usable slice of the business solution—not simply be the cheapest or shortest version. Agree what must be included for the first release to work end to end, and explicitly record what can wait.

• Which user and business problem should the first release address?
• What is the minimum complete workflow, from its starting point to its outcome?
• Which features are essential for launch, and which are later improvements?
• What must remain manual for now, and who will perform that work?
• Which user groups, locations, languages, or transaction types are included initially?
• What is explicitly out of scope, such as a mobile app, advanced analytics, or automated migration?
• What evidence would justify expanding the product after launch?

For a web-based product, define browser and device expectations, user access, hosting responsibilities, and the operational workflows it must support. Our guide to custom web application development in India can help you think through web-app scope.

Integrations and data ownership

Integrations are more than a list of systems. For each one, establish what information moves, in which direction, how often, and what happens when a transfer fails. Ask system owners whether access, documentation, test environments, or third-party approvals are available.

• Which existing systems must connect to the new software, and which are optional?
• Which system is the source of truth for each important record?
• What data is exchanged, how frequently, and through what supported interface?
• Who owns integration credentials, vendor relationships, and recurring API or service fees?
• How should the product handle duplicates, rejected updates, outages, and retries?
• Does historical data need migration? Who cleans, maps, validates, and approves it?
• Who owns the data, source code, designs, documentation, and cloud accounts under the proposed agreement?
• How can your business export its data, retain it, or securely delete it when needed?

Security, compliance, and reliability

Raise security and privacy requirements during discovery, not after the main design is fixed. Identify what information the software will process, who should access it, and what could happen if it is exposed, altered, or unavailable. The right controls depend on the product, data, users, and applicable obligations; ask your legal or compliance adviser to confirm requirements for your case.

• Will the product handle personal, financial, health, confidential, or otherwise sensitive information?
• What data is genuinely needed, and how long should it be retained?
• How will access be authenticated, restricted by role, and removed when no longer needed?
• What audit logs, backups, recovery arrangements, and incident-response responsibilities are required?
• What availability, response time, usage volume, and recovery expectations matter to the business?
• Which environments, vendors, hosting locations, or subcontractors will handle the data?
• Who will review vulnerabilities, dependency updates, and security changes after launch?

For projects in India, ask your adviser and delivery partner to assess which obligations apply and when. The Digital Personal Data Protection Rules, 2025 have a phased commencement schedule. Also ask whether CERT-In directions apply to your organization and system, and who is responsible for relevant logging and incident-response processes. The CERT-In directions set requirements for covered entities. Do not treat a vendor’s general security statement as confirmation that your business is compliant.

Budget and delivery assumptions

A proposal is only comparable when its assumptions and exclusions are visible. Ask what work is included in the estimate, what could change it, and which costs continue after launch. If you are comparing a custom build in India, request the same scope, assumptions, and delivery responsibilities from each provider before comparing totals.

• Does the estimate include discovery, design, development, testing, deployment, and initial training?
• Are data cleanup and migration, integrations, security testing, and accessibility work included?
• What hosting, software licences, messaging, payment, or third-party service charges recur?
• Is the commercial model fixed-price, time-and-materials, or a staged combination?
• What assumptions about stakeholder availability, approvals, data quality, or vendor access affect the estimate?
• What support, maintenance, warranty, and post-launch response are included—and for how long?
• How are taxes, including any applicable GST, shown in the quotation?
• What are the payment milestones, and what deliverable or review triggers each one?

Be cautious when a detailed price or launch date is presented before the provider has understood the workflows, integration constraints, data, and acceptance expectations. Ask what is known, what remains uncertain, and how the estimate will be updated as those unknowns are resolved.

Acceptance criteria and change control

Acceptance criteria describe observable conditions for deciding whether a feature or deliverable meets the agreed need. They should be clear enough for the business and delivery team to review together. For instance, instead of “approvals are easy,” define which role can submit a request, who can approve it, and what status and record are visible afterward.

• Who reviews and accepts each deliverable?
• What specific scenarios must work, including relevant errors and exceptions?
• What data, devices, browsers, or user roles are used in acceptance testing?
• How are defects classified, reported, fixed, and retested?
• What happens if a deliverable does not meet the agreed criteria?
• Who can request a scope change, approve it, and decide what it does to cost or schedule?
• How will the team distinguish a defect against agreed criteria from a new feature request?

Record decisions and assumptions, name a business decision-maker, and agree how unresolved questions will be handled. Unclear scope, missing requirements, and changing expectations can lead to rework or disputes about what was included. A simple written change process helps everyone assess a request before committing to it.

Discovery workshop checklist

Before a workshop, invite the sponsor, process owners, frontline users, IT or system owners, and relevant security, legal, or compliance stakeholders. Share the problem statement and any existing workflow documents in advance. Nominate someone to capture decisions, open questions, and owners.

1. Agree on the business problem, desired outcomes, and how success will be measured.
2. Map the current process, users, handoffs, exceptions, and pain points.
3. Define the first-release users, end-to-end workflow, priorities, and exclusions.
4. List integrations, data sources, migration needs, and system owners.
5. Capture security, privacy, accessibility, performance, availability, and support expectations.
6. Review budget range, delivery assumptions, dependencies, and ongoing costs.
7. Agree acceptance responsibilities, change control, and the next decisions required.

What evidence should you request before approving a proposal?

Ask for more than a feature list and a total price. A useful proposal should show that the provider understood your business context and should make the boundaries of the work reviewable.

• A summary of the problem, intended outcomes, users, and key workflows.
• A proposed MVP scope, explicit exclusions, and assumptions that could affect delivery.
• An integration and data approach, including migration responsibilities where relevant.
• Security, reliability, testing, deployment, and support responsibilities.
• Deliverables, milestones, acceptance criteria, pricing model, and change-control process.
• Examples of relevant work or references you can verify, plus the proposed team and decision process.

Before signing, confirm that your business and the provider agree on what will be delivered, what remains uncertain, who makes decisions, and how changes are assessed. If important answers are still unknown, consider a time-bounded discovery phase with defined outputs—such as validated workflows, prioritised scope, technical risks, and a more dependable delivery estimate—before authorising the build.