# AI app builder evaluation worksheet

An editable worksheet from Overskill, reviewed September 9, 2026.
Use one copy per product and the same brief and sample records each time.
These are proposed checks, not completed tests or product ratings.
Every Observed and Status field starts as Not tested.

Source guide: https://www.overskill.com/learn/compare-ai-app-builders

## Record your starting point

- Product / plan:
- Date / tester:
- App name / version / environment:
- Model or mode, if selectable:
- Starting point: blank / named template / existing project:
- Template source and version, if used:
- Device / browser:
- Essential requirements that must pass:
- Follow-up instructions and manual setup:
- Test account labels and roles (no passwords):

Use a disposable app and test accounts you control. Do not put real customer
information, credentials, private sign-in links or payment details in this file.
If a provider requires email verification, use test inboxes you control while
keeping the fictional identity labels below consistent across products.

## Common brief

```text
Build a small client project portal.
Clients sign in, create a request, and see only their own requests.
An administrator sees both clients' requests and changes their status.

Request fields: title, brief, requester, status.
Statuses: Submitted, In review, Completed. Start at Submitted.
Clients cannot change the requester or status.
Check permission for every record read and change, including direct links.
Show empty, loading, validation and save-failure states.
Do not connect payments or send external notifications yet.
Explain required setup and how to test each role.
```

## Fictional identities and records

| Identity | Role | Request title | Exact brief | Initial status |
| --- | --- | --- | --- | --- |
| Maya Chen | Client A | Launch brochure | A two-page brochure for a fictional studio. | Submitted |
| Luis Rivera | Client B | Event poster | A poster for a fictional community event. | Submitted |
| Jordan Blake | Administrator | No client request | Not applicable | Not applicable |

These are test roles to create or assign in your own app. They are not accounts
that exist in Quarry or any other published starter. Record the actual request
identifiers privately so you can check the same records after a restore.

Use Pass only when supported by an observed result, Fail for a mismatch,
Not tested when evidence is missing, and Not applicable with a reason.
A provider's documentation establishes the intended behavior, not your result.

## 1. Create the two requests

Action: sign in as each client and submit the matching request above. Try an
empty required title and a failed save using a supported test method.

Expected: one request per successful submission, exact text, correct requester
and Submitted status. Missing required data is explained. A failed save does
not display a successful submission or leave a partially saved request.

Observed: Not tested
Status: Not tested
Evidence / missing setup / correction:

## 2. Save, return and update status

Action: reload; sign out; return in a new session as each client. Jordan changes
only Maya's request to In review. Reopen both clients' views.

Expected: both original records persist. Maya sees Launch brochure / In review.
Luis sees Event poster / Submitted. Jordan sees both. The briefs and owners
remain unchanged.

Observed: Not tested
Status: Not tested
Evidence / correction:

Baseline A: save this point using the product's documented options.
Record separately what was captured; a code checkpoint may not save customer
records. Overskill's app-version restore is not a customer-record backup. If a
suitable data capture or restore method is unavailable, keep recovery Not tested.

- Code version / capture time:
- Database name / development or production / snapshot time:
- Data snapshot or export method:
- Saved record count / identifiers:
- Baseline capture observed: Not tested
- Baseline capture status: Not tested

## 3. Make the same change

Follow-up prompt for every product:

```text
Add a Priority field to requests: Normal by default, or Urgent.
Only the administrator can change Priority.
Keep the existing request, ownership and status behavior.
```

Action: Jordan sets Luis's request to Urgent. Reload. Repeat checks 1, 2 and 4
in a test copy so additional submissions do not alter your saved Baseline A.

Expected: Luis's priority persists as Urgent, Maya's is Normal, and the original
workflow still works. Clients cannot change Priority. Capture repairs as well
as the final result.

Observed: Not tested
Status: Not tested
Follow-up prompts / repair time / evidence:

## 4. Check access from both clients and while signed out

Action: from Luis's session, try Maya's request in lists, its direct link and
an attempted update. Reverse the clients, then repeat while signed out.
Also try changing requester, status and Priority as a client. Get technical
help to exercise direct requests where hidden controls prevent a UI attempt.

Expected: no other client's private title or brief is exposed, unauthorized
changes are refused, and the saved records remain unchanged. A client still
has their permitted access. Jordan's authorized actions still work.

Observed: Not tested
Status: Not tested
Evidence for lists / direct reads / direct changes / signed out:

## 5. Repeat the journey on a phone

Action: create a sample request, read its status and navigate back using a
small-screen device. Use the same roles and permission rules.

Expected: the form, errors, navigation and saved result are usable; controls
are reachable without horizontal scrolling or hidden required fields.

Observed: Not tested
Status: Not tested
Device / evidence / correction:

## 6. Recover code

Use a separate disposable copy. Start with the Priority change, then follow
the documented method to recover the pre-Priority code version.

Expected: the original interface and workflow return. Record database state
before and after separately; code recovery alone does not establish data
recovery. If the operation restores both, record that declared scope.

- Documentation / selected version / declared scope:
- Records before / after:
- Observed: Not tested
- Status: Not tested
- Evidence / limitations:

## 7. Recover data

Use another disposable copy starting from Baseline A. Change Luis's status
to Completed. Recover the saved Baseline A data through a documented method.
Do not attempt this against real customer data.

Expected: Maya is In review, Luis is Submitted, both exact briefs remain,
and ownership is unchanged. Repeat the two-client checks. Identify whether
the method covers development or production; do not transfer a result from
one environment to the other.

- Database / environment / snapshot time / recovery method:
- Record count and values before / after:
- Observed: Not tested
- Status: Not tested
- Evidence / unavailable recovery method / correction:

## 8. Hand over a running copy

Use a separate copy in your intended destination. Move or recreate the needed
services, load the sample records and repeat the client/admin checks.

Expected: the destination runs with the two correct records and permissions.
The intended maintainer can operate it. A ZIP download or repository link alone
is not a completed handover. Overskill's export ZIP can include app files and
SQL/JSON table data; inspect row counts and export warnings rather than assuming
all records are present. Reconnecting services and running the destination still
need their own evidence.

| Item | Needed action / documented method | Observed | Status |
| --- | --- | --- | --- |
| App code and configuration | | Not tested | Not tested |
| Both records and ownership | | Not tested | Not tested |
| Uploaded files, if added | | Not tested | Not tested |
| Sign-in and account mapping | | Not tested | Not tested |
| Connected services and payments, if added | | Not tested | Not tested |
| Address / domain / hosting | | Not tested | Not tested |
| Client/admin checks at destination | | Not tested | Not tested |

Evidence / maintainer instructions / remaining work:

## 9. Evaluate payments separately

Keep payments out of the common portal build. If they are essential to your
app, use the same payment scenario for every product. This worksheet asks for
eligibility and sandbox evidence, not a real charge. Use provider-supported
test mode only when it is available for your account and its boundaries are
clear. If no safe sandbox is established, leave execution Not tested and record
why. A zero-dollar checkout is not proof of isolation: Overskill's test checkout
uses real purchase and access flows. This sheet does not verify your account's
payment eligibility or enabled features.

| Stage | Expected evidence | Observed | Status |
| --- | --- | --- | --- |
| Eligibility and setup | Exact provider/workflow, eligible plan, authorized account role, verification/setup requirements, preview limitations, and any copy/remix restriction recorded from current documentation. | Not tested | Not tested |
| Supported test mode, if available | In a verified sandbox, successful test checkout, cancellation and failed payment produce the expected access; retries do not grant duplicate access. Test relevant screens outside an embedded preview where required. | Not tested | Not tested |
| Live readiness review | Remaining account, publication and provider steps are recorded. Sandbox results are not labelled live. No live charge is needed for this comparison. | Not tested | Not tested |

Provider / documentation URL / access date:
Plan / account role / required connection:
Payment-enabled copy or remix restrictions:
Supported sandbox and isolation evidence, or reason execution stays Not tested:
Preview or standalone test site:
Expected access after success / cancellation / failure:
Evidence / remaining setup:
Live payment processing: Not tested

## Keep effort and cost separate

Record actual observed usage and its units; leave unknown amounts unmeasured.
Do not compare a one-time build total with somebody else's monthly hosting bill.

| Category | Amount / unit / currency | Period or workload | Evidence |
| --- | --- | --- | --- |
| Build usage | Not measured | | |
| Revisions and repairs | Not measured | | |
| Plan subscription | Not measured | | |
| Hosting and storage | Not measured | | |
| Connected services | Not measured | | |
| Payment fees, if applicable | Not measured | | |
| Your setup and repair time | Not measured | | |

## Decision notes

- Essential checks passed with evidence:
- Failures and untested requirements that block use:
- Required manual setup / maintainer:
- Next correction and retest:
- Which starting-point differences affected the result:
- Why this product fits or does not fit your actual task:

Do not calculate an automatic winner from this sheet. Keep missing evidence
visible, especially for privacy, recovery and payments.

Portal guide: https://www.overskill.com/learn/build-a-client-portal
Adapt your brief: https://www.overskill.com/learn#brief-builder
Launch checklist: https://www.overskill.com/learn/ai-app-launch-checklist
Booking is a separate track: https://www.overskill.com/learn/build-a-service-booking-app