Software project discovery checklist

Discovery is where product ideas become buildable scope. Use this checklist with your team or a delivery partner before you lock a timeline or budget. It is the same sequence Kode Builder uses when scoping SaaS, internal tools and customer-facing platforms — business outcomes first, then users, workflows, data, integrations and the constraints that decide architecture. Print it, share it, or tick items in the browser as you go.

1. Business Goals and Success Criteria

If you cannot name the outcome, every feature will feel equally urgent. Write the problem and how you will know the first release worked.

• Problem statement written in one paragraph (who hurts, why now)
• Primary business outcome named (revenue, cost, risk, speed, compliance)
• In-scope product type decided (MVP, internal tool, customer portal, platform)
• Out-of-scope ideas parked so they do not leak into v1
• Success criteria for launch defined in observable terms (not “better UX”)
• Constraints listed: regulation, geography, existing contracts, brand rules
• Competitors or analog products reviewed for must-have vs differentiators
• Decision owner named for scope trade-offs during the project

2. Users, Roles and Permissions

Software is used by people with different jobs. Map who signs in, what they can do, and who never sees the admin.

• Primary user personas listed with jobs-to-be-done (not just job titles)
• Secondary users identified (ops, finance, support, partners, auditors)
• Role matrix drafted: admin, operator, customer, read-only, partner
• Permission rules sketched (who can create, approve, export, delete)
• Authentication approach chosen (email, SSO, OTP, social, invite-only)
• Multi-tenant or multi-org needs confirmed (one company vs many customers)
• Accessibility and language needs noted (English, Hindi, Punjabi, others)
• Support and onboarding path for first users documented

3. Workflows and Core Journeys

List the paths that must work on day one. Edge cases belong on a later list unless they are legally required.

• Happy-path journeys mapped end to end (3–7 core flows is typical for an MVP)
• Statuses and hand-offs defined (draft → submitted → approved → done)
• Exception paths listed: rejection, cancellation, refund, retry, timeout
• Notifications identified (email, SMS, in-app, webhook) with who receives them
• Offline or delayed steps noted (manual review, warehouse, bank settlement)
• Admin/ops screens listed separately from customer-facing screens
• Reporting questions written (“What do we look at every Monday?”)
• Mobile vs desktop priority decided per journey

4. Data, Records and Ownership

Every screen is a view of data. Decide what you store, who owns it, and what you must be able to export.

• Core entities listed (users, orders, tickets, vehicles, invoices — your domain)
• Source of truth named for each entity (this product vs an existing system)
• Sensitive fields classified (PII, payment, health, location, credentials)
• Retention and deletion rules sketched (including user export / right to erase)
• Existing spreadsheets or databases identified for migration or import
• File and media needs listed (uploads, size limits, virus scan, CDN)
• Audit trail needs decided (who changed what, and when)
• Backup and restore expectations written in plain language

5. Integrations and External Systems

Integrations often take longer than the screens. Name every system that must talk to the product.

• Payment, identity, email, SMS and analytics providers listed
• ERP, CRM, WMS, TMS or accounting tools named with read vs write needs
• Direction of sync documented (one-way, two-way, near real-time, nightly)
• API access confirmed (keys, sandboxes, rate limits, who owns the vendor account)
• Webhook and event needs listed (order paid, shipment update, user signup)
• File-based exchanges noted (SFTP, CSV, EDI) if APIs do not exist
• Failure handling agreed (retry, dead-letter, manual queue, customer message)
• Third-party SLAs and fallbacks understood before go-live

6. Non-Functional Requirements (NFR)

Performance, security and operability decide hosting and cost. Capture them now so architecture is not guessed later.

• Expected users and peak usage described (even if approximate)
• Availability expectations stated (business hours vs always-on)
• Regions and data residency listed (where users and data may live)
• Security baseline agreed (HTTPS, secrets, least-privilege roles, MFA for admins)
• Compliance context named if relevant (PCI scope, SOC 2, HIPAA, GDPR)
• Device and browser support listed (and what you will not support in v1)
• Logging, alerting and who gets paged after launch documented
• Environments planned: local, staging, production (and who can deploy)

7. Launch Plan and Rollout

Shipping is a sequence: who gets access first, what you measure, and how you undo a bad release.

• Launch audience defined (internal only, beta customers, public)
• Content and legal assets listed (terms, privacy, help articles, training)
• Cutover from current process described (spreadsheet, WhatsApp, old tool)
• Rollback approach written (feature flags, previous build, manual fallback)
• Support coverage for launch week assigned (hours, languages, escalation)
• Analytics events defined so you can tell if journeys complete
• Known v1 gaps communicated to stakeholders in writing
• Post-launch review date scheduled (what to keep, cut or sequence next)

8. Budget, Timeline and Ownership

Discovery should end with a decision: what you will fund, who owns the product, and how change requests are handled. For typical India-based build ranges, see the custom software cost guide.

• Budget band and payment structure agreed (fixed scope vs phased)
• Timeline expressed as phases, not a single optimistic date
• Product owner named on the client side (one person, not a committee)
• Engineering, design and hosting ownership after launch documented
• Change-request rule agreed (what is in scope vs a new estimate)
• Source code, infrastructure and account ownership listed (you vs vendor)
• Recurring costs listed: hosting, third-party APIs, SMS, monitoring
• Next decision date set: proceed, pause, or reduce MVP scope