New product or workflow
Bring a process owner, sample inputs and outputs, user roles, retained systems and constraints. We define one useful release, a process map, interfaces, acceptance scenarios and an estimate with explicit assumptions.
Pricing & Process / Sample brief
What you receive from a paid assessment.
A paid assessment ends with a decision brief. This page shows the scope of an assessment and a sample brief for an orders-and-stock release.
Paid assessment
Resolve the costly unknowns before committing to a build.
Start with a conversation about your needs. If we need to investigate before estimating the build, we agree a separate paid assessment. Its proposal defines the questions, deliverables, fee or capped hours, schedule, review sessions and acceptance criteria before work begins.
Existing application
Bring a system owner, an architecture overview, known incidents and details of available access. We review deployment, dependencies, data and recovery, then identify the risks and recommend how to stabilise or replace the system in stages.
AI feasibility
Bring one approved data source, a reviewer who knows the subject and representative questions. We define permissions, a baseline, evaluation questions and operating-cost assumptions to decide whether a focused pilot is worth building.
What you review at the end
A decision brief connecting the workflow, proposed scope, exclusions, unresolved risks, acceptance checks and cost assumptions. Each agreed question is answered with evidence, or left open with an owner and a next action. Then you choose a build proposal, a smaller investigation, or a pause.
Production software, a full security audit, additional stakeholder interviews and integrations are included only if explicitly agreed. The schedule depends on your team’s availability and access to the systems involved. We also agree deliverable formats, ownership and reuse rights.
Sending an enquiry does not commit you to paid work.
Sample decision brief
Follow one agreed scope from assessment to handover.
This brief follows the orders-and-stock example. The assessment defines the proposed scope, risks and acceptance scenarios. It also records the checks and responsibilities needed for a later launch decision.
Workflow and scope
Customer → order → stock reservation → portal status → overdue-order report. The new system owns order status and reservations after cutover; accounting owns invoices and payments. One warehouse and one accounting export are included. Forecasting, multi-currency billing and additional warehouses are deferred.
Inputs and open risks
The client supplies a sanitised customer/product/order extract, accounting API documentation and an operations reviewer. We investigate stable source IDs, duplicate customers and provider retry behaviour. The technical lead records evidence; the client data owner resolves ambiguous mappings before migration approval.
Acceptance examples to agree before implementation
| Scenario | Expected evidence | Reviewer |
|---|---|---|
| Normal order | An authorised user creates one order, stock is reserved once, and the customer sees only their order status. | Client operations owner |
| Stock shortage or repeated request | No partial reservation is silently committed; the exception is visible. Retrying the same operation creates no second reservation. | Operations + QA |
| Accounting outage | A failed export remains visible. Retry uses the same business reference and cannot silently produce a duplicate invoice. | Finance + integration owner |
| Permissions and reporting | Another customer’s record is inaccessible. The overdue count excludes cancelled and completed orders and matches the source list at the same report time. | Client data owner + QA |
| Trial import | Source and target counts, key totals, selected relationships and rejected records are reconciled; rerunning the import does not duplicate history. | Client data owner |
Schedule and client decisions
Example sequence: assessment → design approval → build and review cycles → trial import → pilot → launch. We set dates once team availability, provider access and review periods are confirmed. Each stage needs the relevant client decisions on data ownership, exception rules and acceptance. If assumptions change, we update the forecast.
Go/no-go and fallback
Launch only after accepted scenarios, reconciled data, tested recovery and agreed support readiness. Record unresolved issues and who accepts them. If checks fail, postpone cutover. During the pilot, define which system accepts writes and how changes are reconciled before reverting; a backup alone is not a rollback plan.
Handover and daily use
Agree a repository and access inventory, deployment instructions, a data map, an operator guide, a backup and restore procedure and an issue contact. Pilot users practise an order, a shortage and a failed export. Record their questions, account owners and who approves the end of transition.
Decision after assessment
Proceed when the first release, estimate assumptions and responsibilities are agreed. If a risk still prevents a reliable proposal, reduce the scope or investigate that risk before commissioning development.
Your next system starts with a conversation
Tell us what needs to work better.
Share your processes, the systems you use today, and what you want to improve first. Our CEO normally leads the first discussion of possible approaches and what needs investigation before an estimate.
Europe, USA, Canada & Australia