01
Discovery & business analysis
Stakeholder workshops, workflow mapping, requirements, user stories, feasibility, and risk and dependency mapping.
Product Strategy & UX/UI
The cheapest place to be wrong is before anyone writes code.
Discovery, journey mapping, prototyping and interface systems exist to move the expensive mistakes forward — into a week of design rather than a quarter of development.
Overview
Most failed software was built correctly. It was just the wrong thing.
Delivery risk rarely comes from the engineering. It comes from an unvalidated assumption about who the user is, what the process actually does, or which problem was worth solving first.
Discovery is how we make those assumptions explicit and testable. A prototype that three real users struggle with tells you more than a signed-off requirements document.
The output is not a folder of artefacts. It is a smaller, better-argued scope, a clear MVP boundary, and a shared understanding of what success looks like.
What you get
- Discovery reportWorkflows, users, systems, constraints, risks and a recommended direction — including options we advise against.
- PrototypeA clickable prototype of the journeys that carry the most risk, tested with real users.
- MVP definitionWhat is in, what is deliberately deferred, and the reasoning behind the line.
- Design systemComponents, patterns, states and accessibility rules ready for engineering.
- Delivery planSequenced roadmap with dependencies, assumptions and the decisions still outstanding.
Scope
What this covers.
02
Product strategy
Product definition, roadmap, MVP boundary, prioritization, build-versus-buy and success measures.
03
Research
Talking to the people who will use it — and the people who currently do the job it replaces.
04
Journeys & architecture
Information architecture, user journeys and the structural decisions that are hard to change later.
05
Prototyping
Clickable prototypes tested with real users before engineering commits.
06
Design systems
A component library and interface rules so the product stays coherent as it grows.
Where it fits
The problems this actually solves.
If none of these sound familiar, this is probably not the capability you need — and we would rather point you somewhere more useful.
Everyone agrees on the goal and disagrees on the scope
A written MVP boundary with the reasoning, so trade-offs are decided once rather than re-argued every sprint.
Requirements keep changing mid-build
Discovery surfaces the unknowns early, when changing direction costs days instead of months.
The last system was technically fine but nobody used it
Usability testing with real users before build, and adoption instrumented after launch.
Screens are inconsistent and each one is designed from scratch
A design system with reusable components and documented interface rules.
We cannot tell whether to build, buy or integrate
A structured build-versus-buy assessment with the total cost of each path made explicit — including whether a WordPress or WooCommerce build would do the job for a fraction of a custom one.
Delivery
How we deliver it.
01
Frame
Agree the business problem, the users and what a good outcome would look like in measurable terms.
02
Explore
Workshops, workflow mapping and research with the people who do the work today.
03
Prototype
Design the risky journeys and put them in front of real users.
04
Define
Set the MVP boundary, document requirements and architecture direction, and sequence delivery.
05
Hand over
Move into build with a design system and a scope both sides understand.
Technology
What we build it with.
Selected around product goals, integration needs, security requirements, team fit and long-term maintainability — not trends alone.
Design
- Journey mapping
- Wireframing
- Clickable prototypes
- Design systems
- Usability testing
Standards
- WCAG 2.2 AA
- Responsive design
- Component libraries
Handover
- Documented requirements
- User stories
- Acceptance criteria
Where AI fits
Decide whether AI belongs in the product at all.
Discovery is the right place to test that assumption. We assess AI use cases on value, data readiness, risk and effort — and are comfortable recommending against them.
Explore AI & Intelligent AutomationQuestions
Straight answers.
It is worth it when scope is unclear or the workflow is high-risk — which is most of the time. Its most valuable output is often a smaller scope than you expected, or a recommendation to solve the problem a different way.
No. The discovery outputs are yours and are written to be usable by any competent engineering team, including your own.
Typically a small number of weeks, scaled to the complexity of the workflow and how many stakeholders need to be involved. We agree the boundary before starting.
Then it has done its job at a fraction of the cost of finding out during development, and we will say so plainly.
Not sure yet whether it should be built at all?
That is exactly the right time to talk. A short discovery engagement will tell you more than another round of internal debate.