From prototype to a product customers can run

The engineering questions behind a financing round change as a company moves from a first demonstration to repeated customer deployments.

Company building3 min read

Industrial camera and calibration target. Illustration.

The first prototype usually receives unusually good care. Its developers know the inputs, understand its failures and can intervene before a demonstration stops. A customer will eventually ask the product to work without that attention. The distance between those two conditions deserves as much scrutiny as the original invention.

Seed, Series A and Series B describe financing stages rather than engineering standards. Judging technical maturity requires a closer look at the product: what has been demonstrated, what customers can operate and what the company can deliver again at a manageable cost.

What did the prototype establish?

A claim of faster processing needs a task, a comparison and a measurement boundary. For document software, the relevant interval might begin when a file arrives and end when an approved result reaches the customer's system. Timing a model call would describe only one part of that work. Human review, input preparation and corrections can determine whether the application saves time at all.

Preserve the test inputs, configuration and software version. Report unsuccessful runs and any manual intervention alongside the result. The next engineer should be able to reproduce the method and investigate a different outcome. At an early stage, this record can be more informative than a large test suite built around easy cases.

A monochrome photograph of an operator at a console, facing a curved wall of instruments. — Engine Research Building control room, NASA Lewis Research Center, 1968.NASA Glenn Research Center (opens in a new tab) · Public domain (opens in a new tab)

The first customer changes the test

Real installations introduce permissions, incomplete records, different network conditions and established working habits. A pilot needs acceptance criteria agreed with the person responsible for the business task. That person may have a different objective from the sponsor who invited the startup to demonstrate its technology.

Record the hours required for installation, data preparation and support. Note which exceptions a customer can resolve and which require the founding team to intervene. Custom engineering may be justified by a valuable contract, but its obligations belong in the delivery plan and gross margin assumptions, including during a pilot.

A second installation is a different milestone

The next deployment reveals which parts of the first were reusable. Compare customers with similar requirements, including the time to install, frequency of failures and effort required to recover. If each installation needs a new integration or expert operator, revenue growth may increase demand for scarce engineering time before it creates operating efficiency.

Service measures should follow the customer's task. Google's Site Reliability Workbook recommends defining service level objectives around user experience. A server can answer health checks while document processing has stopped. Completion rate, freshness of data or time to a usable result can expose failures that infrastructure availability conceals.

Orange KUKA industrial robots surround unfinished silver car bodies on an automotive assembly line. — KUKA robots on BMW's 3 Series assembly line, Leipzig, 2005.BMW Werk Leipzig (opens in a new tab) · CC BY-SA 2.0 DE (opens in a new tab)

Customers also buy the ability to change

A working release will need updates. Technical diligence should include who approves changes, how a failed deployment is contained and whether the team has practised recovery. An architecture overview, important dependencies and test results tied to a specific release provide evidence for that assessment.

NIST's Secure Software Development Framework provides a vocabulary for development and vulnerability response. Its practices can be incorporated into different development lifecycles. Adopting the vocabulary alone gives a buyer or investor no assurance about a supplier. They need evidence of how the team applies the practices, with scrutiny proportionate to the consequences of failure.

Keep engineering and commercial maturity separate

NASA's technology readiness levels distinguish early research from testing in progressively more relevant environments. They help explain why a component demonstration differs from a working system. They were developed for a particular technical context, however, and no readiness level automatically corresponds to a financing round.

An Artemis II crew member in protective clothing climbs out of the Orion capsule in a spacecraft testing facility. — Artemis II crew member exiting Orion during ground testing, Kennedy Space Center, 2023.NASA / Kim Shiflett (opens in a new tab) · NASA media usage guidelines (opens in a new tab)

A reliable product can still lack customer demand, a viable delivery model or a route through procurement. Keep those questions beside the engineering record. For the next investment decision, identify the unresolved dependency that could most change the company's schedule or cash needs, and fund a test capable of resolving it.