A warehouse prototype lets you try a different way to organise the work. You can see whether the next task is obvious, whether the instructions make sense and which steps people no longer need to repeat. If you used AI to build it, establish how the application records and coordinates that work when several people use it over time.

These five tests are for a technical builder who can inspect the application’s requests and stored records, or work with a developer who can. They connect what the operator sees to what the shared system has actually done. The same tests are useful regardless of who wrote the code.

Use a test environment with fictional orders and a simulated carrier connection. Agree the expected behaviour with someone who understands the operation before running each test. Keep the starting records, requests, observed results and expected outcome together. A generated test that asserts the code’s current behaviour will not tell you whether that behaviour fits the business.

1. Another person continues unfinished work

Start a picking task, confirm part of the quantity and save progress. Close the application. Ask another authorised operator to open the job on a different device and continue it using only what the system shows.

They should be able to identify what has been picked, what remains and where the unfinished work is. If the process requires an explicit handover or reassignment, use that route. Inspect the stored quantities and task state as well as the second screen. Refreshing the first device should bring it back to the same shared account of the work.

This test distinguishes a useful continuing process from a screen that remembers what its current user clicked. If the first device shows five picked but the shared record still says zero, another person may repeat completed work. If the record is correct but the second operator cannot identify the picked stock, the implementation still needs a better handover experience.

A pass requires both a consistent record and enough information for the next person to act. Saving a status named “in progress” is not sufficient if it leaves them to reconstruct the job.

2. A confirmation succeeds, but its response is lost

Complete a packing task in the test environment. Let the application save the confirmation, then suppress the response so the client cannot tell that it succeeded. Submit the same confirmation again, using the same request identity.

Inspect the completion record and any downstream effects the design creates, such as stock movements or a carrier booking. The repeated request should resolve to the agreed result without performing the same work again. Merely attaching an identifier is insufficient: the receiving logic must recognise and handle that identity.

Now make the simulated carrier accept a booking but return a timeout. The operator needs to see that packing is complete and the booking result is uncertain, with a defined way to resolve it. The recovery path should check or reconcile the existing request before creating another booking. A genuinely rejected booking may need a retry; an accepted booking whose response was lost needs different handling.

Record what the operator should do next and prove that the recovery path reaches the intended result. An error log alone does not finish the job.

3. Two orders compete for the last unit

Set up one available unit and two distinct orders. For this test, the agreed business rule is that available stock cannot be allocated twice. Send the two allocation requests together, so both have a chance to read the initial availability.

Exactly one order should obtain the unit. Inspect the committed allocations and remaining availability, then check both operators’ screens. The unsuccessful operator needs a clear result and a useful next action, such as leaving the unfulfilled quantity awaiting stock under your chosen process. They should not continue with an allocation that only existed briefly on their screen.

A button disabled on one device cannot coordinate the other device. The authoritative update must enforce the stock rule when requests overlap. If the implementation uses database transactions, identify how its isolation, conditional updates or locking preserve that rule. Different isolation levels permit different concurrent behaviour, so establishing that the system uses transactions is not enough.

Repeat the test with controlled overlapping requests. One successful run does not prove that a race cannot occur. Keep the rule and the concurrency case in the application’s tests after fixing it.

4. A correction is made by the right person, with a reason

Choose a correction that your process reserves for a supervisor, such as amending a confirmed picked quantity. Sign in as an ordinary operator and attempt it through the interface. Then send the underlying request directly using that same operator’s credentials in the test environment.

Both routes must follow the agreed access policy. A hidden button can simplify the screen, but it cannot enforce the action’s permission. OWASP’s authorisation guidance recommends validating permissions on every request.

Next perform the correction as an authorised supervisor. Check that the revised quantity is reflected where it is used and that the original value, the person making the change and the reason remain explainable. If another system already received the earlier quantity, follow the agreed correction route there too.

This test needs a successful authorised path as well as a rejected unauthorised one. Operators need a way to get legitimate mistakes corrected. A system that prevents everyone from acting may pass a narrow denial test while leaving the actual work unresolved.

5. The team changes how it chooses the next job

Try an ordinary operational improvement. Suppose unstarted picking tasks currently appear in the order received, and the team now wants to prioritise the earliest dispatch deadline. In this illustrative policy, tasks already claimed stay with their operators; the new priority applies to work not yet started.

Create tasks whose receipt order differs from their deadline order, including one already claimed. Change the selection rule. Check that the next-task view and any automatic assignment use the new rule for unstarted work, while the claimed task remains available to the person doing it. Agree and test what happens when deadlines tie or are missing.

Sorting a table by deadline can make the screen look right while an assignment action still selects the oldest task. The useful test follows the choice into the task someone receives. It should also show why that task was selected, so a supervisor can understand the queue.

Keep the earlier test cases and add the new policy’s cases. You should be able to explain which behaviour intentionally changed and which remained stable. This is how a prototype starts to demonstrate that it can support improvement without losing work already underway.

Turning the prototype into a working operation with Keel

Keel is an operations platform for shaping the way your team works and giving it a dependable structure. The useful parts of your prototype can inform the task views and the way people continue work in that system. The implementation must connect them to shared progress and rules that hold when another person or application performs the same action.

In the priority example, a workflow on Keel could give operators their next eligible task through an implemented selection action. That action would apply the agreed deadline rule to unstarted work while preserving existing assignments. Changing the policy would change the work people receive, with tests establishing which tasks it affects. This is an implementation example, not a prebuilt picking policy.

Keel supplies permissions on models and actions, flows for human and processing steps, and testing facilities. Your business rules, concurrency design and external-system recovery still need implementation and testing. Our guide to what Keel supplies and what you build explains the boundary.

AI assistance with writing the application does not require a model to make decisions during live warehouse work. If your design includes an AI step in the workflow, its outputs, permissions and recovery behaviour need their own agreed tests. A plausible response is not proof that the resulting operational action is appropriate.

Passing these five tests is a starting point for assessing the application, not a production-readiness certificate. Use what they reveal to scope the next implementation, including who will support the work and maintain its tests. Keel currently leads implementation and agrees a handover with each customer. Discuss your warehouse prototype with Keel, bringing the workflow, an observed test result and the behaviour you want to preserve.