Custom software discovery is the first stage of a project in which the supplier learns how your organisation actually works and then writes a plan you approve before any development begins. You provide your goals, your current workflow, sample documents and decisions. You receive a written requirements summary, a solution plan covering modules, roles, approvals, reports and integrations, a prototype of the key screens, and an agreed scope.
Discovery is the least visible part of a software project and the one that most decides how it ends. A weak discovery produces a plan that sounds plausible and misses the exceptions, which turn up in testing as change requests. A good one is often uncomfortable, because the supplier keeps asking "what happens when…" until the awkward cases are on paper. This guide describes what happens in the first two steps of the Timeline Digital process, Understand and Plan: the sessions, what we ask you to provide, the documents that come out, and the decisions you will be asked to make. It is written for a client preparing for a project, and it works as a checklist for judging any supplier's discovery. Our custom software development page shows where discovery fits in the whole engagement.
Where discovery sits in the process
Every Timeline Digital project follows five steps: Understand, Plan, Select Technology, Pilot, and Build & Scale. Discovery is the first two.
| Step | Question it answers | What you receive |
|---|
| Understand | What is the real business problem, and is custom software the right answer? | A written summary of workflow, problems and requirements; an honest view on whether custom is right |
| Plan | What exactly will be built, for whom, and how will it behave? | A solution plan, screen designs or a clickable prototype, and a scope both sides approve |
| Select Technology | On what foundation? | Options with trade-offs, a written recommendation, hosting approach |
| Pilot | Can we see it work? | A free pilot of 2 to 3 key modules you choose |
| Build & Scale | Build, test, deploy, support | The complete system in reviewed stages, then support |
The order matters. Technology is selected after the plan, because the plan (users, security, offline needs, integrations) decides which technology fits. The pilot comes before the full commitment, so you see working software before agreeing the full scope, milestones and commercial terms.
The Understand step in detail
What is discussed
The aim is to understand the business problem before recommending anything. Sessions are led by a senior engineer or analyst, not a salesperson, and cover:
- Current workflow. Who does what, in which order, using which tools. We ask to see it done, not only described.
- Business problems. Where time is lost, where errors occur, where customers wait.
- Manual processes. Spreadsheets, paper forms, WhatsApp messages and emails that act as systems.
- Existing systems. What you use now, what must stay, what can be replaced, and which have APIs or exports.
- Users and departments. Who will use the software, in what roles, on which devices, in which languages.
- Required improvements. What "better" means, ideally with a measure you can check later.
- Automation opportunities. Steps a rule can handle, and steps that need judgement.
- Future requirements. Where the business is heading, so the design does not block it.
What you provide
| Item | Why it helps |
|---|
| Your goals, in a sentence or two | Everything else is judged against them |
| A walk-through of the workflow, from the people who do it | Managers describe the policy; operators describe the work, and the two differ |
| Sample documents: invoices, order forms, reports, spreadsheets, exports | Show the real fields, codes and exceptions |
| A list of existing systems with owners and vendor contacts | Integration feasibility depends on the vendors |
| The names of the decision-maker and a day-to-day contact | Delays in decisions are the largest single schedule risk |
| Known constraints: hosting rules, data location, budget limits, deadlines tied to events | Constraints change the plan |
| Any previous attempts: what was tried, what failed | Saves repeating mistakes |
You do not need a written specification to start. Most projects begin without one, and writing it is part of this stage. If you want to prepare, our software requirements brief template gives a structure.
What comes out of Understand
- A written summary of your workflow, problems and requirements, which you read and correct. Reading it is the first test of whether the supplier has understood.
- An honest view on fit: whether custom software is the right answer, or whether configuring a product, integrating two tools or doing nothing yet would serve you better. A supplier who only ever says "build" is selling, not advising.
- A list of open questions and assumptions, each with an owner.
The Plan step in detail
The Plan turns understanding into a design you can approve. It is written down so that you know what will be built before development begins.
What the plan covers
| Plan section | What it contains | Typical decisions asked of you |
|---|
| Modules | The parts of the system and what each does | Which are in the first release, which later |
| Workflows | Each process as steps, with exceptions | What happens when an approver is absent, an item is rejected, data is missing |
| User roles | Who the user types are | How many roles; who administers users |
| Permissions | What each role may see and change | Rules for sensitive data; regional or branch restrictions |
| Approvals | Chains by type, amount or department | Limits, delegation, escalation |
| Automation | Notifications, calculations, scheduled tasks | Which rules are fixed and which must be editable by staff |
| Reports and dashboards | Each report: purpose, fields, filters, audience | Definitions of key metrics, agreed with finance |
| Integrations | Each connected system, direction of data, frequency, owner of each record | Which system is the master for each field |
| Security | Authentication, access, audit logging, backups | Sign-in method; retention; who sees the audit log |
| Data migration | What moves, in what format, how it is checked | Cut-off date; who signs off the migrated data |
| Future scalability | Growth in users, data and modules | What is expected in the next few years |
Prototype
We prepare screen designs or a clickable prototype of the key flows. Seeing a screen exposes problems that a document hides: a field nobody uses, a step in the wrong order, a report that needs another filter. Review it with the people who will use the system, not only the sponsor. Changes are cheap at this stage and expensive after code exists.
Scope
The plan ends in an approved scope that both sides sign off. The scope names the modules, integrations and migrations in the first release, and also what is outside it. After the free pilot, the milestones, delivery plan and commercial terms are agreed against that scope. Anything outside the approved scope is reviewed and agreed before extra work begins, so changes to cost or delivery are transparent and agreed in advance.
Your time commitment
Discovery asks for time from the people who do the work, not only from a sponsor. Expect:
- Several working sessions with the people who run the process day to day
- Short review rounds on the written summary, the plan and the prototype
- Quick answers to open questions, because a delayed decision delays everything behind it
- A named decision-maker who can approve the plan
The length of discovery depends on the size of the problem and how quickly decisions are made. There is no fixed timeframe: the schedule for your project is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. We do not promise a fixed length for discovery in advance, because a single-workflow tool and a multi-branch system do not take the same time to understand.
Common discovery failures, and how to spot them
| Warning sign | What it means | What good looks like |
|---|
| The supplier sends a quote before any conversation | Pricing from assumptions | Questions first, scope and terms after the pilot |
| Only managers are interviewed | The plan describes policy, not work | Operators and exception-handlers are in the sessions |
| No one asks about exceptions | Surprises arrive in testing | "What happens when…" is asked repeatedly |
| The plan is a feature list | Nothing is connected | Workflows, roles, approvals and data owners are explicit |
| No prototype or screens | Misunderstandings stay invisible | Key flows are clickable before code |
| Integrations are "included" with no detail | Hidden work and risk | Each integration lists system, direction, frequency and dependencies |
| No statement of what is out of scope | Disputes later | Excluded items are named |
| Everything is recommended as custom | The supplier is selling | Alternatives such as configuring or integrating are discussed |
What discovery does not do
Discovery does not build the system, fix your data or settle decisions your organisation has not made. If two departments disagree about a rule, the plan will record the disagreement and ask you to resolve it. If your data is dirty, the plan will include cleaning it, but the cleaning needs your people.
After discovery
With the plan approved, the Select Technology step documents the technology options and the recommendation with the reasons. You then choose the 2 to 3 key modules for the free pilot, and the free pilot is ready in about 2 days. If you are happy with it, the scope, milestones and terms are agreed and the full build starts. Timeline Digital does not publish prices for custom software, because every project is custom. Project source code, designs and documentation transfer to you on full payment under our IP and ownership policy.
About the author and publisher
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. This guide was written by Usama Asif to help clients prepare for the Understand and Plan steps of a custom software project; it describes our process and is not a quotation.