Deeptech Commercialization: Seven Software Milestones Before a Customer Pilot
Plan a deeptech customer pilot through seven software milestones for users, evidence, workflows, integration, support, deployment and commercial learning.
Sep 17, 2026
A deeptech customer pilot needs 7 software milestones: buyer, evidence, workflow, interface, deployment, acceptance, and commercial learning.
The core technology may already work in a lab, test rig, controlled dataset, or engineering environment. That does not prove a customer can use it inside a real operation. The first software release should bridge that gap without turning the pilot into a second research programme or a broad product build.
This playbook is for a deeptech founder preparing a design-partner or paid customer pilot. It helps the team choose the smallest customer-facing software layer that can collect inputs, guide work, expose results, preserve evidence, handle exceptions, and show what deserves funding next. It does not cover patents, fundraising, scientific validation, or regulatory approval.
KUMO offers a free Kumo Build Readiness Review for founders who need to define that boundary. Map my first milestone around one customer, one operating workflow, and one testable release decision.
Commercialization requires more than technology readiness
Technology readiness and customer readiness answer different questions. NASA's technology readiness level framework describes maturity from basic principles through an actual system proven in an operational environment. The framework is useful because it forces evidence at each stage. It does not, by itself, specify the software a customer needs to configure, use, observe, support, or buy the product.
The European Innovation Council's Transition programme explicitly combines technology maturation with business and market readiness. Its emphasis supports a practical rule: the customer pilot should prove both that the core technology performs and that a buyer can operate the surrounding product in a defined context.
India's National Deep Tech Startup Policy framework describes deeptech ventures as science and engineering led, with long development cycles, technical uncertainty, and substantial capital needs. That makes software scope discipline more important, not less. Every unnecessary dashboard, integration, role, or workflow consumes time and money that should be tied to a commercial question.
| Evidence layer | Question it must answer | Typical owner |
|---|---|---|
| Core technology | Does the scientific or engineering mechanism perform within stated conditions? | Scientific or engineering lead |
| Customer workflow | Can the intended user complete the target job with the technology inside the process? | Product and customer owner |
| Operating system | Can the team deploy, observe, support, recover, and change the release? | Delivery and operations owner |
| Commercial learning | Did the pilot prove enough value and fit to justify the next commitment? | Founder and buyer sponsor |
A customer pilot fails when these layers are blurred. A scientific improvement is not automatically a better user workflow. A polished interface is not proof of core performance. A successful demo is not evidence that the team can support the system in the customer's environment.
Milestone 1: name the buyer and the operational decision
Start with the person who can approve the pilot and the person who will use or operate the product. They may be different. Write the exact business decision the pilot must inform, such as whether a quality team can inspect a new material faster, whether a field operator can act on sensor output, or whether a clinical research team can review evidence with less manual coordination.
The US National Science Foundation's I-Corps programme centres experiential customer discovery for researchers and engineers. The useful lesson is not to treat one enthusiastic conversation as validation. Record the user's current process, alternatives, constraints, buying authority, evidence standard, and reason to change.
Use the prototype versus MVP funding guide when the team is still deciding whether it needs learning artefacts or an operational release. For this pilot, every feature must connect to the named buyer decision.
Milestone 2: define the evidence boundary
State what the core technology already proves, what remains uncertain, and what the software must capture without altering the underlying test. Include inputs, versions, operating conditions, outputs, confidence or tolerance where relevant, manual interventions, and known failure states.
The software should preserve traceability from an observed result back to the source input, technology version, configuration, operator, time, and environment. It should not present a result with more certainty than the core evidence supports. If a domain expert must review or interpret output, make that handoff visible.
The NIST AI Risk Management Framework is specific to AI risk, but its emphasis on governing, mapping, measuring, and managing risk is useful for deeptech products that include AI. Apply it only where AI changes the product's decisions or risks. Do not label a conventional calculation or rules engine as AI for marketing effect.
Milestone 3: map one end-to-end customer workflow
Follow one real case from intake to outcome. Include normal work, missing or invalid inputs, an ambiguous result, a technology failure, a user correction, and an escalation. Name every person and system involved.
The workflow must show where the customer begins, what they provide, what the product does, what evidence appears, who decides, and what record remains. Avoid building a generic platform shell before this sequence is clear. A focused web interface, operator app, connected dashboard, or secure review queue may be enough.
The software milestone acceptance tests help turn a demo into inspectable release evidence. For a deeptech pilot, acceptance must include both software behaviour and the conditions under which the core result is valid.
Milestone 4: choose the minimum interface and integrations
List the data that must enter the pilot, where it comes from, how it is validated, and what may be written back. Then identify which integrations are essential for the buyer decision. A CSV import, secure upload, or controlled manual handoff can be better than a production integration when the pilot is still testing value and workflow fit.
Integrate early only when a manual bridge would invalidate the test, create unacceptable risk, or make the intended user experience impossible. Define authentication, roles, data retention, failed transfers, retries, duplicate handling, and a way to reconcile records.
The first interface should make important states clear. Show when data is incomplete, processing is pending, a result needs review, an action failed, or a human must intervene. Do not hide uncertainty behind a polished dashboard.
Milestone 5: make deployment and support part of the product
A customer pilot needs a named environment, access boundary, release process, monitoring plan, support channel, backup or recovery approach, and accountable owner. The right choices depend on the technology and the customer's constraints. Some pilots can run in a managed cloud environment. Others need a private network, edge device, site installation, or controlled data transfer.
Document what KUMO, the founder's technical team, and the customer each operate. Include hardware or device dependencies where relevant. Define what happens when connectivity drops, a component is unavailable, a configuration changes, or output falls outside a usable range.
The software technical due diligence guide shows how ownership evidence, system boundaries, dependencies, access, recovery, and change control affect a software asset. The same evidence matters before a deeptech pilot becomes a repeatable product.
| Pilot area | Minimum evidence before customer use | Stop condition |
|---|---|---|
| Access | Named users, roles, revocation path, sensitive-data boundary | Uncontrolled access or shared credentials |
| Data | Input definition, validation, retention, deletion, traceability | Results cannot be traced to source inputs |
| Core connection | Version, configuration, timeout and failure behaviour | Software masks a failed or uncertain core result |
| Operations | Release record, monitoring, support owner, recovery step | No one can detect or own a pilot failure |
| Customer handoff | User guidance, escalation, decision boundary | User cannot tell when expert review is required |
Milestone 6: agree the pilot acceptance packet
Define acceptance before development starts. The packet should be small enough for the buyer sponsor to inspect and detailed enough for the delivery team to reproduce.
Separate pass criteria from learning criteria. A pass criterion protects the customer or establishes minimum utility. A learning criterion helps decide what to improve next. For example, source traceability may be mandatory, while the preferred arrangement of an operator screen may remain a learning question.
Innovate UK's guidance for applicants asks applicants to address eligibility, scope, finances, delivery, and evidence through a structured process. A customer pilot needs the same discipline in a smaller form: a clear scope, named outcomes, delivery ownership, and evidence that supports the next decision.
| Acceptance item | What the packet should contain | Decision enabled |
|---|---|---|
| Core result | Agreed cases, conditions, tolerances, exceptions, version record | Is the technology usable in this context? |
| User workflow | Task completion, corrections, handoffs, escalation evidence | Can the intended team operate it? |
| Software reliability | Failure cases, logs, recovery, unresolved defects | Can the pilot run without hidden support? |
| Security and data | Access review, source traceability, retention and deletion proof | Can the customer accept the operating boundary? |
| Commercial learning | Sponsor feedback, measured value, adoption barriers, next commitment | Stop, repeat, narrow, or fund the next release? |
The MVP product analytics plan can help define a small set of events before release. Track actions that explain whether the workflow worked, not vanity activity. Pair usage evidence with interviews and operating observations.
Milestone 7: decide what the pilot unlocks
Set the decision meeting and required evidence before the pilot begins. The result should be one of four honest outcomes: stop, repeat the pilot with a corrected hypothesis, narrow the target workflow, or fund the next release.
The EIC Accelerator programme focuses on innovations with scale-up potential and significant market impact. Scale belongs after a team can explain what one customer deployment proved, which parts can repeat, and which dependencies still require bespoke work.
A strong next milestone removes one constraint. It may harden a deployment path, connect one system, support another user role, add a production control, or make onboarding repeatable. It should not absorb every request from the pilot customer.
When comparing delivery proposals, use the software proposal comparison guide to inspect exclusions, acceptance, ownership, support, and change control. Deeptech founders should keep core scientific ownership explicit while requiring clear ownership of the surrounding product software.
Build the smallest credible customer-pilot release
A useful pilot release connects the core technology to one customer's real job, preserves the evidence boundary, exposes uncertainty, survives expected failures, and produces a decision about the next commitment. That is enough. A broad platform can wait.
The KUMO Equipp case study is relevant because the product connects identity, assets, orders, delivery, and finance into one operating chain. It is evidence of connected software delivery, not proof that a deeptech pilot needs the same architecture.
KUMO works with founders on bounded product milestones through its Founders Partnership. The free Kumo Build Readiness Review helps separate core technology work from the software needed for one customer deployment. Map my first milestone.
FAQs
What software does a deeptech startup need before a customer pilot?
It needs only the software required to run one customer workflow, preserve source and result evidence, handle access and exceptions, support the deployment, and measure whether the buyer's decision was resolved. That may be a focused web app, operator interface, secure review queue, connected dashboard, or a small combination.
How is a deeptech customer pilot different from an MVP?
An MVP tests whether a small product delivers enough value to learn and continue. A deeptech customer pilot must also protect the boundary between core technical evidence and the surrounding user, operating, and commercial evidence. Scientific performance and product usability should be accepted separately.
Should the first pilot include customer-system integrations?
Only when the integration is essential to the workflow, evidence, safety, or buyer decision. A controlled import or manual bridge can be appropriate when it does not distort the test. Any integration that is included needs ownership, validation, failure handling, reconciliation, and access controls.
What should a deeptech founder measure during the pilot?
Measure core performance under stated conditions, completion of the target customer task, corrections and exceptions, support effort, reliability, user adoption, evidence traceability, and the buyer sponsor's next commitment. Do not use page views or demo enthusiasm as proof of commercial readiness.
How can KUMO help a deeptech founder prepare the first customer deployment?
KUMO can help map the customer workflow, define the software boundary, build the interface and integrations, prepare deployment and support controls, and bind the milestone to acceptance evidence. The free Kumo Build Readiness Review is the starting point for choosing that first bounded release.
