Implementation worksheet · 5 min read
A Code Export Acceptance Test for AI App Builders
An export passes acceptance when a developer who has never seen the project can clone it, install dependencies from the lockfile, build without errors, run it locally against their own database, and deploy it somewhere the vendor doesn't control — inside one working day. Anything less is a code viewer wearing an ownership claim.
Every builder says some version of 'your code is yours'. The claims differ wildly in practice: read-only viewers, export-on-paid-tiers, GitHub sync, or full repo control. The test below converts the claim into evidence before you've bet a client relationship on it.
Put it into practice
1. Export at your real tier
Run the export exactly as your plan allows — viewer, download, or repo sync. Note what the tier gates: on Greta, for example, the code viewer is on every plan, direct editing starts at Starter, and GitHub sync is a Pro feature; verify the current matrix on the pricing page before testing.
2. Fresh-machine install
Clone to a machine (or container) that has never seen the project. Install from the lockfile only. Record every manual step the README didn't mention — each one is a point off.
3. Build and run locally
Point the app at a database you provisioned. Secrets go in your env files. If the app phones home to the vendor to boot, write that down — it's the finding.
4. Deploy off-platform
Push to any host the vendor doesn't run. It doesn't need to be production-grade; it needs to prove the app runs where the vendor isn't.
5. Diff a regenerated feature
Make one small change through the builder, re-export, and diff. You're checking the export is the live artifact, not a stale snapshot.
Export acceptance record
Copy this structure into your review document and record your observed result for each row.
| Check | Expected | Observed | Pass |
|---|---|---|---|
| Clone + lockfile install | no undocumented steps | ||
| Local build | zero errors | ||
| Run vs own database | boots and serves | ||
| Off-platform deploy | serves from foreign host | ||
| Re-export diff | matches builder state |
A failure worth checking
The demo-repo failure: testing export on the vendor's polished sample project instead of your own build. Sample repos are curated to pass. The only export that matters is the app you actually made, mess included.
Common questions
Is GitHub sync the same as code ownership?
It's the strongest common form — continuous, diffable, and off the vendor's servers. But run the acceptance test anyway: a synced repo that won't build without the vendor's runtime still fails step four.
What's a reasonable time budget for the test?
One developer-day. If a competent developer can't get an exported app running independently in a day, the export exists but the ownership practically doesn't.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.