The first step before any development: a discovery phase that maps how the work actually runs today. It ends with a document - the process map, the loss points priced in money, and a scope of work with a price. The stage stands on its own: after it you can build nothing at all, or take the document to any contractor you like.
When a separate discovery phase pays off
It is not always worth it. If the task is narrow and clear, building it straight away is cheaper. The analysis earns its cost in other situations.
Automation is wanted, the target is not clear
Many problems, one budget. With no price on the losses, the backlog gets sorted by how loud the complaints are.
Quotes differ several times over
Different prices usually mean different readings of the task. There is nothing to compare until the scope is written the same way for everyone.
The process rests on one person
Decisions are made from a file only they maintain. Until that file is unpacked there is nothing to automate: the logic lives in their head.
Software was bought and is not used
The system sits there while the work flows past it in spreadsheets. The cause is usually in the process, and new code will not cure it.
What gets examined
The audit follows what people actually do, not what the policy says. The policy shows the intent, the screen shows the outcome.
What is done by hand
Step by step: which data a person carries over, to where, and how many times a day. There is usually more manual work than the office expects.
Where data is entered twice
The same record goes into the marketplace account, the warehouse software and the report. Every repeat is a place where numbers drift apart.
Where one file decides
Purchasing, pricing or shipping depend on one employee's spreadsheet. We find the rules they calculate by and write them down.
Where the work waits
A request sits until somebody opens their inbox. Idle time shows up in the timestamps inside the systems, not in how the team feels about it.
What is already in place
Warehouse software, marketplace seller accounts, accounting, messengers. Part of the backlog closes by configuring what you already own.
What it costs
People hours, cash frozen in stock, losses from errors and sales missed. Every loss point gets a number attached to it.
What you end up with
One document, four parts. It is written to be read by an owner, not only by a developer, and to be usable without me.
Process map as it runs today
How goods, money and documents move: people, systems, handover points. No layer of wishes on top, only the current state.
Loss points with numbers
The weak spots ranked by money per month. Next to each one you can see where the figure came from.
Requirements and scope
What exactly has to be built, down to screens, data and integrations. Any contractor can price the work from that description.
Rollout order
Which contour goes live first and which comes next. Each step has to pay off on its own, not only together with the ones after it.
How the work runs
- Conversation with the owner. What hurts, which decisions are taken blind, where the money leaks most visibly. These are hypotheses, and the next steps test them.
- Watching the work happen. Talking to the people who do the job by hand and looking at their screens. This is where the private files and workarounds surface.
- Numbers. Exports from the systems and a cost attached to each loss point. Without this, priority goes to whoever complains loudest.
- Document and walkthrough. Map, losses, scope, rollout order. We go through the document together, correct what is disputed, and then it is yours.
Sometimes the answer is that no software is needed
A share of the losses goes away without code: by changing the order of work, moving a step between people, or configuring software the company already pays for. That conclusion goes into the document alongside the rest. It is bad business for a developer and fair to the client, and the companies that hear it tend to come back anyway.
The view here comes from operations, not only from code: before consulting I was COO of an e-commerce company doing 4 million dollars a month. I know what a warehouse looks like in peak season and why a tidy diagram falls apart at the receiving dock.
What it looks like in practice
Below are systems that grew out of this kind of analysis. Each has a detailed case study and a clickable demo on fictional data.
Common questions
How is this different from a scoping call
A call runs on how people describe the process in words. The analysis runs on facts: which screens they click, which files they open, how many times the same data is typed again. Described out loud, a process is almost always tidier than it is in practice.
What do I get at the end
One document in four parts: a map of the process as it runs today, the loss points priced per month, a requirements and scope document, and a rollout order one contour at a time. It is a working paper, not a slide deck. It shows where to start and what can be skipped.
Can I take the document to another contractor
Yes, the document is yours. It describes the scope of work, not a lock-in to me, so any developer can read it and quote their own price. Otherwise a discovery phase is just a way to sell development, and those are two different jobs.
Why put a price on the losses
Without a number there is no way to set priorities: the list of problems is always longer than the budget. Pricing shows which part of the workflow eats the most and what pays back first. The count covers people hours, cash frozen in stock, and errors found weeks after the fact.
What if the answer is that no software is needed
That conclusion goes into the document like any other. A share of the losses disappears once the order of work changes or the software you already pay for is configured properly. Code written for its own sake costs more and ages worse than a fixed process.
What do you need from our side
Access to the people who do the work by hand, and to the files and reports they open every day. Plus exports from the systems already in place. The owner is usually needed for two conversations: at the start and when the findings are walked through.
If an outside read on how your process actually runs would help, write a couple of lines about what hurts: LinkedIn or Telegram. What comes back is questions about the work, not a pitch deck.