Northbound Freight
A shipment portal built over an existing transport management system, so customers can answer their own status questions.
Self-service replaces status calls
01 · Strategy
Digital strategy and consulting
Most failed digital projects were decided badly, not built badly. The scope was agreed in a meeting, the technology was chosen by habit, and nobody wrote down what success would look like. Six months later the budget is spent and the argument is about what was actually promised.
Strategy and consulting engagements exist to remove that risk before it becomes expensive. We work out what should be built, what it needs to do, what it will run on, what it will cost in time, and how you will know it worked.
When this is the right starting point
A discovery or consulting engagement is worth running when the decision is still open – when there is more than one credible answer and the cost of choosing wrong is high.
- You have a business problem but not yet a defined product or scope.
- Internal stakeholders disagree about what the project actually is.
- You have quotes from suppliers that are impossible to compare because each assumed something different.
- An existing platform is holding the business back and you need to know whether to fix it, replace it, or migrate it.
- You are being asked to choose a technology and the deciding factor so far has been what a vendor recommended.
- You need a defensible plan and budget to take to a board or an investor.
What we do
Three engagement types, sold separately or in sequence. Each produces written deliverables you own and can hand to any supplier – including one that is not us.
Product discovery
Structured work to define what to build. Stakeholder interviews, business process mapping, user research where users are reachable, competitor and market review, requirements definition, and a prioritised scope with an explicit line between the first release and everything after it.
Technical consulting
Independent assessment of technology and architecture decisions. Platform and stack selection against your actual constraints, integration strategy across the systems you already run, architecture review, build-versus-buy analysis, and infrastructure planning.
Digital audits
A read on what you have now. Technical audit of an existing site or application, search visibility and indexation review, performance and Core Web Vitals assessment, analytics and measurement review, accessibility review, and a prioritised list of what to fix in what order.
Diagram
How the engagement runs
A discovery engagement typically runs two to five weeks depending on the number of stakeholders and systems involved. It follows the same sequence every time.
-
Frame the problem We start with the commercial objective, not the feature list. What has to be true for this to have been worth doing? That question is answered in writing and agreed before anything else happens.
-
Talk to the people who know Interviews with the stakeholders who own the outcome, the people who will operate the thing daily, and – where they are reachable – the customers who will use it. Operational detail almost always surfaces here rather than in the brief.
-
Map what already exists Current systems, data flows, integrations, content, traffic and tooling. Replacement projects fail on things nobody documented, so we document them.
-
Define scope and sequence Requirements written as outcomes, prioritised against effort and commercial value, and split into a first release and a roadmap. Everything deferred is written down as deferred rather than quietly dropped.
-
Choose the technology A recommendation with the reasoning, the alternatives considered, and what each option would cost you later in licensing, hosting, hiring and lock-in. See our technology decisions for how we weigh those trade-offs.
-
Estimate and plan A phased delivery plan with ranges rather than false precision, the assumptions each range depends on, and the specific unknowns that would change it.
What you receive
Written, structured and yours. These documents are designed to survive being read by someone who was not in the room.
- Objectives and success criteria, stated as measurable outcomes
- Stakeholder and user research findings
- Current-state map of systems, data and integrations
- Prioritised requirements, split into first release and roadmap
- Recommended technology and architecture, with alternatives and reasoning
- Integration plan for the systems you already run
- Risk register with mitigations
- Phased delivery plan with effort ranges and assumptions
- Measurement plan defining what will be tracked and why
Typical engagements
Replacing a platform the business has outgrown
The current system works but blocks the roadmap. Discovery establishes what actually has to be carried across, what can be dropped, and whether a rebuild or a migration is the better commercial answer.
Scoping a first release
A product idea with real demand behind it and no agreed scope. Discovery produces a first release that is small enough to ship and large enough to be worth using.
Making an internal case
A team that knows what it needs but has to justify the spend. Discovery produces the plan, the numbers and the risk analysis that a board will accept.
How this runs
Every engagement follows the same sequence, with a defined output at each stage and nothing proceeding on an assumption that has not been written down. Strategy work sits inside that process rather than alongside it.
Common questions
Do we have to build with you afterwards?
No. The deliverables are written to be handed to any competent supplier. We think that is the only way an independent recommendation can be independent – if the technical recommendation only works when we build it, it is a sales document, not advice.
How long does discovery take?
Two to five weeks for most engagements. The variables are the number of stakeholders who need interviewing and the number of existing systems that need mapping. We give a fixed duration and a fixed price before starting.
We already know what we want built. Is this still worth doing?
Sometimes not, and we will say so. If the scope is genuinely settled, the integrations are understood and the technology decision is obvious, discovery adds cost without adding certainty. A short technical review is often the better fit.
What if discovery concludes the project should not happen?
Then it has done its job at a fraction of the cost of finding out during development. That outcome is rare but it is a legitimate result, and we will state it plainly rather than scope a project we do not believe in.
Related services
Related reading
Not sure what you need built yet?
That is a good reason to talk, not a reason to wait. Tell us the business problem and we will tell you whether discovery is the right next step.
Or email hello@applystudio.com – we reply within one business day.