Paid PoC for software and AI projects in Japan

A concrete first workflow

Example: suggest a support category from a redacted message, with human review.

What you receive

A narrow working prototype, agreed test inputs, a check log and a recommendation to continue, revise or stop.

An example acceptance check

For an ambiguous message, the system must request review. The report records expected and actual behaviour, including failures.

What a paid PoC actually buys

The buyer is paying for decision-quality evidence, not a long discovery exercise or a polished slide deck. The scope should connect one workflow to representative data and a visible result.

• One written business question
• One working user and data path
• Acceptance results against named test cases
• A recommendation to proceed, change, or stop

When a paid PoC is the right first step

Use a paid PoC when the team already has a workflow, data source, user problem, and decision owner, but still needs proof before approving a larger build.

• A budget owner needs evidence
• The workflow touches real data or APIs
• Users need to review the software or AI behavior
• The next decision can be stated before kickoff

Paid PoC cost and estimate drivers

Urbano DX's current 2-week package is priced at £9,500 to £13,500. The final quote depends on data readiness, number of integrations, UI depth, AI evaluation work, security constraints, and handover scope.

• Fixed scope and written exclusions
• Named assumptions behind the estimate
• Change requests priced before work expands
• Currency, tax, invoicing, and payment terms confirmed in the proposal

What the PoC contract should define

A useful statement of work removes ambiguity before delivery starts. It should describe the proof, responsibilities, data access, ownership, acceptance, and what happens when an assumption changes.

• Scope, exclusions, milestones, and acceptance criteria
• Client inputs, access dates, and review responsibilities
• IP, repository, reusable components, and source handover
• Security, data handling, change control, cancellation, and payment terms

How to write acceptance criteria

Acceptance criteria should describe observable behavior with named test data. Avoid goals such as better accuracy or easier use unless the team agrees how those claims will be measured.

• Input and expected output for each critical test
• Accuracy, latency, completion rate, or user review threshold
• Failure and fallback behavior
• Who accepts the result and by what date

What an LLM or AI PoC must test

An LLM PoC needs more than one successful prompt. It should use a representative evaluation set and make model uncertainty, evidence, human review, logging, and data handling visible.

• Representative cases, edge cases, and unsafe cases
• Grounding, citations, or source evidence where required
• Human approval and correction path
• Model cost, latency, privacy, retention, and failure behavior

What the internal approval pack should contain

The final pack should let a manager, procurement reviewer, or security reviewer understand what worked, what remains risky, and what the next budget would buy.

• Demo link or recording and acceptance summary
• Architecture, data flow, risks, and open decisions
• Source and handover position
• Next-phase scope, estimate, alternatives, and stop option

When not to start a PoC

A PoC is premature when nobody owns the result, representative data cannot be used, the success condition is undefined, or the organisation has already decided to buy a full platform regardless of evidence.

• Start with a readiness audit when the workflow is unclear
• Resolve data access and compliance before building
• Use a free product trial for basic vendor learning
• Move to an MVP only when production use is already approved