What a Paid Software Discovery Week Should Hand You on Friday

Friday has to be a packet, not a feeling

A paid discovery week is not a complimentary workshop with a pitch at the end. You are buying a written picture of the work so the next purchase order can be argued with. If Friday’s artefact is a slide deck titled “Insights” and a smile, you bought hospitality. Hospitality is not how you choose a software partner, and it is not how you brief the one you already chose.

We sell this shape under IT systems consulting when the brief is still a paragraph. We also refuse to start a build when the brief is still a paragraph. Those two sentences are the same ethic. Discovery is cheaper than encoding a guess about GST, branch stock, or who is allowed to reverse a dispatch. It is not free, because free discovery is a sales call that has to be recovered in the build.

This page names what should be in your inbox on Friday afternoon. If a vendor cannot promise these objects in writing before Monday, you are not buying discovery. You are buying a week of their time and a right to be disappointed. Use how to choose a software development company for the rest of the buying motion. Use this for the week itself.

The first-slice sentence

One sentence that names the users, the Tuesday job, and the test. “Warehouse staff will record dispatches in the system instead of WhatsApp.” “The counter will raise a job card that accounts can find without phoning the floor.” “Dealers will submit a claim with the invoice photo and see a status without emailing the nephew.” If the sentence needs a semicolon and three modules, it is not a first slice. It is a programme pretending to be a week’s work.

The sentence must be fail-able. After two weeks of real use you should be able to count whether the job moved. “They liked the screens” is not a count. “Four dispatches out of five were created in the system” is a count. Discovery that cannot propose a count has not found the slice. It has found a tour of the office.

Write the out-list next to the sentence on the same page. Portal, second branch, last year’s analytics, mobile store listing, bilingual help, AI draft button — whatever was wished on Monday and did not survive Thursday. The out-list is how June stays honest. An MVP without an out-list is a full project in denial. Discovery’s job is to make that denial visible while the invoice is still small.

Assumptions written so they can be wrong

Assumptions are not decoration at the back of a PDF. They are the only reason two quotes can be compared. Friday’s packet should list them as numbered claims, each one reversible. “Item codes are unique across branches.” “Tally remains the books for this phase.” “The night shift will use the same screen.” “Someone from operations can give us a day a week.” “The WhatsApp group will be closed when the path is live.” If an assumption is false, the scope moves or the date moves. That rule should be in the packet, not invented in week six.

A vendor who will not write assumptions will discover them on your clock. A vendor who writes twenty assumptions that all say “client to confirm” has not done discovery. They have done risk transfer. The useful ones are specific enough to check on Thursday: open the export, sit with the night supervisor, watch a voucher post. Friday should record what was checked and what is still a claim.

• Data: what we saw, what was a sample, what was a story.
• Rules: what two people agreed, what they still argue about.
• Access: APIs, test companies in Tally, bank or scale vendors who have not issued a key.
• People: who will sit with the build, who can say no to a director.
• Cutover: parallel run or not, and for which facts.

If the argument about a discount rule is unresolved on Friday, the packet should say so. Hiding the argument to look decisive is how you encode the louder person’s guess. Discovery is allowed to end with a disagreement. It is not allowed to end with a fake consensus.

Systems that stay

Most Kerala and India SME weeks we run end with Tally staying. Sometimes the website stays. Sometimes a weighbridge package stays for a year with a file drop. “Systems that stay” is a heading in the Friday packet, not a footnote. It stops a build team from treating the office as greenfield, and it stops a director from hearing “new system” as “we are turning Tally off in July”.

For each system that stays, write the interface: nightly file, on-post API, human export, or “no interface this phase — double entry accepted and named”. Double entry is allowed if you say it. Sneaking it in is how staff invent a third sheet. For each system that will not stay forever, write whether this phase wraps it or ignores it. Ignoring a desktop .exe that still invoices is a decision. Pretending it does not exist is not.

WhatsApp is a system. If it is the dispatch list, the packet must say whether the group closes. Software cannot retire a group chat. A manager can. Put that sentence in as a client obligation or the build will be “done” and unused. We have written that line often enough that it is no longer optional prose. It is a deliverable.

A scope you can argue with

Scope is not a module grid. It is the in-list for the first slice, the out-list, the interfaces, the definition of done, and the change path. Friday’s document should be short enough to read in one sitting and specific enough that a sceptic can point at a line and say “this is wrong”. If it cannot be wrong, it is not a scope. It is a brochure.

Definition of done, in operational words: yesterday’s record is findable; the Tuesday job completes without the vendor in the room; the posting or file you agreed with Tally exists; backups exist; a named person can undo a bad action; source and hosting ownership are written. “Looks modern” is not done. “Phase 1 complete” is not done. If those phrases appear, send the packet back on Friday before the feeling fades.

Change path: extra work is written and priced before it is done, or it is refused. Time and materials with a cap is allowed when the problem is still wet. A fixed first slice is allowed when the sentence is dry. A fixed price on an unfixed problem is not a discovery outcome. It is the thing discovery is supposed to prevent.

What Monday to Thursday actually look like

Week one of a serious build looks similar. That is not an accident. Discovery is the first week without the pretence that screens are the product. If your paid week is four remote calls and a Figma file, you purchased a studio ritual. Studios are fine for a marketing site. They are the wrong animal for the system people work in.

We will not pretend five days uncover every GST exception. They uncover whether you are ready to fund a slice, and what would make a quote comparable. The leftover exceptions become a list in the packet, not a surprise in the UAT week.

What we refuse to hand you

1. A twelve-module roadmap with dates and no counts.
2. A technology recommendation that does not name your other systems.
3. A rupee total invented before anyone has seen an export. Cost shape lives on the estimate after the packet, not as a theatrical number on Friday.
4. Fake case studies or invented client names to make the week feel validated.
5. A “free extra” build estimate that quietly ignores the out-list so the number looks kind.
6. Source-code ownership that stays with us, or a licence you cannot leave. If discovery is used to lock you in, it was a sales funnel.

You can add your own refusals. A useful one: no demo environment that uses dummy customers and a happy path only. If we did not see a bad voucher, a cancelled line, or a new supplier, the week was a tour. Say so in the packet. “We did not see month-end” is an honest Friday sentence. It should constrain the confidence of the quote, not be deleted because it sounds weak.

The packet, as a checklist

When you open Friday’s email you should be able to tick these without hunting through a slide master:

• First-slice sentence and out-list on one page.
• Numbered assumptions, each marked seen / still a claim.
• Systems that stay, with the interface or the named double entry.
• Side channels that must die — groups, sheets — and who will kill them.
• Definition of done in operational words.
• Your hours per week if a build follows.
• Risks that would stop a responsible vendor from offering a fixed slice yet.
• What we did not see.
• A scope document you could send, unchanged, to a second firm for a comparable price.

That last bullet is the test we would want applied to us. If the packet only makes sense if we do the build, it is a proposal in costume. A good discovery week is portable. You might still hire us. You should be able not to.

How this differs from a free call

A free call can sort website versus application, or tell you that Tally should stay. It cannot sit on the warehouse floor, open the embarrassing workbook, and write assumptions you can sue a scope with — figuratively, in the change-log sense. If a vendor offers a free “discovery” that ends with a fixed programme price, treat the price as marketing. Serious estimates attach to a written slice after someone has seen the data.

Paid is also how you get honesty about not building. Friday is allowed to say “do not fund software this quarter; write the discount rule and stop calling the sheet a system”. That sentence can save the year. A free process will not say it, because the free process needs a next stage. We would rather lose a vague RFP than win a build that should have been a process memo. Apply the same suspicion to anyone who cannot end a paid week with “stop”.

If you already have the sentence and the export and an operations lead with a day a week, you may not need discovery. Buy a fixed first slice with a change log. Discovery is for when two people in the business do not agree what the software is for, or when two vendors have quoted “the system” on a one-line brief. The week is how you stop being that brief.

What you do with the packet in May

Send it back with markup. Argue. Then either stop, run a second week on the hole you found — access, a branch that does not share item codes — or ask for a build estimate against the in-list only. Compare estimates using the same packet. Price is the last column. Empty cells in assumptions or interfaces are how you fund a change request that was the actual project.

Keep the Friday PDF with the purchase order. When a director adds a portal in week three, open the out-list. When a vendor says “we assumed Tally would be replaced”, open the systems-that-stay page. That is the whole value of paying for the week. The software, if it happens, is how you test the sentence. The packet is how you stay adults when the sentence is inconvenient.

If you want us to run the week, the service is consulting, not a disguised sprint. If you want the slice built afterwards, it should look like an MVP: hosted, fail-able, handed over, with the boring parts left in. If you want neither, you still have a useful artefact — a page the next vendor cannot waffle past. That is a good Friday. A slide that says “thank you for an inspiring week” is not.