What a discovery week should produce before development
The documents and decisions a one-week discovery should leave behind so development does not invent your process.
Written by Er. Jatin Varshney · Reviewed 10 November 2026 · 2 min read
Discovery is not a long presentation
A discovery week is a short, paid period to learn how the work actually runs. It should end with artefacts you can reuse even if you hire someone else. It should not end only with slides.
Five artefacts to demand
- User map: roles that will open the system in week one, not “users” in general.
- Current workflow: the statuses and handoffs you already use in chat, sheets, or paper.
- First-release boundary: what ships first, and what is parked.
- Risks and open questions: integrations, data migration, legal constraints, peak days.
- Demo plan: which screens will be tried by real staff, and when.
How we run it at JantaraX
We usually spend the week on calls with the people who do the job, not only with the owner. We write the statuses in their words. We draft the first outcome as one sentence. We list exclusions. Then we estimate the build against that page — not against a generic feature catalogue.
If discovery shows the business needs a public website first, we say so. Building an internal CRM while strangers cannot tell what you sell is a common and expensive mix-up. See also our guide on website versus web application.
A filled discovery summary (short form)
Roles: two sales executives, one owner. Current flow: Instagram lead → WhatsApp → notebook → visit. Statuses: new, visit booked, estimate sent, won, lost. First outcome: every lead has an owner and a next date. Out of v1: invoicing, customer login, WhatsApp auto-reply. Risk: duplicate phone numbers from ads. Demo: owner tries the Monday list after two weeks of build.
That paragraph is enough to start engineering without inventing a process. If your discovery ends without something like it, you are not ready to build.
Questions
Can we skip discovery to save money?
You can skip the label, not the work. Someone will invent the workflow during the build, which usually costs more than a short discovery.
How long should discovery be?
For a focused product, a few days to one week is common. Multi-branch operations may need longer. The test is whether the five artefacts exist, not the calendar.
Use this on your own project
The project brief tool turns the same questions into a page you can copy and send.
Other guides
How to brief a software project before you hire anyone
A short brief that names the user, the job the software replaces, and what the first release must do — with a filled example you can copy.
A website or a web application: which one to build first
How to tell a public website from software people log into, and how to choose the one that fixes this quarter’s actual loss.
What to specify in a custom CRM before development starts
The record, the statuses in your own words, the ownership rules, and the one Monday report — the parts that decide whether a CRM gets used.
Decisions to make before you add an AI chatbot
Which questions the bot may answer, when it must hand the chat to a person, and the three numbers worth reading after the first week.
What hosting and maintenance should cover after a site goes live
What you should own, what a maintenance month includes, and the one restore test that tells you a backup is real.
Red flags when hiring a software company in India
Seven warning signs in proposals and early calls — and what a serious partner should put in writing before you pay.
Mobile app or progressive web app: which to fund first
A practical split between an installable mobile app and a phone-friendly web app, with the questions that decide the first spend.
Corrections: support@jantarax.com. See also how this site is maintained.