First 1–2 working days
Move fast by making the critical path visible.
Urgency is managed through qualification, narrow scope, immediate access and close decisions—not by hiding risk or pretending every project is the same size.
Discuss an urgent projectA release path built around evidence.
As little as 7 days
Build
For a qualifying brief, target the smallest working product that proves the decisive workflow and can be assessed by real stakeholders.Target: within 30 days
Pilot
Put the workflow into controlled use with the right users, safeguards, feedback loop and deployment decision.By agreed release plan
Deploy
Harden, integrate, observe and improve the product with explicit ownership, acceptance criteria and operational evidence.The conditions behind a seven-day MVP.
The target is credible only when the engagement can move through all four gates. If one is missing, we revise the plan before work begins.
- 01
A bounded outcome
One decisive workflow, explicit acceptance criteria and clear exclusions.
- 02
Technical access
Systems, APIs, representative data and owners available at the start.
- 03
Decision speed
A named decision-maker able to resolve scope and risk quickly.
- 04
Delivery capacity
A dedicated team and budget agreed for the urgent path.
One daily delivery rhythm.
Decide
Resolve the issue most likely to block the critical path.
Show the work
Keep working software, risks and acceptance criteria visible.
Verify
Test the agreed outcome, document limits and decide what moves next.
01
Before the clock starts
What to bring to an urgent software or AI development conversation
Urgency is easier to assess when the buyer can explain the operational consequence in plain language. A useful first brief says what has stopped, what is about to happen, who is affected, what has already been tried and what a safe improvement would look like. It does not need a completed specification. It does need enough context to distinguish a time-sensitive delivery problem from an ambition that has not yet been made decision-ready.
Where possible, identify the person who can make scope, access and commercial decisions during the first phase. A delivery team can investigate alternatives, but a seven-day MVP target is not meaningful if essential access, risk decisions or approvals remain unowned. The aim is not to pressure a buyer into a rushed commitment; it is to make the critical path visible early enough for everyone to decide whether a rapid route is credible.
Share the current route through the work, even if it is incomplete. A screen recording, a rough process map, a queue export with sensitive details removed, a list of systems, a sample of the decision a user makes, or a short description of the failure is often more useful than a polished presentation. If the situation involves a live incident, separate the facts known now from assumptions, workarounds and unresolved questions so that stabilisation work does not accidentally become a speculative rebuild.
- 01
The event, deadline or operational consequence that makes the work urgent.
- 02
The accountable sponsor, day-to-day product or operational owner, technical contact and decision-maker for the first phase.
- 03
The smallest user outcome that would reduce risk or create enough value to justify a pilot.
- 04
Known systems, suppliers, data sources, environments, APIs, repositories, credentials processes and access constraints.
- 05
Current evidence: logs, error messages, screenshots, user journey, examples of good and bad outcomes, architecture notes or support history.
- 06
Known boundaries: data sensitivity, affected people, regulatory or contractual constraints, security review expectations and change windows.
- 07
A realistic route for agreeing budget, accepting work and releasing the first bounded outcome.
02
Go, narrow, sequence or stop
Questions that make a delivery decision stronger
A sensible first decision is usually smaller than the overall ambition. Rather than asking whether a platform can solve every future need, ask whether a named user can complete one important workflow safely enough to learn from it. That question makes dependencies, trade-offs and acceptance evidence concrete. It also gives an organisation a clear point at which to stop, change direction or authorise the next increment instead of allowing a time-sensitive project to drift into undefined scope.
For AI-enabled work, the question is not simply whether a model can produce an impressive answer. It is whether the intended user can recognise what the output represents, see appropriate supporting context, act within defined authority and recover when the answer is uncertain, incomplete or wrong. The buyer should decide which source remains authoritative, who can override the output, what outcome is prohibited and what evidence is needed before a pilot can expand.
Commercially, a credible urgent route needs a transparent conversation about capacity, scope, dependencies and budget. Work may be structured around a short assessment, a bounded MVP, a controlled pilot, recovery/stabilisation or a further delivery phase. Exact pricing, delivery dates and team composition should follow the proposed scope and availability. They should not be implied by generic website copy or a case-study style timeline.
- 01
What is the smallest outcome that makes a material difference this month, not merely a demonstration?
- 02
Which assumption would make the proposed route unsafe, impossible or commercially unhelpful if it proved false?
- 03
Who can decide on scope changes, data access, third-party approvals, deployment and acceptance without creating a long approval loop?
- 04
What should a user do if the system is unavailable, an integration fails or an AI-supported result is not trustworthy enough to use?
- 05
What existing team, supplier or customer workflow must continue to operate while the change is made?
- 06
What evidence would allow the sponsor to say yes to a pilot, no to further investment, or yes to a carefully controlled rollout?
- 07
Which costs, licences, providers, specialist reviews or client-side activities are outside the proposed delivery team and need early ownership?
Let us test the deadline against the work.
Share the outcome, urgency, systems, access and budget. We will return a credible route—or explain what prevents one.
Start a conversation