Discovery and problem framing
Real examples, tested against assumptions, until the constraint is named.
Product and technical direction
Decide what to build before committing months of delivery.
Clarify the real constraint, test the likely solution and decide what changes first — before committing budget to a product that may not fix it.
- A recommendation, not a pitch
- “Buy” is a valid answer
- Ends with a decision
The decision
Four honest answers, not one.
The constraint, named
- Buy
An existing product covers it with acceptable compromise.
- Connect
The tools are fine. The handoff between them is not.
- Build
Nothing off the shelf can carry this workflow.
- Change the process
The software was never the expensive part.
See it, before you buy it
What you actually end up using.
Workflow mapOne real job, as it actually runs
14 stepsWebsiteEnquiryInboxRe-typedSheetRe-typedAccountsInvoice
Same booking entered three times. That is the constraint.
Options · costed on the same workflowBuy, connect, build or change process
ComparedBuy an existing productCovers 60% · forces two process changesPossible
Connect current toolsRemoves the re-entry · keeps the stackRecommended
Build a full platformSolves everything · largest commitmentLater
Recommended first moveOne release that changes something expensive
StagedConnect website requests to the workflowFirstBring payment status onto the recordNextDecide on a wider platformAfter evidence
Map
The workflow as it actually runs.
Every tool, handoff and re-entry made visible — including steps that exist only as workarounds.
Illustration of direction-work outputs. No live customer data is shown.
What's included, every time.
The work starts before a scope or technology choice: map the constraint, test assumptions against real examples, and cost each option against the same workflow. Buy, connect, build a focused first release or change the process are all valid answers.
Build-versus-buy analysis
Products, configuration and process change costed honestly against a build.
Architecture review
What the data and systems will realistically support, and where risk sits.
A staged roadmap
The smallest useful first move, and what to decide only after it ships.
“The platform has brought our website, availability, reservations, invoices and payments into one connected workflow. Our team works from the same information, and I can see what is happening from the office or my phone.”
Before the first conversation
Questions worth asking.
Will you tell us not to build?
If that is the honest answer, yes. A configuration change, an existing product or a process change is often the better investment.
What do we get at the end?
A mapped workflow, a named constraint, options compared on the same basis, the architectural risks and a first move you can act on with or without me.
Do we need a specification before starting?
No. Bring recent real jobs, the tools involved and what is slowing the team down. Producing the definition is the work, not a prerequisite.
A practical first conversation
Bring the process that is slowing the business down.
Thirty minutes on one real workflow. If custom software is not the answer, I will say so on the call.