User guide · a screenshot at every step
Full user guide
From a one-paragraph idea to a working app: what you do at each step, what the system does for you, and where AI helps.
- You what you decide or press
- AI helps steps that call AI
- No AI the system does it all itself
Start here: get to know AppForge before you sign up
You can look around without signing up, and nothing in this part calls AI.
Home page
YouNo AIThe AppForge home page What you do
- Read what AppForge does, then press “Start building free” or “See how it works”.
What the system does
- Shows the overview: idea → several AI designers at once → build the app.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: The top menu leads to Showcase · Integrations (kits) · Guide · ROI · Try it first · Partners.
Try it first, without signing up
YouNo AILook at the showcase before you sign up What you do
- Type an idea to see an example, or pick a finished design to look at.
What the system does
- Opens a prepared example. It does not create a new project.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: Good for showing customers the result before they decide to sign up.
Showcase
YouNo AIThe Showcase page on the live system: 14 real apps their owners chose to show What you do
- Look at real apps built with AppForge that their owners chose to show.
- Press “Open the live app” or Remix to copy the design into a project of your own.
What the system does
- Remix copies the design into a new project right away.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: Remix does not call AI, so copying costs no credits.
Integrations (the kit library)
YouNo AIThe kit library, with more than 80 ready-to-use capabilities, searchable and filterable by category What you do
- Search and browse ready-made capabilities you can add to an app, such as payments, maps, chat and notifications.
What the system does
- More than 80 kits are ready to use, and 3 more come with every app (admin · login · multi-language).
Where AI helps
This step does not call AI. The system does it all itself.
Tip: A kit is tested code. Add it and you get the screens and API at once, without asking AI to write them again.
Sign up / sign in
YouNo AISign up with email, or sign in with a passkey What you do
- Sign up with email, or sign in with Google · LINE · GitHub · passkey (Face ID / Touch ID).
What the system does
- A new account gets starting credits to try things out.
Where AI helps
This step does not call AI. The system does it all itself.
Build an app, step by step
The main path from idea to app. Along the way the system stops at a “gate” so you can check and approve. The screenshots in this part come from the demo project “Kind Clinic”, filled with every state.
Your project dashboard
YouNo AIAll projects, and the “Waiting for you” box What you do
- See all your projects, open one, or press “New project”.
- The “Waiting for you” box lists the projects that need your decision.
What the system does
- Each card shows its status, with buttons to edit and publish to the Showcase.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: “Add an existing app” registers an app that was not built with AppForge.
1. Tell your idea
YouAI helpsA few secondsThe idea box, examples under it, and settings: style · detail · build budget What you do
- Type one paragraph about your idea, or press an example under the box.
- Start from a template · attach an existing document (such as a BRS) · or start from a website you like.
- Settings: website style (10 styles) · approval detail · build budget.
What the system does
- Reads the document or website you attached (no AI).
- Creates the project and starts the workflow.
Where AI helps
Optional: “Plan First” lets AI briefly interview you before the idea goes to the design rooms (there is a fallback if AI does not answer).
Tip: Quick approval = stops for you to check at 3 points: after requirements · after design · after QA. Deep = stops at every step. The “scaffold only” budget = AppForge designs and lays out the skeleton, and you write the rest with your own AI.
The project's workflow page
YouNo AIThe workflow page: the 5-step bar on top, the project menu, and the QA summary What you do
- See which step you are on (design → review → build → polish → publish).
- The project menu: Changes · Studio · API spec · Usage · Images · ROI · Share.
What the system does
- Project QA summary: estimated and actual time, finished steps, files produced, readiness to go live, and what to do next.
Where AI helps
This step does not call AI. The system does it all itself.
2. Requirements
YouAI helpsAbout 1 minuteThe “Waiting for your approval” box and the requirement brief AI expanded What you do
- Read the user groups and the feature list you got.
- Ask for a redo with a changed prompt, or cut scope you do not want, then press “Approve and continue”.
What the system does
- Stops and waits for you before design begins (in both Quick and Deep).
Where AI helps
AI expands the idea into a requirements document (the main model for this job: Claude Opus 5.5).
Tip: Designing costs no credits. The system charges credits when you press “Approve & start build” at the gate before building (step 4), at the price you see in the quote.
3. Design with 6 AI rooms at once
YouAI helpsAbout 3–4 minutesThe design rooms: 6 rooms work at once, then merge into one design (shown at the start, every room queued) Progress in the workflow: requirements done, design in progress What you do
- Watch each room's progress live.
- If a room fails, redo only the failed room.
What the system does
- Sends one brief to 6 rooms: Claude · ChatGPT · Gemini · Grok · Perplexity · Qwen (a backup model steps in if a room fails).
- Merges all the results into one design document.
Where AI helps
This whole step is AI's work: each room thinks from a different angle (screens and usage · architecture · database · API · mobile · security), then another AI merges them.
Tip: A real example: MindDNA got 8 screens, 9 tables and 8 APIs, with the risks to watch for, before a single line of code was written.
4. The gate before building: check the design
YouNo AIThe gate before building: choose a budget level, then press “Approve & start build” ClinicAi design summary: 14 screens, 23 tables, 23 APIs and time saved What you do
- Read the design summary: screens, tables, APIs, time saved compared with a human team, executive summary, tech stack, plan, risks.
- Pick a budget level (scaffold · economy · balanced · premium), then press “Approve & start build”. This is when the system charges credits.
What the system does
- Tabs Prompt/Brief · Agent Council · Model Compare · Style Tokens let you look back at where things came from.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: Before you press build, we suggest opening the “API spec” menu and making the form first (step 5). The more the compiler can write, the less AI has to write, and the lower the price.
Readiness before building, and style
YouAI helpsThe readiness score before building, and what to fix first Style proposals from AI, and brand templates What you do
- See the readiness score (clarity of requirements · screens · data/API · security · design · evidence from the design rooms) and what should be fixed.
- Pick a screen style from the proposals, or from a brand template (73 styles).
What the system does
- Checks readiness from the design (no AI).
Where AI helps
The 3 style proposals come from the design AI already made (no extra AI call).
Brand images, and ask 2 models before deciding
YouAI helpsBrand images, and Model Duel: ask 2 models before deciding What you do
- Upload a logo and a home-page image, or press “Create with AI”.
- Model Duel: pick 2 models and ask both the same question to compare answers before you decide.
Where AI helps
AI creates the images (OpenAI) · Model Duel calls 2 models. Both are optional.
Platform, app shell and kits
YouNo AIChoose the platform and the App Shell The kit market by category What you do
- Pick the platform (web · mobile · both) and the app shell (5 kinds of App Shell).
- Add more kits from the kit market, by category.
What the system does
- Recommends kits from words in the design (no AI) · the first 2 kits are included in the base price.
Where AI helps
This step does not call AI. The system does it all itself.
Estimate the AI cost, then press build
YouNo AIEstimate the AI cost before you press build What you do
- See the estimated AI cost, then press “Approve & start build”.
What the system does
- Build price = base price + kit price + AI cost for the part that cannot be compiled.
- The system charges credits when you press this button, at the same price you see. If you do not have enough credits, it takes you to top up first.
Where AI helps
This step does not call AI. The system does it all itself.
5. The API spec form (the heart of 6GL)
YouAI helpsUnder half a minuteA draft API spec form: how many items can be compiled, and what you need to decide What you do
- Press “Generate the form”, then read the summary of how many endpoints and screens can be compiled.
- Answer only what the system asks in the “You need to decide” box.
What the system does
- The system arranges things itself first, then asks AI to help only where it is unsure.
- Checks completeness before you can approve (no AI).
Where AI helps
AI classifies once (a low-cost model, with no random variation in its answers).
Tip: This form is the “blueprint” a person approves, and then the compiler reads it. What can be compiled does not need AI to write it.
Tables (Entity) and permissions
YouNo AIPermissions for each table: view · create · edit · delete, and who sees the data What you do
- Choose what each table can do (view · create · edit · delete) and who sees the data: owner · role · public.
What the system does
- Enforces the permissions for real in the app that is built.
Where AI helps
This step does not call AI. The system does it all itself.
Endpoints: who does each API
YouNo AIEach endpoint and the kind it was given (CRUD · Query · custom …) What you do
- See which kind each API is, and change it if it is wrong.
What the system does
- The kinds the compiler can write itself: crud · query · aggregate · summary · document.
- kit = a kit does it · platform = already comes with the app · custom = AI's job at build time.
Where AI helps
This step does not call AI. The system does it all itself.
Screens: screen recipes, and kits that can do them instead
YouAI helpsEach screen, the recipe it uses, and the kit that can do it instead What you do
- See which recipe each screen uses, or whether a kit does it instead, and change it.
What the system does
- There are 50 screen recipes, such as table, form, calendar, report, dashboard.
Where AI helps
The “Words on screen” button writes the Thai and Chinese words for every page (1 AI call).
Landing page, scheduled jobs and notifications
YouNo AILanding page templates, and scheduled jobs with notifications What you do
- Choose a landing page template (or let AI choose when building).
- Set scheduled jobs (Thai time), such as a daily morning summary, and press “Add a notification” for when a number reaches a threshold.
- Press “Save”, then “Approve”.
What the system does
- Scheduled jobs use the Scheduler kit · notify by email, LINE or webhook.
Where AI helps
This step does not call AI. The system does it all itself.
6. Approve the form → the “Ready to build” card
YouNo AIOne clickThe approved form The “Ready to build” card: 4 price levels, and the guide to the remaining work What you do
- See the 4 prices on the card (scaffold · economy · balanced · premium), then go back and press approve at the gate before building.
- Download the guide to the remaining work (.md), for the scaffold budget where you write the rest yourself.
What the system does
- The next build compiles from this form. What cannot be compiled is AI's job.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: The remaining AI cost is charged by the number of items AI still has to write, and never exceeds the price without a form. The real price is on this card.
7. Build the app: backend → frontend → UX/UI → QA → deploy
YouAI helpsAbout 15 minutesProgress while building What you do
- Watch the progress of each step · in Quick mode it stops for another approval after QA.
What the system does
- The compiler writes everything in the form without AI: tables, APIs, screens, dashboards, CSV/Excel export, Thai documents, scheduled jobs.
- The deploy step: lays out the app, logo, landing page, README, and pushes to GitHub (if set up).
Where AI helps
AI writes only the items that cannot be compiled (developer · UX · QA, depending on the chosen budget) · writes the landing-page text and chooses the template · writes the README.
Tip: The scaffold budget skips AI entirely (the compiler still works) · the landing page does not make up reviews, so the app owner can add real ones.
8. Build finished
YouNo AIBuild finished: time, number of screens, endpoints, tables, and credits used Publish button, push to GitHub, and download the code What you do
- Press “Publish & get a live link” · push to GitHub again · download the skeleton .zip.
What the system does
- Shows the time taken, the number of screens, endpoints and tables, and the credits used.
- Keeps the result of every step so you can look back.
Where AI helps
This step does not call AI. The system does it all itself.
9. Preview, publish and go live
YouNo AIPreview about 2–3 minutesThe live preview page: start preview, publish, mobile preview, deploy Publishing an app on the live system What you do
- Press “Start preview” and try the real app · view it on a phone with the QR code.
- Press “Publish” · add it to the Showcase (choose the audience: everyone, or an email list).
What the system does
- Runs the app on the preview machine so you can try it.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: The right-hand image is from a real publish on the live system.
Go live: domain, login and Jarvis
YouNo AIGo live · your domain · DNAfinity ID · Jarvis What you do
- Download the deploy kit (.zip) or use managed deploy · add your own domain.
- Turn on “Sign in with DNAfinity ID” for the app · create a Jarvis key (paid with AppForge credits).
What the system does
- Keeps version history so you can roll back.
Where AI helps
This step does not call AI. The system does it all itself.
Polish with AI, and Gap Analysis
YouAI helpsPolish with AI, and Gap Analysis What you do
- Type what you want changed, for example “make the hero bigger” · press “Run Gap Analysis” to find gaps before launch.
What the system does
- Has undo, and lets you click to pick the spot to change.
Where AI helps
AI Polish: AI changes things as you ask (credits are charged first) · Gap Analysis: AI finds gaps in the app.
10. Studio: edit on the real screen
YouNo AIInstantStudio on the live system: a live preview of the real app Click to pick a button on the app page — a direct edit costs 0 credits What you do
- Press “Pick”, then click what you want to change on the live app page.
- Change a colour, text, image, or move a field, and see the result at once.
What the system does
- A direct edit uses no AI and costs no credits (the “Direct edit · 0 credits” label).
Where AI helps
This step does not call AI. The system does it all itself.
Tip: The images are from Studio on the live system (the ClinicAi app).
Change the colours of the whole app with design tokens
YouNo AIChange colours with design tokens What you do
- Pick a colour from the tokens (primary · accent · background, etc.) and press apply.
What the system does
- Changes the CSS variable once, so the whole app changes together.
Where AI helps
This step does not call AI. The system does it all itself.
Ask in words, add a page, and history
YouAI helpsStudio: the box where you describe a screen change in words Add a new page from a template Edit history, and the Dev / SIT / UAT environments What you do
- Describe the screen change → see the price first → confirm → see the plan → check → apply.
- Add a new page from a template (no AI) · see history and undo · Dev / SIT / UAT environments.
What the system does
- Builds a preview that can be compiled again (no AI).
Where AI helps
Commands in words: AI makes a plan once, from a list of recipes the system picked out, and you check it before applying.
Tip: You see the price first every time, and you can always undo the latest edit.
11. Ask for changes later (Change Council)
YouAI helpsChange Council: the current spec, a new request, and the verdict What you do
- Type what you want to add or change, and read the verdict.
- Press apply → you get a new version of the requirement spec → let AI carry it out.
What the system does
- Keeps the spec as versions, and you can open the full document.
Where AI helps
AI phrases the request once → 6 AI advisor seats each weigh in from a different angle and summarise the decision → AI writes code to the approved spec.
Reforge: bring an existing app to AppForge
Already have an app? Send its code or its running website. AppForge reads it, understands it and builds a new app that the old clients can still call as before, with tools to prove the new app behaves like the old one.
What Reforge is
YouAI helpsThe Reforge page: turn legacy code into a modern app What you do
- Open “Reforge” from the account menu (top right) or search for it with ⌘K when you already have an app and want a new one on the AppForge standard, without describing the idea from scratch.
- At the end you choose one of two paths: AppForge builds the whole new app for you, or you take a repo and port it yourself in your IDE (Reforge DIY).
What the system does
- Three stages: ingest → understand → map to AppForge, and it stops for your review before each next stage.
Where AI helps
AI reads the code and maps it · masking secrets, reading the old API's shape and comparing old with new use no AI
Tip: The menu shows when an admin has turned Reforge on · the new app answers the API in the old shape, so old clients such as a mobile app keep working unchanged (see the “Legacy API contract” table at the end of this part).
Send in the old code
YouNo AIA few secondsChoose the code source, confirm your rights, then start reforging What you do
- Choose the source: upload code (.zip) up to 30 MB · a GitHub repo · or a running website.
- Tick the box confirming you own the code or are authorized, then press “Start reforging”.
What the system does
- Without the confirmation nothing starts, and every confirmation is recorded.
- Running website: first prove the site is yours (serve the text at the address given, or add a DNS TXT record). After that it is only read: pages of the same site, robots.txt honoured, forms read but never submitted, nothing logged into.
Where AI helps
This step does not call AI. The system does it all itself.
Ingest and understand
YouAI helpsA few minutesThree stages: ingest · understand · map, with what was ingested and the recovered spec What you do
- Check “What we ingested”: files and lines, languages, package manager, framework and the sign-in method, then press “Looks right — understand it”.
- Check “Recovered spec”: the number of tables, endpoints and screens, then press “Looks right — map to AppForge”.
What the system does
- Every secret is masked before any AI call or disk write · .env files and key files (.pem .key .p12 .jks) are dropped whole.
- Files over 512 KB are skipped and at most 6,000 files are read · it says plainly how many files the AI read out of the total, and which ones only in part.
Where AI helps
Ingest uses no AI · Understand: 6 AI labs each read one side at the same time (database · API · screens · business rules · sign-in and permissions · outside services), then one spec is merged from them
Tip: If you see a warning that the stack was only partly detected, review the recovered spec more carefully before going on.
The migration plan, then build the new app
YouAI helpsThe migration plan: what each old piece becomes in the new app What you do
- Read the “Migration plan”: what each old piece (tables, routes, sign-in, validation and so on) becomes in the new app.
- Press “Build this app” → the normal build page (build gate, price, API Spec form), or choose Reforge DIY at the next step.
What the system does
- The old API's shape is read from the app's own files (tests, route files, response helpers); every item found cites its file and line · not found = not translated, never guessed.
- The built app gets a legacy API layer: an old client calls the old path and gets the answer in the old shape, while the new app's own API stays complete.
Where AI helps
AI writes the migration plan and the new app's design · reading the old API's shape uses no AI · building works like any other build
Tip: Each user's data stays theirs: the new app always sets a row's owner from the signed-in user (a client cannot send it) and another user gets 404.
Prove they match — old vs new
YouAI helpsProve they match: capture answers from the running old app What you do
- Enter the URL of the old app that is still running and press “Build plan + capture from old app” to keep its real answers as the baseline cases.
- Point at the new app's preview and run the comparison · you can load the old data into the preview with a JSON export of the old database.
- You can also run the old app's own tests (only pytest and supertest suites that call the app over HTTP can be replayed).
What the system does
- Each answer is compared field by field, and the evidence tier T0–T3 says what was actually checked (see the table at the end of this part).
- Old tests that can't be replayed faithfully are left out with the reason, for example they send a value masked at ingest or need data the old test database had.
Where AI helps
The comparison uses no AI · when a case fails, AI suggests the fix but does not apply it; you apply it on the build page or in your own workflow
Tip: You can set “Publish rule for this app”: the minimum tier required · a single failing case blocks publishing.
HAR files, run history and data migration
YouAI helpsUpload a HAR · run history · generate the data-migration script What you do
- No old app running? Open DevTools → Network, tick “Disable cache”, use the old app, then export a HAR with content (up to 25 MB) and upload it.
- To check that one user can't read another's data, upload one HAR per user.
- Press “Generate migration script” to get a script that moves the data from the old database into the new tables, then run it yourself against your databases.
What the system does
- Reads (GET 200 with JSON) become cases · from the first write on, the requests form one replay sequence, sent only to this project's preview · the file is read once and discarded, no cookie or header is kept.
- Every run is kept as it was; a later run can't change an earlier result.
- The migration script runs in one transaction, counts rows before and after, and stops if a table loses rows · a script with a destructive statement can't be downloaded · AppForge never touches your databases.
Where AI helps
Migration script: AI writes the column mapping and the script, then the system checks its safety before it can be downloaded · reading a HAR uses no AI
Tip: A password used to sign in during a comparison is used for that run only and is never stored.
Reforge DIY: take the repo and port it yourself
YouAI helpsReforge DIY: one repo, four parts inside What you do
- Name the repo, choose private, choose whether to include the old code, then start packaging.
- Clone the repo and open it in Claude Code or any IDE agent, and port one feature at a time following the guide.
What the system does
- One repo with 4 parts: legacy/ (the old code, secrets masked) · app/ (an AppForge app that boots right away with the mapped kits) · docs/reforge/ (the spec, the migration map, the guide and the attestation record) · tools/reforge/ (a parity checker that runs on your machine).
- You can change your mind later: press “Build with the platform instead”.
Where AI helps
The porting guide has a prompt per feature, in the order to do them, ready to paste into your AI · the porting runs on your own subscription
Tip: A one-time fee per project; you always see the price before paying · data is not migrated automatically, and parity covers only the cases you record.
Connect rea: rea takes the old app apart, and its evidence goes into Reforge
YouAI helpsWhat you do
- Use it when there is no source, or the source doesn't tell the whole story: a running website, minified or bundled JS, an Electron, .NET or APK app with no source, or behaviour you only see while the old app runs.
- Follow the table “Connect rea, step by step” at the end of this part: install rea and connect the AppForge MCP in the same AI client, then ask in a sentence for the old app to be taken apart and sent to the project as a “Legacy Evidence Pack”.
- Come back to the Reforge page, check the “Evidence from rea” card, answer every question in the “What rea could not tell” card (“Unknown — leave it out” is always allowed), then approve to turn it into a design.
What the system does
- Checks the pack without AI: all 6 sections (data, API, screens, logic, auth, external services) must match their shapes, stay under the caps and hold no secrets, and every ev_… evidence id cited must exist in the attached evidence bundle · an item that cites no evidence is marked “no evidence yet”
- Skips AppForge's 6 AI labs and goes straight to “understood” · a website must prove ownership first (the .well-known file or a DNS TXT record), as with a normal website source
- AppForge never runs rea on its servers: rea is an MCP server that runs on your machine with your AI client
- If the project already has its code (uploaded or from GitHub), a pack sent with mode “merge” is merged with AppForge's lab results instead of replacing them: items rea observed or derived win, items rea only inferred lose to the code, and conflicts between the two are shown to you before you approve
Where AI helps
Taking the old app apart uses your AI client and subscription, not AppForge credits · AppForge uses AI once, to turn the evidence into a design after you approve
Tip: rea (github.com/morluto/rea) is a third-party open-source project (MIT), not part of AppForge · if you already have a Reforge DIY repo, you can use rea inside it as docs/reforge/REFORGE_GUIDE.md §1a describes · the architecture, the benefits and a screenshot of every step are in the guide book “Reforge × rea” (/guide/reforge-rea).
Connect rea, step by step
| Step | What to do | What you get |
|---|---|---|
| 1 · Prepare a machine | Use your own machine, not a server that runs production · install Node.js 22.19 or later (or 24.11+ / 26+) and an AI client that supports MCP, such as Claude Code | A machine ready to run rea |
| 2 · Install rea | Run npx [email protected] setup, choose your AI client, review the plan setup will write, approve it, then restart the client | Your AI client sees rea's tools as an MCP server |
| 3 · Connect the AppForge MCP | Open Settings → Agent tokens, pick the Reforge project, and run the claude mcp add command it gives on the same machine | The same AI client sees both rea's tools and AppForge's: reforge_pack_schema · reforge_pack_validate · reforge_pack_submit |
| 4 · Ask your AI in a sentence | For example: “Use rea to take apart https://crm.example.com, which I own, with read-only tools, then send it as an evidence pack to this AppForge project. Cite evidence for every item, and don't guess anything rea says it doesn't know.” | The AI reads reforge_pack_schema, gathers the results into 6 sections, checks them with reforge_pack_validate until they pass, then sends them with reforge_pack_submit along with the evidence bundle (export_evidence_bundle) and a HAR if there is one |
| 5 · Tools used most when migrating | inspect_analysis_view (the api-surface view): endpoints grouped from a HAR → the API section · analyze_javascript_application: modules, imports, routes and IPC of a JS/Electron app · inspect_web_network_capture: every request and response in a HAR file · inspect_managed_artifact / inspect_managed_members: .NET assemblies with no source · list_unknowns: what rea cannot tell yet | You know how the old app really behaves before you write the new one |
| 6 · Check and approve in AppForge | Open the project's Reforge page: the “Evidence from rea” card shows the rea release, the number of items, how sure each is (observed · derived · inferred), the items with no evidence and what rea could not tell · check, then approve | The new app's design, then the API form you approve before the build, as in a normal Reforge |
| 7 · Use the same HAR on both sides | Record a HAR from the old app, let rea explain its endpoints, then send the same file with the pack or upload it under “Prove they match” in AppForge | rea says what the old app does · AppForge checks whether the new app answers the same · AppForge's HAR reader follows rea's rules: HAR 1.1/1.2, and a file with a duplicate key is refused |
| 8 · Rules | Only for software you own or are allowed to change (you confirm it when you send the pack, matching rea's DISCLAIMER) · a website must prove ownership · use read-only tools: rea itself classes 31 tools as changing things, such as installing an app over ADB or running a Frida script · what rea says it doesn't know is not migrated, and must not be guessed | A migration where every item can be checked |
This guide follows rea release 6.7.0 (checked on 18 Oct 2026) · rea ships often and each minor release breaks something from the one before; with another release the commands or tool names may differ from this table · AppForge's pack does not depend on rea's file formats
Legacy API contract: what an old client still gets
| What the old client expects | What the new app does |
|---|---|
| The old paths, such as /api/todos | Answers on the old paths · the new app's own API (/api/v1/...) stays complete |
| A body envelope such as {success, data, message}, or none | Wraps or doesn't wrap, as the old app did |
| An error format such as errors[] or {error: "…"} | Answers errors in the old format |
| Status codes per route, e.g. DELETE answers 200 or 204 · bad input answers 400 | Answers the same codes as the old app |
| PUT for edits, and actions such as /toggle | Accepts PUT and performs the actions as before |
| True/false as 0 and 1 | Answers 0 and 1 |
| Column defaults, including an empty string | Uses the old defaults, and accepts an empty value when the default is empty |
| Lists as {items, total} | Wraps lists as before · does not yet send total when the list fills a page, and does not yet translate ?page= / ?tag= |
| Register, log in and “me” on the old paths, by email or username · the token where the old answer had it | Works as before · old users migrated with bcrypt passwords sign in the first time and their account is linked automatically · passwords never go out in an answer |
| Each user's data stays theirs | The row's owner comes from the signed-in user · another user gets 404 |
| Many-to-many name lists, such as a note's tags | Not supported yet: answers 400 with a clear error, never silently drops the data |
Every item comes from the old app's own files, citing the file and line · an item that isn't detected is not translated (the AppForge standard answer is used).
Evidence tiers of the parity proof
| Tier | What was checked | What it needs in addition |
|---|---|---|
T0 | Reads (GET) replayed against the new app, without the old data loaded — not yet a proof | The old app's URL, or a HAR file |
T1 | As T0, with the old data loaded into the preview first | A JSON export of the old database |
T2 | T1 + writes (add, edit, delete) replayed and read back matching | A HAR that contains writes |
T3 | T2 + every case measured for values that change by themselves (such as times) + the old app's own tests all pass | The old app's tests that can be replayed |
| Insufficient | Too few cases were decided to claim any tier | Capture more cases |
| Differences found | A case failed, or one user saw another user's data — always shown, never hidden behind “insufficient” | Fix the new app and run again |
A tier states only what was actually checked, never a label someone set · the default publish rule: minimum tier T0 and no failing case.
API Spec: everything the form supports
Reference tables for the API Spec form: endpoint and screen kinds, every screen recipe, scheduled jobs, alerts, sync, kits, the approval checks and the 4 prices. Every row comes from what the system really does.
The 8 endpoint kinds
| Kind | What it is | What the compiler generates | Who writes the code |
|---|---|---|---|
crud | Add, view, edit or delete the rows of ONE table (list, read, create, update, delete). The form knows it by itself when the path names exactly one table, such as GET /patients. | The table's routes, only for the operations you approved (see per-table access). A path ending in an action such as /approve or /calculate is not crud: it would add a row instead of doing the action. | No AI when the path names one table · otherwise AI helps fill it · the compiler always writes the code |
query | A GET that returns rows of ONE table, filtered or sorted by that table's own fields; it can pick just the first row (latest) and cap the count (at most 200). Filters: eq ne gt gte lt lte in contains is_null. Relative times follow Thai time: today tomorrow week_start month_start year_start days_ago_N. | A GET route with the search / date-range parameters the form defines, checked by the compiler's own validator, not a second rule set. | AI helps fills the form · the compiler writes the code |
aggregate | Summary numbers over ONE table: count sum avg min max, optionally per group (day, week or month for a date field), with filters, sort and limit. sum and avg need a number field. | A GET route that returns the summary as rows or groups; a dashboard or report screen can bind to it. | AI helps fills the form · the compiler writes the code |
summary | Numbers over several tables in one request, such as a dashboard's or overview's figures. Each item is an aggregate of ONE table with its own name, at most one group, and a group can be labelled with the related row's name (appointments per branch, labelled by branch name). | One route that returns every figure; overview and dashboard screens can bind to it. A report that lists rows of several tables is not a summary. | AI helps fills the form · the compiler writes the code |
document | ONE row printed as a formal document: invoice, receipt, quotation, certificate. The path has one parameter, the row's id. The form sets: number prefix (1-6 of A-Z 0-9), the issue-date field, the party field, line items (a has_many relation: description, quantity, price), total, VAT, WHT and body text. A certificate has no line items, total or tax. | A route and a printable document page, from the values the form sets. | AI helps fills the form · the compiler writes the code |
kit | A packaged capability a kit provides. Today 7 kits can stand in for an endpoint, listed in the kit table below (AI chat, Jarvis, AR, motion, charts, file import, documents). | When the kit that serves this endpoint is in the build, the app uses the kit's route and it is not remaining work. When that kit is not in the build, or no kit can stand in yet (payments or messaging, for example), the endpoint is still remaining work. | No AI when the kit is in the build |
platform | Sign-in, sign-up, tokens, the user's own account, and the PDPA pack. | app-base already ships these in every app, so they are never remaining work. | No AI — in every app already |
custom | Anything else, or anything the form is not sure of, including endpoints ending in an action (approve, cancel, calculate …) and entries the compiler refused. Each entry's reason is shown on the form; nothing is dropped silently. | The compiler does not build it; it is remaining work on the Ready to build card. | AI helps in the build (per the quote), or you write it from the guide |
AI never writes code in this form. It only fills the form in one call, a person reviews and approves it, and the compiler writes the code from the approved form.
The 4 screen kinds
| Kind | What it is | Is it remaining work? | Who writes the page |
|---|---|---|---|
compiled | A page that shows ONE table, in one of the 4 basic patterns (data-list, detail, form, master-detail) or a registered screen recipe (the recipe tables below) with the options that recipe accepts. | No, unless screen compile is switched off for that build or the form as a whole does not compile. | No AI — the compiler writes it |
kit | A page a kit ships: /chat, /jarvis, /ar and /motion. A person maps the screen on the form; the AI does not pick it. If the kit has nothing to read (Jarvis needs a compiled read route), the mapping is refused. | Not remaining when that kit is in the build; remaining when it is not. | No AI when the kit is in the build |
platform | A page app-base already ships in every app (such as /settings), and the public landing page at “/” (you can choose its template; see the landing templates). A “/” that is the app's own content, such as a signed-in dashboard, is not platform. | No. | No AI — in every app already |
custom | Every other page, such as a page that combines several tables or one that no recipe fits. The reason is shown on the form. | Remaining work. | AI helps in the build (per the quote), or you write it |
A · Records and lists
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
data-list | List | A table of the rows of one table | — |
card-gallery | Card gallery | Rows as cards with a picture and a heading (the picture must be an http(s) link or a data:image); search shows when the screen's query has a search parameter | heading*, image, subtitle, columns, show_search |
detail | Record detail | The details of one row, opened by its id | — |
master-detail | List with detail | The rows on one side, the chosen row's details beside them | — |
tree | Hierarchy tree | Nested data as a hierarchy you can expand and collapse, such as categories and sub-categories (view only) | label*, parent* |
compare | Compare / reconcile | Compare two sides of one data set split by a yes/no field to reconcile, such as our ledger against the bank's | match_key*, side_field*, resolved_field*, amount_field |
Many recipes read at most the first 2,000 rows (10 pages of 200, in ID order, not newest first); when they reach the cap, the screen says it stopped.
B · Forms
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
form | Form | A form that adds a new row or edits an existing one | — |
section-form | Section form | A long form split into sections, with an optional sticky summary; drafts are kept in this browser only | layout, sections, sticky_summary |
wizard | Wizard | Fill in short steps in order; drafts are kept in this browser only | fields_per_step |
transaction-form | Transaction form | A trade document with line items and a total worked out from quantity × price (no tax, discount or currency yet) | quantity_field*, price_field* |
bulk-grid | Bulk edit grid | Edit many rows at once in one grid, only the columns you chose | columns*, page_size, show_search |
questionnaire | Questionnaire | A questionnaire that shows a question depending on an earlier answer (one condition pair); each submit creates a new record | condition_field, condition_equals, condition_target |
C · Overview and reports
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
dashboard | Dashboard | Numbers and charts over a date range, worked out in the browser from the data it read | date_field*, metric_field, label_field, default_range_days |
workbench | Workbench | Analyse by grouping on one dimension at a time and see each group's count, or the sum/average of one number field | dimensions*, measure_fields, label_field |
report | Report | A grouped report with totals | group_by*, metric_field, label_field, show_search |
timeline | Timeline | Events in time order as a timeline, such as visit history | when*, heading*, detail |
overview | Overview | An app-wide overview from a bound summary and up to three bound query lists, tied to no single table | — |
overview-record | Record overview | An overview of one record with up to four related tables, such as one patient with their appointments and invoices | — |
D · Work and time
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
calendar | Calendar | Rows on a calendar (no recurring events yet) | time_field*, label_field*, default_view |
booking | Booking | Book a resource for a time slot, with an overlap check on this page (not in the database, so two people booking overlapping slots at the same moment can both succeed); everyone who sees the grid sees every booking | resource_field*, start_field*, end_field*, title_field, slot_minutes, open_hour, close_hour, slot_key_field |
kanban | Kanban board | A board with a column per status; move a card with a select menu (no dragging needed) | status_field*, title_field* |
worklist | Work queue | A work queue ordered by priority that an assignee can take | assignee_field*, title_field*, priority_field, due_field |
approval-inbox | Approval inbox | An approval inbox where an approver approves or rejects with a reason. Separation of duties is partial: it checks that at least one role can file without being able to decide; a role with both rights can approve its own request, and an admin can decide any row | heading*, status*, reason*, decided_at, choices |
case-tracker | Case tracker | Track one case with a stage bar you can move forward or back | title_field*, stage_field*, assignee_field, notes_field |
rule-table | Rule table | Reorder, enable/disable and check the existing if…then… rules, one condition per rule, with a warning for conflicting rules; rules cannot be added or removed here, and this page does not run them | condition*, comparison*, value*, outcome*, priority*, enabled |
gantt | Gantt plan | A Gantt plan of tasks, view only (bars cannot be dragged yet) | heading*, start*, end*, depends_on |
E · Commerce
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
catalog | Catalog | A product catalogue with price, stock status and a one-at-a-time category filter | heading*, price*, stock*, category*, columns |
product-detail | Product detail | One product's page with price, compare-at price and availability (no cart yet) | heading*, price*, currency*, picture, compare_at, availability |
checkout | Checkout | A cart and order confirmation; no real charge, confirming only changes the order's status | order_field*, quantity_field*, price_field*, label_field*, status_field*, choices |
order-tracking | Order tracking | Orders with a status bar; anyone who can update the row can advance the status or cancel — who may do which step is not limited yet | status_field*, label_fields*, cancelled_value, reason_field |
billing | My membership | My membership: request an upgrade by bank transfer with a slip that an admin checks (no card payment); can be added as a page from Studio | plans* |
F · Content
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
search | Search | Search one kind of data with a query and filters | heading*, filter_field* |
asset-library | Asset library | A file library: upload, replace, delete and group in folders by text label (no version history yet) | file*, title, folder |
document-editor | Document editor | Open one document and edit its title and body with autosave (no comments or history yet) | title_field*, body_field*, status_field |
article | Article (CMS) | CMS articles: draft → review → publish, plain text | status_field*, title_field*, body_field*, publish_at_field |
G · Conversation
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
inbox | Team inbox | A team inbox grouped by thread; everyone who sees the list sees every conversation (no attachments yet) | thread_field*, body_field*, author_id_field*, author_name_field, created_field |
copilot | AI assistant | An AI assistant that answers from the data the page read; your question and at most 50 rows go to the AI provider the admin set (uses AI while the app runs) | label_field*, context_fields*, action_field |
feed | Feed | A feed of posts and replies (no likes, and this page cannot edit or delete posts yet) | body_field*, author_id_field*, author_name_field, parent_field, created_field |
lesson | Self-check quiz | A multiple-choice self-check scored at the end; the answers sit in the browser, so it is practice, not an exam | question_fields*, answer_key*, score_field, completed_field* |
H · Account
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
onboarding | Onboarding checklist | A getting-started checklist you can resume; the steps come from the table's fields and are fixed | step_fields*, dismissed_field |
profile | My profile | My profile: edit name, language, time zone and consent | name_field*, locale_field, timezone_field, consent_field |
I · Administration
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
settings | Settings | A settings page: switch things on and off and edit values, in groups (no change history yet) | key_field*, value_field*, enabled_field*, group_field |
operations | Operations log | A log of background runs with status, times and attempts, to see which job failed | heading*, status*, started_at*, finished_at*, message, attempts, choices |
notification-center | Notification center | A notification centre with an unread counter (not push or real-time) | message*, when*, read*, link |
J · Public
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
landing | Landing page | A public marketing page for signed-out visitors, read-only, with no contact form yet | title_field*, body_field*, image_url_field, link_url_field, link_label_field, order_field |
K · Place and device
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
map | Map | An OpenStreetMap map with the list beside it (opening the map sends the viewer's IP address to OpenStreetMap) | label_field*, lat_field*, lng_field*, category_field |
kiosk | Kiosk check-in | An on-site check-in point: enter or scan a code to check in, such as an attendee's badge code | code_field*, name_field*, checked_in_field*, checked_in_at_field |
fieldwork-offline | Offline field record | Record field reports without a signal and sync when back online | record_fields*, client_ref_field*, label_field, date_field |
device-capture | Device capture | Take a photo or scan with the device, with a note and an amount, such as a receipt (no live camera preview and no audio recording yet) | photo*, note, amount |
live-monitor | Live monitor | A live monitor with status lights and last-seen times, refreshed in cycles (not push) | title_field*, status_field*, last_seen_field*, status_choices, stale_minutes, refresh_seconds, reading_field, command_field |
L · Canvas
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
diagram | Flow diagram | A flow diagram of boxes and arrows with draggable positions, one outgoing arrow per box | label_field*, x_field*, y_field*, next_field |
media-editor | Media player / editor | A media player with trim points, stored beside the file; the file itself is not cut | media*, kind*, title*, captions, trim_in, trim_out |
print | Print view | A print view of one record using the browser's print dialog; it never makes a PDF file | heading*, fields*, date, body |
M · Advanced studios
| Recipe id | Name | What the screen does | Main options (* = required) |
|---|---|---|---|
knowledge-graph | Knowledge graph | A read-only knowledge graph that draws declared foreign-key relations as links and stops at a node cap (uses the graph kit's display) | label_field*, max_nodes |
The other options on the form
| Option | What you can do | Rules and limits |
|---|---|---|
| Relations between tables | The form lists every relation whose target table could not be found, with candidates. A name that sounds like a person (provider, doctor, staff, owner, author, assignee, reviewer, approver, member …) most likely means the platform's users table. AI helps pick a target in the same call that fills the form. | An undecided one is asked of a person: pick a target (an existing table or “User”) or drop the relation. While any is undecided the form cannot be approved. Nothing is guessed. |
| Visibility per table | Pick one of three per table: owner (each person sees only their own rows) · role (visible to the roles you name) · public (every signed-in user sees every row, with no owner or role limit). All three still require signing in. | A role table must name at least one role. A role name starts with a letter, is at most 64 characters, and may use letters, digits, _ and -. An owner table needs a field that points to users. |
| CRUD switches per table | Tick which of list, read, create, update and delete a table has. Only the ticked routes are generated. | At least one is required, because an empty list would read as the full set. app-base's own tables (users and so on) are not on this form. |
| Screen words in Thai and Chinese | The compiler writes page titles and field labels in English. When the form is drafted, AI translates them into Thai and Chinese once, stores them on the form for you to read and edit, and the compiler uses those words. | Each label is short, at most 60 characters. One call translates at most 200 strings; the rest stay English. A word you edited is never overwritten. If translation fails the form still works; it just compiles in English as before. |
| The “/” landing row | Every app already has a public landing page at “/”. When the design describes that page as a marketing page, the form marks it platform instead of having AI write a new page, and lets you choose one of 5 templates (the template table below). | A “/” that is the app's own content, such as a signed-in dashboard, keeps the normal rules. A value that is not on the template list is dropped. |
| What AI fills on the form | One AI call for whatever the system cannot answer itself. It answers JSON only, using only the names it was given, never writes code, and everything passes the compiler's checks before a person is asked to approve. | Nothing is guessed. A field that does not exist is refused. What cannot be built becomes custom with a reason; nothing is dropped silently. |
Scheduled jobs on Thai time
| Option | What you can do | Rules and limits |
|---|---|---|
| Name and time | Give the job a name and a time as HH:MM on Thai time. | The name is at most 120 characters. The system converts to UTC (minus 7 hours) itself. |
| Days | Every day, or pick weekdays (0 = Sunday … 6 = Saturday). | If you pick days, pick at least one. |
| Steps | Available steps: summary (a compiled summary) · when (a condition; needs a summary before it) · document (a document from an earlier summary) · notify (by email, LINE or webhook) · fetch_file (fetch a file) followed straight away by import (into a table). | A job has at most 20 steps and needs the scheduler kit in the build. Export steps and in-app notices are not supported yet. An owner table cannot be used by a scheduled job, because a job has no signed-in user. A job the compiler refuses is taken off the form with one note naming the reason; other jobs are unaffected. |
| Who it runs as and notifies | A job runs, and notifies, as the admin role only. | The numbers in the mail use Thai words drafted with the job, not aliases. |
| Jobs drafted from the design | When the design carries timing words such as “every morning” or “scheduled report”, the form proposes a job for it and adds a summary if none exists. | A proposal that fails the checks is taken off with a note; it is never left as open work. |
Alerts: a summary → a condition → send
| Part | What you can do | Rules and limits |
|---|---|---|
| The summary | The job reads a number from a compiled summary. | It must be a summary the form already has. |
| The condition | Compare one number from the summary with a fixed value using <, <=, >, >=, ==, != (for example sales < 10000). If the condition does not hold, the run ends as skipped and nothing is sent. | One number per condition, and the value is a real number, not text. |
| Channel: email | Email the admin with the numbers in the body; no attachment — documents can be downloaded on the app's /jobs page. | The recipient is the admin role. |
| Channel: LINE | Send to the LINE users, groups or rooms you typed on the form. | At most 10 ids per job. An id starts with U, C or R followed by 32 lower-case hex characters. Only admins type them, and they leave the app for LINE. The channel-client kit must be in the build. |
| Channel: webhook | Post to the webhooks the admin registered for an event name. | The event name is lower-case letters, digits, _ . - and at most 80 characters. The webhooks kit must be in the build. |
Sync jobs into a table
| Option | What you can do | Rules and limits |
|---|---|---|
| Shape of a sync | fetch_file (fetch a file or query result) followed by import (into a table), run at the time and on the days you set (every day or chosen weekdays). | fetch_file must be the step right before import, because import reads only the last file. |
| Source: a SQL database | Read from an external database the app's admin registered, with ONE query; the result's column names are the table's field names. | Read-only: ONE SELECT (or WITH … SELECT), at most 4,000 characters, at most 10,000 rows, 30-second timeout. The data-connectors kit must be in the build. A query not clearly read-only is refused. |
| Source: object storage | Read one file by its key from an object-storage source the admin registered. | The key is at most 200 characters. The connectors-object-storage kit must be in the build. An upload source cannot be written on a form. |
| Target table | Insert rows that are not there yet, matched on the fields marked unique. A matching row counts as a duplicate and is not inserted again. | The table must accept spreadsheet import (create and list switched on, and the imports kit in the build), have at least one unique field as the dedup key, and must not be an owner table. |
Landing templates for “/” (5)
| Template | Best for |
|---|---|
product | A general software product or tool (the default) |
service | Booking, appointments, reservations or queues at a real-world service |
community | Content, members, groups or people sharing with each other |
personal | Wellbeing, habits, self-tracking or reflection for one person, calm in tone |
business | B2B, operations or teams at work: proof, stats, a demo call to action |
Who picks, in order: you, on the form's “/” row → AI, in the same call that writes this page's copy (only a name on the list is kept) → keyword rules over the design; with no match you get product. Every template reads the same content; they differ in section order and treatment.
Kits that serve endpoints and screens
| Kit | Endpoints it serves | Page it ships |
|---|---|---|
chat | POST /api/v1/chat · GET /api/v1/chat/history | /chat |
jarvis | POST /api/v1/jarvis/ask · GET /api/v1/jarvis/status | /jarvis (needs a compiled read route) |
ar-viewer | GET /api/v1/ar/models | /ar |
motion-events | POST · GET /api/v1/motion/events | /motion |
charts | GET · POST /api/v1/charts · PUT /api/v1/charts/{mid} | — |
imports | POST /api/v1/imports/{domain}/preview · POST …/confirm · POST /api/v1/imports/batches/{batch_id}/rollback · GET …/template | — |
documents-export | POST · GET /api/v1/documents · GET /api/v1/documents/{did} | — |
A kit counts as doing the work only when it is in the build. When several kits match equally, nothing is guessed and the endpoint stays remaining work. Kit prices follow the quote.
Checks before approval, and what blocks it
| Rule | If it fails |
|---|---|
| Every table the compiler builds must be on the form | Blocked: a table left off would get every CRUD route. |
| Every table needs at least one operation | Blocked: an empty list reads as the full set. |
| A role table must name a role | Blocked. |
| Every relation must be decided | Blocked until you pick a target or drop the relation. |
| The form must compile as approved | Anything the compiler's validator still refuses, such as an owner table with no key to users or two collections that clash, blocks approval and says why in the compiler's words. |
| An endpoint or screen the compiler cannot build | Does not block approval: it becomes custom with its reason on the form and joins the remaining work. |
| Editing after approval | The form goes back to draft. While it is a draft, a build ignores it entirely (it compiles and is priced as if there were no form), so approve it again before you build. |
The “Ready to build” card: 4 prices
| Level | Who builds the rest | Price |
|---|---|---|
scaffold | You, with your own AI, from the remaining-work guide. AppForge scaffolds and compiles what compiles. | Per the quote |
economy | The economy AI (Haiku) builds the rest. | Per the quote |
balanced | The balanced AI (Sonnet) builds the rest. | Per the quote |
premium | The premium AI (Opus on critical stages) builds the rest. | Per the quote |
Price = scaffold and compile + kits + the AI part × the share of work still left (weighed by the model cost of each endpoint and screen), rounded up once. Nothing compiled = today's flat price; everything compiled = the scaffold price. An approved form can only lower the price. The card shows today's flat price beside every level. This is the default method. An admin can set a per-item rate instead (never above the AI part of the flat price), and each level's AI model is a default the admin can change.
Remaining work: what counts and what does not
| Item | Counted as remaining? |
|---|---|
| crud, query, aggregate, summary and document endpoints | No: already compiled, unless the form as a whole does not compile. |
| platform endpoints | No: app-base serves them. |
| kit endpoints | No when the kit is in the build (counted as done without AI); yes when it is not. |
| custom endpoints | Yes, with each entry's reason. |
| compiled screens | No, unless screen compile is off for that build or the form as a whole does not compile. |
| platform screens | No. |
| kit screens | No when the kit is in the build; yes when it is not. |
| custom screens | Yes. |
The remaining-work guide (downloaded from the card) lists these same items with a prompt for your own AI, and says plainly that files the compiler already wrote must not be rewritten, renamed or duplicated. If the form as a whole does not compile, every item except platform counts as remaining work, with the reason.
Studio: everything it can do
Reference tables for Studio: canvas edits, the command workbench, adding a page, rebuild, history, environments and references. Every row says whether AI is used and, where the system fixes it, how many credits.
Direct edits on the canvas
| What you do | How | Scope and limits | AI and credits |
|---|---|---|---|
| Colours, fonts, radius, spacing (design tokens) | Enter the CSS variable name such as --primary and a value such as #4f46e5 or oklch(0.6 0.2 280), then Apply. | Applies to the whole app (design-tokens.css). The name is lower-case letters, digits and -; the value is at most 120 characters. The project needs a design system. | No AI · 0 credits |
| Text on the screen | Click text on the preview. If it can be edited directly, a text box appears; type the new words and press Apply. | Two kinds can be edited directly: (1) text with a key in the app's dictionary, saved in the language file the preview is showing (en th zh ar de es fr id ja ko pt vi); (2) the title and field labels of a compiled screen, saved into the design so they survive a rebuild, with the same words in every language. Other text has no fixed address yet; type a request instead. | No AI · 0 credits |
| Logo and background image | The Studio canvas has no image upload button yet. Type a request such as “make the logo blue”, or upload under “Branding Images” at the design review step before you build. | Branding Images: PNG, JPEG, WebP or GIF up to 2 MB, a logo and a background per language (en, th, zh or the default), used on the app's landing page. | AI helps when you type a request · 2 credits · uploading uses no AI |
| Move a field up or down | Click a field on the preview and press up or down, choosing “This screen” or “Every screen of this data”. | Changes the field order of a compiled screen. | No AI · 0 credits |
| A free-text instruction about what you picked | Type what you want changed in the prompt box and AI edits the app's files. | Used for anything the direct paths above do not cover. You always see the price and confirm first. | AI helps · 2 credits |
Every Studio change goes through one pipe: quote → confirm → do → reconcile. Even a 0-credit direct edit passes through it, so you see the price first every time.
How Studio sorts a typed request into 6 routes
| Route | Words that send it here | Result | AI and credits |
|---|---|---|---|
token | color, font, radius, spacing, density, theme | A design-token edit | AI helps · 2 credits when typed as free text |
asset | logo, banner, image, hero | An image edit | AI helps · 2 credits when typed as free text |
text | rename, wording, label | A text edit | AI helps · 2 credits when typed as free text |
spec_change | field, column, table, api, endpoint, permission, role, approve, workflow | Studio says the change belongs in the requirement, not just the page, and offers “Open Change Request”. If the request could be either a spec change or a style edit, you pick the meaning first; nothing is quoted yet. | No AI in Studio |
refuse | auth, login, password, secret, .env, migration | Refused, with a reason | No AI |
overlay_ai | Everything that matches none of the above | Goes to the AI editor that edits the app's files from free text. | AI helps · 2 credits |
This is a keyword table you can inspect, not a model guessing. An unrecognised request goes to the AI editor rather than being refused. Admins can see how often each route was picked and how often a person overrode it.
Command workbench: what a typed sentence can change (9 kinds)
| Change | What it does | Limits |
|---|---|---|
set_screen_query | Bind a list screen to an existing query and name its search parameter. | Uses a query the form already has. |
set_screen_related | Show related rows beside a record (such as a patient's appointments), with complete en/th/zh field labels. | Bound to one query and one source field. |
set_screen_pattern | Switch a screen between a list (data-list) and a list with detail (master-detail). | These two only. |
set_screen_copy | Edit a screen's title and field labels in Thai, English and Chinese. | All three languages are needed. |
set_screen_field_order | Set the order of fields on a screen. | At most 64 fields, no duplicates. |
set_screen_lookups | Make a field that points to another table a searchable picker labelled by a field you choose. | At most 8 per screen. |
set_screen_form_presentation | Lay a form out flat, in sections or in tabs; set the groups, a sticky summary and each control (single-line, multiline, radio). | At most 8 groups and 64 controls. |
set_screen_recipe | Move a screen onto a screen recipe (the recipe tables in the API Spec part) with its options. | The model is shown at most 8 fitting recipes, ranked against your sentence and the table's fields. Options must pass that recipe's own check against the real table. |
upsert_query | Create or change a GET query of one table, with filters and sorting. | At most 12 filters, 8 sorts and 200 rows. The path is fixed literal segments and must not overlap platform routes (auth, admin, appforge). |
If a command cannot be done with these 9, the answer is “cannot”, with a reason, never a guess. Creating new tables or editing data is not on this list.
Command workbench: quote → confirm → plan → review → apply
| Step | What happens | AI and credits |
|---|---|---|
| 1 Quote | You type a sentence on the screen you chose. The price is shown first, with no model call yet. | No AI at this step |
| 2 Confirm | You confirm the price once per command. | AI helps · 2 credits per command (one inference) |
| 3 Plan | The model proposes the typed changes (the 9 kinds above) in one call. If the answer fails the checks the system asks for one repair; if it still fails, the answer is “cannot”, with reasons. | AI helps · included in the 2 credits |
| 4 Review | You see before and after for every change before anything is written. Possible states: quoted, planning, review, needs clarification, cannot, failed, applied. | No AI |
| 5 Apply | The compiler checks and writes the files, with no AI call and no further credit. It is recorded in history and can be reverted. | No AI · nothing more charged |
One command makes at most 12 changes. If you confirmed but planning never started (for example, the server stopped midway), the credits are refunded automatically.
Add a page, rebuild, history and revert
| What you do | How | Scope and limits | AI and credits |
|---|---|---|---|
| Add a page | Add a page that renders on app-base's own routes and needs no table. Pick the template and set its path, title and options. The template you can add now: “My membership” (billing), default path /membership; it needs the plan names. | The path has 1–3 segments of lower-case letters, digits and -, each at most 40 characters. The title is optional, at most 60 characters; left blank, the template's own name is used in every language. Refused with a reason when the path is taken or reserved, the options fail, or the page will not compile. A double submit adds one page. | No AI · 0 credits |
| Rebuild | Recompile the saved design with the current compiler, then refresh the preview. | Deterministic: the same design gives the same result every time. | No AI |
| History | Every change made through Studio is recorded as a numbered entry you can list. | Kept with the project. | No AI |
| Revert | Undo the latest entry, restoring the files it changed; if it changed the design, the design is restored too (an added page is removed, for example). | Only the latest entry can be reverted; an older one is not undone in the middle, because that would discard changes you never asked to lose. | No AI · 0 credits |
Environments Dev / SIT / UAT and promotion
| Environment | What it is | What it takes to get in |
|---|---|---|
dev | The live preview you are editing. | None: it is the source for SIT. |
sit | A separately running copy for the first round of checks. | The sit.approve grant and passing the gates. |
uat | A separately running copy for users to accept. | A SIT already deployed at the very same version (hash), the uat.approve grant, and passing the gates. |
production | The real app your users use. Approving this step records that the version is ready to go live; the actual deploy still goes through the normal deploy step. | That version through UAT, the promote-to-live grant, and passing the gates. |
Every step uses the same gates as the Publish button: a reforged app must pass its parity check and leave no open gap. The requester and the approver must be different accounts. SIT and UAT close themselves when idle, and how many may run at once per project is capped; an admin sets both. Promotion uses no AI.
References: images and URLs
| Reference | What it does | AI and credits |
|---|---|---|
| An image (a screenshot) | Reads a design from the picture, such as its colours, with one vision call. What it reads must be grounded in the picture or it is refused (the credits are still used, because the model was called). Then pick values one at a time, such as one colour, and apply each as a direct edit, which costs no credits. | AI helps · 3 credits |
| A URL (a web page) | Reads the page's palette from the signals in its HTML. | No AI · 0 credits |
| URL → page map | Matches each page of the reference site to the most similar page of your own app, as a checklist, using your project's own page list. | AI helps · 2 credits one call |
An image has one step and no further plan, because it is read completely when created. Both AI-priced actions show their price for you to confirm first.
Features an admin has to switch on first
| Capability | What must be on |
|---|---|
| Studio (the visual editor) | The Studio switch. When off, the Studio menu and pages do not show. |
| The command workbench and Rebuild | Studio, plus spec-first generation and screen compile. |
| Image and URL references | Studio plus Studio's references switch. When off, no vision call ever fires. |
| SIT, UAT environments and promotion | Studio's environments switch. |
| Environment settings | An admin sets how long an idle SIT/UAT lives and how many environments one project may run at once. |
| Studio command check (shadow) | The Studio command check switch. An admin turns it on to measure only: nothing is undone and the customer sees nothing. |
If you do not see a menu or button described here, ask your admin whether it is switched on.
What your app gets
Everything in this part is written by the compiler from the approved form, without AI (except Jarvis answers). Screenshots are from the MindDNA app built on the live system.
The app's dashboard
YouNo AIThe dashboard of the MindDNA app (built on the live system) What you do
- The app owner sees today's numbers and shortcuts to the main jobs.
What the system does
- Built from the summary/aggregate in the form + the dashboard screen recipe.
Where AI helps
This step does not call AI. The system does it all itself.
Thai forms that are compiled
YouNo AIA Thai form that is compiled (MindDNA) Checking the Thai words on screen in the API spec form What you do
- Users fill in data in fields that match the tables.
What the system does
- The input fields, data types and Thai words come from the approved form.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: Right image: the screen-word check page in the API spec form, in Thai.
Privacy (PDPA) comes with every app
YouNo AIThe PDPA privacy page that comes with every app What you do
- Users see and manage their own consent.
What the system does
- The PDPA kit is added to every app automatically.
Where AI helps
This step does not call AI. The system does it all itself.
Everything the app gets
| Capability | What it does | Who does it |
|---|---|---|
| Dashboard | Today / this week / this month numbers, charts, summary | compiler |
| Export to CSV / Excel | Every table that has been compiled | compiler |
| Thai documents | Invoices, receipts, quotations, certificates, with VAT, withholding tax and the amount in Thai words | compiler |
| Excel import | Preview → confirm → can be undone, with Thai-style data checks | kit |
| Scheduled jobs + notifications | Set Thai time · summary → condition → notify by email, LINE or webhook | compiler + kit |
| Data sync | Pull files from a SQL database or object storage and import them (read-only) | compiler + kit |
| Permissions and roles | Choose in the form who sees which table (owner · role · public) | compiler |
| 5 landing page styles | Product · service/booking · community · personal · business (you can choose) | compiler (AI chooses the style when building) |
| Multi-language | Thai and Chinese words on screen | compiler (AI helps make the words when making the form) |
| PDPA | Consent and privacy pages come with every app | compiler |
| AR viewer | View a 3D model and place it in a room on supported phones | kit |
| Motion events | The camera detects a raised hand, a wave, or someone entering or leaving, on the device; no image leaves the device | kit |
| Jarvis, the in-app assistant | Ask by text or voice; tools come from the form · writing data needs a person to confirm | kit + AI (answers go through the gateway) |
Credits, prices and value
1 credit ≈ ฿0.74–1.00, depending on the pack you buy
Your credits
YouNo AICredit balance and top-up packs Credit usage history, and tax-invoice details What you do
- See your balance, buy a top-up pack (big packs get a bonus and free premium kits), see the history, and fill in tax-invoice details.
What the system does
- Top-ups go through Stripe · the history shows every charge and top-up.
Where AI helps
This step does not call AI. The system does it all itself.
Tip: This image is from the demo system, so it shows the message “Billing is not turned on yet”.
Calculate ROI
YouNo AIThe ROI calculator What you do
- Enter the size of the work and the build level, and see the time and money saved compared with hiring a team.
What the system does
- Calculated from standard values an admin can set · there is a page explaining how it is worked out.
Where AI helps
This step does not call AI. The system does it all itself.
Summary: where AI helps
Every step that is not in this table is done by the system without calling AI.
| Step | What AI does |
|---|---|
| Tell your idea | Optional: “Plan First” lets AI briefly interview you before the idea goes to the design rooms (there is a fallback if AI does not answer). |
| Requirements | AI expands the idea into a requirements document (the main model for this job: Claude Opus 5.5). |
| Design with 6 AI rooms at once | This whole step is AI's work: each room thinks from a different angle (screens and usage · architecture · database · API · mobile · security), then another AI merges them. |
| Readiness before building, and style | The 3 style proposals come from the design AI already made (no extra AI call). |
| Brand images, and ask 2 models before deciding | AI creates the images (OpenAI) · Model Duel calls 2 models. Both are optional. |
| The API spec form (the heart of 6GL) | AI classifies once (a low-cost model, with no random variation in its answers). |
| Screens: screen recipes, and kits that can do them instead | The “Words on screen” button writes the Thai and Chinese words for every page (1 AI call). |
| Build the app: backend → frontend → UX/UI → QA → deploy | AI writes only the items that cannot be compiled (developer · UX · QA, depending on the chosen budget) · writes the landing-page text and chooses the template · writes the README. |
| Polish with AI, and Gap Analysis | AI Polish: AI changes things as you ask (credits are charged first) · Gap Analysis: AI finds gaps in the app. |
| Ask in words, add a page, and history | Commands in words: AI makes a plan once, from a list of recipes the system picked out, and you check it before applying. |
| Ask for changes later (Change Council) | AI phrases the request once → 6 AI advisor seats each weigh in from a different angle and summarise the decision → AI writes code to the approved spec. |
| What Reforge is | AI reads the code and maps it · masking secrets, reading the old API's shape and comparing old with new use no AI |
| Ingest and understand | Ingest uses no AI · Understand: 6 AI labs each read one side at the same time (database · API · screens · business rules · sign-in and permissions · outside services), then one spec is merged from them |
| The migration plan, then build the new app | AI writes the migration plan and the new app's design · reading the old API's shape uses no AI · building works like any other build |
| Prove they match — old vs new | The comparison uses no AI · when a case fails, AI suggests the fix but does not apply it; you apply it on the build page or in your own workflow |
| HAR files, run history and data migration | Migration script: AI writes the column mapping and the script, then the system checks its safety before it can be downloaded · reading a HAR uses no AI |
| Reforge DIY: take the repo and port it yourself | The porting guide has a prompt per feature, in the order to do them, ready to paste into your AI · the porting runs on your own subscription |
| Connect rea: rea takes the old app apart, and its evidence goes into Reforge | Taking the old app apart uses your AI client and subscription, not AppForge credits · AppForge uses AI once, to turn the evidence into a design after you approve |
Most screenshots are from the latest AppForge (main) on a DEV machine with demo data (6 Oct 2026), with no real customer data. The part “What your app gets” uses real screenshots of the MindDNA app built on the live system (30 Sep 2026). The time at each step comes from building MindDNA on the live system.