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

Admas — Tue, 29 Sep 2026 22:26:46 +0000

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:

Leave the customer name empty.
Submit the form.
Confirm that no inquiry is created.
Show a clear message identifying the missing information.
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:

valid input succeeds;
invalid input fails clearly and recoverably;
important state survives refresh;
the delivered preview demonstrates the real path;
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.

AI Generated the App. How Do You Know It Actually Works?

Admas — Mon, 28 Sep 2026 14:15:32 +0000

Generating code is no longer the difficult part.

The harder question is: who verified the behavior of the application after the code was written?

A successful build proves that the project compiled or bundled. It does not prove that:

A user can complete the main workflow.
Invalid input is rejected correctly.
Saved data survives a refresh.
Unauthorized users cannot access protected actions.
The preview matches the current code.
A later change did not break something that previously worked.

For an AI-built application, I believe “done” should require observable evidence from the running product.

A simple verification standard can begin with four checks:

1. Test the successful path

Complete the action exactly as a real user would.

If it is a booking application, create a booking and verify that it appears in the owner dashboard.

2. Test the failure path

Submit invalid information or attempt an action that should be rejected.

A working success screen means little if the application accepts impossible dates, duplicate reservations, or malformed data.

3. Test persistence

Refresh or reopen the application.

If the data disappears, the interface may look complete while the actual product is not.

4. Test a boundary

Attempt one action the current user should not be allowed to perform.

Authentication is not the same as authorization. A user being signed in does not mean every record or action should be accessible.

This verification loop is central to what we are building at Admas: https://www.admas.dev

Admas works inside the project through planning, editing, running, testing, repairing, and previewing—not merely generating files and declaring completion.

The larger principle applies to every AI software-development tool:

Don’t ask only, “Did the agent write the code?”

Ask, “Can I reproduce both success and failure in the running application?”

What evidence do you require before trusting an AI-generated application: a successful build, automated tests, a working preview, or something else?

Disclosure: I’m part of the team building Admas.

DEV Community: Admas