Custom Software Discovery: What Should Be Decided Before Development Starts?

The most expensive software misunderstandings are usually created before development begins.

A stakeholder says “customer portal.”

One person imagines document sharing.

Another imagines payments, support tickets, analytics and mobile access.

A developer begins implementing the first interpretation.

Three weeks later, everyone discovers they were discussing different products.

A software discovery phase reduces that ambiguity.

Discovery Is Decision-Making, Not Documentation Theater

The purpose is not to create a 200-page specification.

It is to answer enough important questions that the team can design and estimate responsibly.

Good discovery should produce clarity around:

• Users.
• Problems.
• Workflows.
• Scope.
• Data.
• Integrations.
• Security.
• Non-functional requirements.
• Architecture.
• Acceptance.
• Risks.
• Exclusions.
• Delivery plan.

Actiknow’s custom web application development process uses discovery to turn business requirements into a buildable product plan before engineering effort accelerates.

Define the Business Outcome

Start with why the software exists.

Examples:

• Reduce customer onboarding from five days to one.
• Replace a shared spreadsheet process.
• Allow technicians to work offline.
• Give customers self-service access to documents.
• Automate invoice approval.
• Create one reporting source across systems.

A clear outcome helps evaluate feature requests.

Define Success Metrics

How will the business know the product worked?

Examples:

• Cycle time.
• Manual hours.
• Error rate.
• Adoption.
• Transactions completed.
• Support tickets reduced.
• Customer response time.
• SLA compliance.

Do not use “application launched” as the only success metric.

Identify User Groups

List distinct user types.

Examples:

• Customer.
• Employee.
• Manager.
• Administrator.
• Technician.
• Vendor.
• Auditor.

For each, understand:

• Goals.
• Frequency.
• Device.
• Location.
• Permissions.
• Technical comfort.
• Pain points.

A mobile field user has different needs from an office administrator.

Map Core User Journeys

For each role, document the main journeys.

Example:

Customer onboarding

1. Customer receives invitation.
2. Creates account.
3. Completes profile.
4. Uploads documents.
5. Staff reviews.
6. Customer resolves exceptions.
7. Manager approves.
8. Account activates.

This exposes required states and handoffs.

Map Exceptions

Normal flows are easy.

Software complexity lives in exceptions.

Ask:

• What if a document is rejected?
• What if an approver is absent?
• What if payment fails?
• What if a technician loses connectivity?
• What if the customer has two accounts?
• What if data does not match the external system?

Document common exceptions early.

Prioritize Scope

Classify features.

1. Must have

Required for the core business process.

2. Should have

Important but can follow the first release.

3. Could have

Useful enhancement.

4. Out of scope

Explicitly excluded.

The exclusion list is important.

It prevents assumptions from quietly becoming commitments.

Define Version One

Version one should complete a useful business journey.

It should not be a collection of disconnected screens.

Ask:

What is the smallest release that allows real users to complete the core workflow safely?

That becomes the delivery baseline.

Avoid Designing Every Future Feature

Discovery should consider future architecture, but not specify imaginary requirements in excessive detail.

Know likely directions:

• More customers.
• More countries.
• Mobile app.
• Additional integrations.
• Higher volume.

Then design sensible extension points.

Do not build features nobody has requested.

Define Roles and Permissions

Create a role-permission matrix.

For each role define:

• View.
• Create.
• Edit.
• Delete.
• Approve.
• Export.
• Administer.

Also define record scope.

Can a manager see:

• All records?
• Their department?
• Their region?
• Assigned records?

Permissions affect architecture and testing.

Define Data Entities

Identify major objects.

Examples:

• User.
• Organization.
• Customer.
• Order.
• Job.
• Document.
• Invoice.
• Approval.
• Asset.
• Project.

Do not need full database design yet.

But clarify relationships.

One customer can have many orders.

One order can have many documents.

This reveals structural complexity.

Define Systems of Record

If data exists elsewhere, decide which system owns it.

For example:

• CRM owns customer.
• ERP owns invoice.
• New application owns workflow status.
• Identity provider owns employee authentication.

Avoid ambiguous two-way ownership.

It creates synchronization conflicts.

Inventory Integrations

For every external system, capture:

• Purpose.
• Direction.
• Data.
• API/file mechanism.
• Authentication.
• Frequency.
• Volume.
• Rate limits.
• Sandbox.
• Ownership.
• Failure handling.

Integration uncertainty is often a major estimation risk.

Verify APIs During Discovery

Do not assume a vendor API supports the required operation.

Confirm:

• Endpoint exists.
• Required fields available.
• Write operation supported.
• Scopes available.
• Rate limits sufficient.
• Historical access possible.
• Webhook coverage.
• Licensing permits access.

A five-minute API assumption can create weeks of redesign.

Define Data Migration

Will existing data be imported?

Identify:

• Source.
• Volume.
• Quality.
• History required.
• Attachments.
• IDs.
• Duplicates.
• Mapping.
• Cutover.
• Reconciliation.

Migration is often underestimated because it is treated as a final import task.

Define Non-Functional Requirements

These describe how the system must behave.

Examples:

• Performance.
• Availability.
• Security.
• Scalability.
• Accessibility.
• Auditability.
• Backup.
• Recovery.
• Offline behavior.
• Browser/device support.
• Localization.
• Data retention.

They can affect architecture more than individual features.

Performance

Define realistic targets.

Examples:

• Common screens load within two seconds under normal conditions.
• Search returns within three seconds for expected dataset.
• Batch report completes within five minutes.

Avoid “fast.”

Use measurable expectations.

Availability

Does the application need:

• Business-hours availability?
• 24/7?
• Customer-facing SLA?
• Maintenance windows?

High availability adds architecture and operating cost.

Do not assume every internal tool needs five nines.

Security

Identify:

• Data sensitivity.
• PII.
• Financial data.
• Authentication.
• SSO.
• MFA.
• RBAC.
• Audit.
• Encryption.
• Tenant isolation.
• Secrets.
• Compliance requirements.

Security scope should be explicit before architecture.

Multi-Tenancy

For SaaS products, decide:

• Single-tenant or multi-tenant?
• How is tenant identity established?
• How is data isolated?
• Can users belong to multiple tenants?
• Can admins cross tenants?
• How is tenant configuration stored?

Multi-tenancy is foundational.

Do not bolt it on late.

Auditability

Which actions need history?

Examples:

• Approvals.
• Permission changes.
• Financial changes.
• Record deletion.
• Status transitions.
• Configuration.

Define audit requirements early because they affect data modeling.

Offline Requirements

If users work in weak connectivity, define:

• Which screens work offline?
• Which data is cached?
• Can users create/update records?
• How are conflicts resolved?
• How much data is stored locally?
• What happens after reconnection?

“Offline support” is not one feature.

Notifications

Define channels:

• Email.
• SMS.
• Push.
• In-app.

For each event, identify:

• Recipient.
• Trigger.
• Template.
• Frequency.
• Opt-out.
• Escalation.

Avoid designing notifications ad hoc during development.

Reporting

Define:

• Operational lists.
• Management dashboards.
• Exports.
• Scheduled reports.
• Audit reports.
• Data warehouse feeds.

Do not promise a generic “reporting module” without understanding what users need.

Search

Clarify:

• Fields searchable.
• Full text?
• Filters.
• Sorting.
• Saved views.
• Expected volume.

Search architecture can change at scale.

File Handling

If users upload files, define:

• Types.
• Maximum size.
• Storage.
• Permissions.
• Versioning.
• Virus scanning.
• Retention.
• Preview.
• Download.

Files create security and cost considerations.

Define Architecture at the Right Level

Discovery should recommend:

• Frontend approach.
• Backend architecture.
• Database.
• Cloud environment.
• File storage.
• Authentication.
• Integration pattern.
• Queue/background jobs.
• Monitoring.
• CI/CD.

Do not over-specify low-level implementation before requirements are understood.

Prototype Risky UX

Use wireframes or prototypes for workflows where misunderstanding is likely.

Examples:

• Complex dispatch board.
• Multi-step onboarding.
• Field technician workflow.
• Dashboard interaction.
• Approval queue.

A prototype can resolve ambiguity faster than paragraphs.

Define Acceptance Criteria

For each major feature, define what “done” means.

Example:

When an authorized manager approves a request, the system records approver and timestamp, changes status to Approved, prevents further editing of protected fields and triggers the configured downstream action.

Acceptance criteria reduce subjective testing.

Identify Dependencies

Examples:

• Client provides API credentials.
• Vendor enables sandbox.
• Legal approves consent text.
• Design assets supplied.
• Historical data exported.
• SSO metadata provided.

Dependencies should have owners and dates.

They can block delivery even when engineering is on schedule.

Identify Risks

Typical risks:

• Unverified third-party API.
• Poor legacy data.
• Unclear business rules.
• Complex migration.
• Offline sync.
• Performance at scale.
• External approval.
• Changing stakeholder ownership.

For each risk define mitigation.

Estimate With Assumptions

An estimate should state assumptions.

Examples:

• One external accounting integration.
• Up to five user roles.
• No offline mode in phase one.
• Client supplies clean customer migration file.
• English only.

Assumptions make uncertainty visible.

Create a Change Process

Requirements will change.

Define:

• How changes are raised.
• Who approves.
• How effort/timeline impact is assessed.
• How documents update.
• How priority changes.

Change control is not bureaucracy.

It protects shared understanding.

Define Delivery Milestones

Break the build into meaningful increments.

Examples:

• Foundation/authentication.
• Core workflow.
• Integrations.
• Reporting.
• UAT.
• Migration.
• Launch.

Milestones should produce testable outcomes.

Plan Testing

Include:

• Unit testing.
• Integration testing.
• Permission testing.
• Workflow testing.
• Data migration testing.
• Performance testing where needed.
• Security testing.
• UAT.
• Regression.

Testing should not be one final week.

Plan Environments

Define:

• Development.
• Staging/UAT.
• Production.
• Data separation.
• Credentials.
• Deployment process.
• Environment configuration.

Do not test destructive integrations against production accidentally.

Plan Handover

Before development, agree:

• Repository ownership.
• Cloud ownership.
• Credentials.
• Documentation.
• Deployment instructions.
• Architecture docs.
• Support.
• Warranty.
• Maintenance.
• IP.

A buyer should know how the product remains operable after launch.

Discovery Deliverables

A useful discovery package can include:

• Business objectives.
• User roles.
• User journeys.
• Feature scope.
• Exclusions.
• Wireframes.
• Data model.
• Integration inventory.
• Architecture.
• Security/non-functional requirements.
• Migration plan.
• Acceptance criteria.
• Risks.
• Implementation plan.
• Estimate.
• Open decisions.

The exact format can be concise.

The value is shared decisions.

Frequently Asked Questions

What is a software discovery phase?

It is a structured pre-development process that clarifies business goals, users, workflows, scope, data, integrations, architecture, risks and acceptance criteria.

How long should software discovery take?

It depends on complexity. A small internal tool may need a few focused sessions; a multi-system platform may require a more substantial discovery engagement.

Does discovery eliminate scope changes?

No. It reduces avoidable ambiguity and creates a controlled process for changes that emerge later.

Should UI design happen during discovery?

Key workflows should usually be wireframed or prototyped when visual interaction is important. Full polished design can continue afterward.

Why verify integrations before development?

Because assumed API capabilities, rate limits or licensing can materially change architecture, scope and estimates.

What should be excluded from discovery?

Avoid spending excessive time specifying distant hypothetical features. Focus on decisions that affect the current product and architecture.

What is the main output of discovery?

A shared, buildable definition of the product with enough technical and business clarity to estimate, implement and test responsibly.

Conclusion

Good software discovery is not about producing more documents.

It is about making expensive decisions before expensive implementation begins.

Define users, workflows, exceptions, scope, data, integrations, permissions, non-functional requirements and acceptance criteria.

Verify risky assumptions.

State exclusions.

Document open decisions.

Then development starts with a shared picture of what is being built and why.

If you are preparing a complex custom software project, Actiknow can help turn the business requirement into a clear product, architecture and implementation plan before development starts. Discuss your software project with Actiknow.