Service

One prototype. One question:
scale it, or stop it.

Proof of concept development as a fixed 3 to 6 week cycle. It ends with a functional prototype, real user feedback, and a written go or no-go recommendation. The price is fixed and agreed before the work starts.

See the proof
One assumption, one decision

One assumption gets named. We agree the pass and fail bar before the build starts.

3-6 weeks
from one assumption to a go or no-go decision
Fixed
price, agreed before the work starts
60,000+
lines of code in one proof of concept we built
Read-only
integration, so your core systems stay safe

01 - The situation

An idea sits in a deck. Nobody proves it or kills it.

You need rapid software prototyping and a clear answer, not a six-month build first.

Where a proof of concept stalls

  • A slide deck cannot prove that an idea works. Only a working system tells you the truth.
  • A full custom build takes months to answer one question.
  • A pilot that touches core systems puts live operations at risk.
  • Nobody agrees a pass or fail bar before the test starts. The result then convinces nobody.

What we do instead

  • We build a working prototype instead of a deck.
  • We name the assumption before the build starts, and test only that.
  • The pilot runs next to your systems, with read-only integration where possible.
  • We agree the pass and fail bar with you before the build starts.

02 - What you get

Three things leave the cycle with you

Not a slide deck and not a rushed pitch. Software prototype development that ends in evidence you can act on.

01

A working prototype, not a mockup

A functional system that real users touch. It runs next to your current systems, safely.

What it is

We take one assumption and build the smallest system that tests it. Where possible, the prototype reads your live data through a read-only integration. Your core systems stay untouched.

Why it matters

You test the real assumption, not a simulation of it. Stakeholders click through a working system, not a set of slides.

02

Evidence from three sources

Usage data, direct user feedback, and a technical feasibility check, collected during the pilot.

What it is

We put the prototype in front of real users and record what they do, not only what they say. In parallel, we test the assumption against real data and real load.

Why it matters

Your decision rests on evidence, not on opinion in a meeting room. The evidence holds up in front of a board.

03

A go or no-go recommendation

A written recommendation, backed by the evidence, plus an architecture document for the case that scales.

What it is

We write the result in plain language: scale it, or stop it. For a go, the architecture document maps the path to production. For a no-go, the reasons stand on their own.

Why it matters

A stakeholder reaches the same conclusion without a walkthrough. A no-go protects the budget for the next idea.

03 - How it runs

One cycle, four steps

Every prototype follows the same structure. The result is a decision, not a demo that fades.

One assumption, one decision

One assumption gets named. We agree the pass and fail bar before the build starts.

Step 1

Name the assumption

We write down the one assumption the prototype must test. We agree the pass and fail bar before the build starts.

Step 2

Build the prototype

One senior team builds a functional system that real users can touch. A demo closes every week.

Step 3

Collect the evidence

Real users test the prototype next to your current systems. We record usage data and direct feedback.

Step 4

Take the decision

We write the go or no-go recommendation. A go case ships with an architecture document for production.

04 - Proof

Where we did this work

One proof of concept that grew into a production pilot, and one specified in full detail for an immediate start.

From email chains to a tamper-evident traceability platform

Circular economy, metal recycling, industrial decommissioning

From email chains to a tamper-evident traceability platform

A small team built a multi-tenant traceability platform for industrial decommissioning in three months, from an empty repository. The platform holds one shared record per project, a custody event for every material hand-off, and an audit trail with a cryptographic chain.

Read the case study
From scattered Excel files to an AI roadmap

Industrial manufacturing and field service

From scattered Excel files to an AI roadmap

A workshop-first engagement gave a European factory network a grounded answer to one question: where does AI pay off? The engagement delivered a prioritized shortlist of use cases, a roadmap ready for stakeholder approval, and one proof of concept specified for immediate implementation.

Read the case study
All case studies

05 - Questions

Common questions

What is proof of concept development?
Proof of concept development tests one technical question: can the idea work at all. Our PoC development services define that one question with you, then build a functional prototype that real users can touch. The prototype is not a slide deck and not a clickable mockup. In 3 to 6 weeks the cycle ends with a demo, real evidence, and a written go or no-go recommendation.
What is the difference between a proof of concept, a prototype, and an MVP?
A proof of concept tests technical feasibility: can this be built at all. A prototype tests the user experience: does it make sense to the people who use it. An MVP tests the market: will people adopt it and pay for it. We wrote a full comparison in our blog post, Proof of Concept vs Prototype vs MVP, and we build all three.
How long does an AI proof of concept take?
The cycle runs 3 to 6 weeks, from the first workshop to the written recommendation. The exact length depends on the data you have and the assumption we test. For one client we specified a proof of concept in enough detail for an immediate start of the build. AI-heavy assumptions, such as model accuracy on your own documents, often need the full 6 weeks.
What is pilot project development, and how is it different from a proof of concept?
Pilot project development takes a prototype that already works and runs it next to your current systems, with real users and real data. A proof of concept tests one assumption, away from daily operations. Where possible, the pilot reads your systems through a read-only integration, so core operations stay safe. We design the migration path only after the pilot proves itself.
What counts as a pass or a fail in a go no-go technical validation?
We agree the pass and fail bar with you before the build starts, not after we see the result. The evidence comes from three sources: usage data, direct user feedback, and a technical feasibility check. A go decision ships with an architecture document for the path to production. A no-go decision is a valid result, and it protects the budget for your next idea.
Do I own the code after a proof of concept?
Yes. The prototype and the code run in your own accounts from the first day. If the decision is a go, that code often becomes the base for the pilot, the way it did for a metal traceability platform we built from an empty repository. If the decision is a no-go, you keep the code, the evidence, and the architecture document.

06 - Related

Other services

Most engagements combine two of these. Start where the risk is highest.

MVP development sprintA fixed-scope sprint of 4 to 6 weeks. It ends with a deployed product, the codebase, and a roadmap.Custom-built AI agentsAgents that take real actions in your product and your operations, under permission controls you select.Custom software and modernizationOne system that replaces the spreadsheets, or a ground-up rebuild of a product you still run.Long-term product partnershipA senior team that builds, operates, and extends your product every month, at fractional cost.AI opportunity workshop and roadmapA workshop with your process owners that shows where AI pays off, and in which order.Agentic development workshopsWe teach your developers to ship production software with AI agents, then guide the first build.Technical due diligenceA review of the code, the architecture, and the team before you invest, delivered as a written report.
This service, written for one audienceFor corporate innovation

Which assumption still waits on a slide?

Book a free scoping session. We define the one assumption that matters, and the smallest prototype that tests it. That holds whether you build it with us or not.

Free scoping sessionISO/IEC 27001:2022 certifiedReply within one business day