The smallest thing that would prove it

A large software proposal can leave its most important question unanswered. The screens look sensible. The feature list covers the work. But can the existing system supply the information the new tool needs? Can staff use the result without checking everything again?

Before asking you to commit to the larger project, we want to identify the smallest working slice that could answer the question most likely to change your decision.

That slice needs a real test. A decorative mockup cannot prove a connection works. An AI demonstration built around carefully chosen easy examples cannot establish how it handles your ordinary requests. A small test should make the difficult assumption visible.

Choose the uncertainty that could stop the project

Start with what must be true for the proposed software to be worth building.

Consider a hypothetical tool that reads incoming order requests and prepares them for staff review. Its appeal depends on several assumptions. The requests must contain enough information. The software must interpret that information correctly. Staff must be able to resolve exceptions without recreating the order by hand.

We would ask which assumption has the weakest evidence and the greatest consequence if wrong. If the order system cannot accept the required fields, testing a polished review screen first leaves the central risk untouched. If the connection is understood but the requests are ambiguous, the reading and review step deserves attention first.

Write the question in terms of work you can observe. For example: can this tool prepare a reviewable order from the requests you actually receive, while clearly leaving unresolved details for staff?

That is narrower than asking whether AI can handle orders. It also gives you a reason to stop if the answer is no.

Build a complete path through that question

For the order example, the working slice might take a sample request, extract the needed fields, and present a proposed order beside the original. A staff member could correct it or return it as incomplete.

The path is small, but the relevant work happens. We can inspect what the software read, what it proposed, and what the reviewer had to change. A screen filled with prepared answers would skip the very step we need to test.

The boundary depends on the uncertainty. If we are testing interpretation, a separate test workspace may be enough. If we are testing whether the order system accepts a change, a pretend connection cannot supply that evidence. We would need an approved test environment or another controlled way to exercise the actual connection.

Any simulated step should be named. It can help contain the experiment, but it cannot count as proof that the corresponding real step works.

Keep the inputs and constraints realistic

Choose samples from the range of work you expect, including the inconvenient parts. An order request might contain an unfamiliar abbreviation, omit a delivery date, or revise a quantity later in the message. Include those patterns when they occur in your work.

We would use approved samples with sensitive details removed, or invented records that preserve the relevant structure. The test does not need unrestricted access to customer records. It does need the ambiguity and variation that affect the result.

Conditions matter too. If staff will review requests on a phone, test that screen on a phone. If the receiving system requires a product code, keep that requirement. If the person reviewing cannot access an attachment, do not quietly give the prototype broader access and call the test successful.

Keep some representative examples aside until the review. Running only the examples used while building can hide how much the software depends on those particular inputs. For an AI step, repeat relevant cases to check whether the result changes in ways the workflow cannot accept.

Decide what counts before looking at the result

We would agree on a short written judgment before the demonstration. For this hypothetical order tool, it could include:

• Required values match the request, with no invented product or delivery details.
• Missing or conflicting information remains visibly unresolved.
• The reviewer can compare the proposal with the source and correct it.
• The prepared order preserves the fields required by the next step.
• Review does not require staff to recreate the work the tool was meant to handle.

These checks need someone who knows the work to judge them. If the goal includes reducing review time, agree on an acceptable limit and compare the test with the current process using comparable requests. A pleasant demonstration is not evidence that the work became easier.

Decide which failures rule out proceeding and which call for a bounded revision. Keep the inputs, outputs, corrections, and judgment together so you can revisit the conclusion. Do not move the pass standard after seeing a disappointing result without recording why the question changed.

Let an unsuccessful test change the plan

A failed test can reveal that the proposed approach depends on something the business cannot provide.

Perhaps the request never contains the product detail staff need. A different model cannot recover information nobody supplied. A clearer intake form may deserve a test before further automation. Perhaps reviewers need so much context that preparing a draft order adds another screen without removing work.

We would separate a fixable defect from a failed assumption. A field mapped incorrectly may justify a correction and another run. Missing information across representative requests may justify narrowing the task or stopping it.

Changing the approach is a useful result when the evidence supports it. Continuing because the prototype already exists is not a reason to commission the full project.

Leave the larger product outside the test

An early slice does not need every report, every integration, a full migration, or the final visual treatment unless one of those is necessary to answer the chosen question. Keep additional feature requests on a separate list.

Small does not mean bypassing protections or treating experimental software as ready for daily operations. Use appropriate access controls for the test and keep consequential actions contained. Reliability under load, recovery, production access, and ongoing support still need their own work before people depend on the system.

When the work is a fit, we build a working prototype before you pay, with no obligation and no money down. You see it before deciding. We want that review to support a specific judgment about your project, with the limits of the evidence clear.

A passing test supports the next decision within its scope. It does not prove the whole system. Before agreeing to the larger build, you should be able to name what worked, what failed, what remains unknown, and why the next step is worth taking.