A Practical Acceptance-Test Contract for AI-Built CRUD Apps

AI can produce a convincing interface before it has proved that the underlying workflow works. A better starting point is a small acceptance-test contract: a list of observable behaviors that must remain true before you call the project useful.

This is not a demand for exhaustive quality assurance. It is a way to turn an idea into one complete, inspectable path.

Example: a customer-inquiry tracker

Suppose a small business needs to collect and manage customer inquiries. The first version only needs four fields:

• customer name
• phone number
• message
• status: New, In Progress, or Done

Before asking an AI developer to build anything, define the contract.

1. State the happy path

A complete inquiry should save successfully and appear in the list with the expected values.

Input	Action	Expected result
Name, phone, and message	Submit the form	One new inquiry appears with status New
Existing inquiry	Change status to In Progress	The visible status changes once
Updated inquiry	Refresh or reopen	The updated status remains

This is stronger than “make the form work” because every step can be observed.

2. Define one recoverable failure

An incomplete form should not silently save bad data or fail without explanation.

For example:

1. Leave the customer name empty.
2. Submit the form.
3. Confirm that no inquiry is created.
4. Show a clear message identifying the missing information.
5. Preserve the other values so the user can correct the form without starting again.

The goal is not simply to produce an error. The user must be able to recover.

3. Check persistence, not just appearance

A preview can look correct while its state exists only in memory. Refreshing or reopening the project is a cheap test that separates a temporary demonstration from a usable workflow.

After saving an inquiry:

• refresh the page;
• reopen the relevant view;
• confirm that the record still exists;
• confirm that the current status remains correct.

Before using real customer information, also verify who can view the records and where they are stored.

4. Test the transition, not only the final label

A status selector can display “Done” even when no update was persisted. Test the transition as an event:

• start with New;
• change to In Progress;
• refresh and confirm;
• change to Done;
• refresh and confirm again.

If the product will support multiple users, permissions and tenant separation require their own evidence. Do not assume this small contract proves them.

5. Ask for the evidence with the build

A useful build request can include both the outcome and its proof conditions:

Build a customer-inquiry tracker with name, phone number, message, and status. Add one sample inquiry. Test one complete submission, show a clear recoverable error for missing required information, confirm saved data remains after refresh, and show the working preview. Report which checks passed and what remains unverified.

That final sentence matters. A failed check is useful information; hiding it behind a polished preview is not.

What to continue after the first contract passes

Once the basic path works, continue the same project with one justified improvement:

• search or filter inquiries;
• assign an owner;
• record status history;
• export selected records;
• add authentication and test its access rules.

Each improvement should add its own acceptance condition. This keeps the project understandable and prevents “more features” from replacing evidence.

A compact definition of done

For a small AI-built workflow, my minimum definition is:

1. valid input succeeds;
2. invalid input fails clearly and recoverably;
3. important state survives refresh;
4. the delivered preview demonstrates the real path;
5. the builder states what was not verified.

This does not prove production readiness, security, scalability, or regulatory compliance. It proves one useful journey and creates a stable base for the next change.

---

Founder disclosure: I build Admas, an AI developer workspace. The acceptance contract above is a practical planning example, not a report of a completed Admas build. Use it to define a useful first result and the evidence needed before adding more scope.