MVP development

For each deferred capability, define the observation that would make it worth reconsidering. Multiple locations might become necessary when a real booking cannot be fulfilled correctly across locations, rather than when a competitor adds a map. Record abandoned requests, corrections, support questions and successful completion using appropriate privacy controls. Review these alongside short conversations with users; a count alone may not explain the reason. Before release, test a completed request, a declined request and a cancellation, including the staff steps. The MVP is ready to teach you something when the full promise works and the team can tell where it did not.

For a prototype, ask a participant to correct an extracted quantity without coaching and explain what they expect the next action to do. Observe misunderstandings rather than measuring how enthusiastically they praise the design. For a proof of concept, define the labelled documents, the fields being evaluated and the unacceptable error classes before running the experiment. For an MVP, follow a permitted user through the actual document-to-stock workflow, including the review queue and a failed update. These are three different acceptance tests. Keeping them separate prevents a success in one area from being used as a blanket claim of readiness.

For each dependency, record what is needed, who supplies it, when it must arrive and what evidence counts as ready. “API access” may mean a login, permission to use a test organisation, approved network access and sample error cases. Avoid treating the first email containing credentials as completion of all four. Assign the dependency to a person who can obtain it, not merely the developer waiting for it. Review changes to the register with the forecast so delays become visible before a date is missed. This is particularly important when a founder is coordinating vendors for the first time.