01 Start here
What Hatch is—and what it is not
Hatch is a desktop app builder for small, self-contained tools tailored to one person or one team's real workflow. It plans the app with you, generates it, runs automated checks, installs it locally and keeps a version history for later changes.
It is
- A no-code way to turn a defined workflow into a desktop app
- A builder for local forms, records, calculations and exports
- A guided process with questions and a blueprint before code
- A sandboxed host for the generated HTML, CSS and JavaScript
- Free, AGPL-licensed software that uses your chosen AI provider
It is not
- A general website, mobile app or server builder
- A cloud database, sync service or multi-user platform
- A way to automate other programs or browse the web
- A guarantee that generated software is error-free
- A substitute for expert review in high-risk work
02 Choose the right job
Where Hatch works best
Strong fits
- Quote or estimate calculators using your own pricing rules
- Job, lead, stock, inspection, shift or maintenance trackers
- Registers, logs, checklists, timers and lightweight CRMs
- CSV organizers, searchable local records and PDF reports
- Tools where one person owns the data and the workflow
Poor fits
- Live multi-user systems with accounts and permissions
- Websites, phone apps, APIs, servers or payment systems
- Apps that scrape sites or continuously sync online data
- Scheduled or background automation while the app is closed
- Medical, legal, financial or safety decisions without review
A good Hatch app has a clear user, a repeatable job, a bounded set of records and an observable result. If the value depends on a live online service, multiple simultaneous users or unattended automation, Hatch is the wrong foundation in its current form.
03 Build flow
What happens after you describe an app
- 01
Describe the job
Say who uses it, what they do, what the app remembers and what it should produce.
- 02
Answer focused questions
Hatch resolves missing fields, rules, terminology and decisions that would materially change the result.
- 03
Review the blueprint
You see the workflow, data and a sketch before generation. Treat this as the contract; mistakes here flow into the app.
- 04
Generate and check
Hatch writes the app, validates it and smoke-launches it with both empty and seeded data. Failed checks can trigger repairs.
- 05
Visual review
A strong vision-capable model judges the running app against the blueprint and can request corrective passes.
- 06
Install, test and refine
Open the shortcut, use realistic records and request precise changes. Versions are append-only, so reverting creates a safe new version.
04 Scope before speed
Pick the smallest build depth that fits
| Depth | Use it for | Questions | Review corrections | Expectation |
|---|---|---|---|---|
| Focused | One core job, few screens and rules | Up to 2 | Up to 1 | Fastest and cheapest |
| Complete recommended | A capable everyday business tool | Up to 5 | Up to 3 | Best starting point |
| Ambitious | More screens, features and edge cases | Up to 8 | Up to 8 | Can take several hours |
The one-minute, roughly twenty-cent example on the home page is a measured small app—not a promise for every scope. Complete and Ambitious builds can run for hours and use substantially more model tokens. A narrow version 1 is usually easier to verify and cheaper to refine than an oversized first attempt.
05 Prompt like the operator
How to get the strongest result
Do not describe a software category. Describe the work as the person doing it: the inputs, rules, sequence, exceptions and final output.
Name the user and job
“One estimator creates residential cleaning quotes” is better than “make a CRM.”
Give the real rules
Include calculations, required fields, statuses, defaults and a representative edge case.
Define the output
Say what success looks like: a PDF quote, filtered list, copied summary or saved record.
Set the scale
Ten records and fifty thousand records imply different screens and controls.
Say what is out
“No payments, customer login or cloud sync” prevents scope drift and false assumptions.
Correct the plan early
Blueprint edits are cheaper and more reliable than repairing the wrong app later.
I run a residential cleaning business and need a quote builder for one person.
A quote records the client's name, property size, visit frequency, base service and optional extras. Price equals the base rate by bedroom count plus selected extras, with 10% off weekly visits.
I need a clear quote summary I can copy and export as a PDF, plus a searchable history of past quotes. I usually have fewer than 500 quotes.
No online payments, customer login or cloud sync.
During questions and refinements
- Answer decisions that change the workflow; use You decide for low-stakes details.
- Read every blueprint section, especially stored data, calculations and “not included.”
- After the build, test with a normal case, an empty case and a difficult edge case.
- Request one precise behavioral change at a time: what you did, what happened and what should happen instead.
- Use real terms from the business. The right labels make the app feel tailor-made even when the workflow is simple.
06 Give useful references
Attachments Hatch can use
You can attach up to five images or text references while describing an app. High-value attachments include a screenshot of an existing tool, a photo of a paper form, a sketch of the desired screen, a sample CSV and a short rules document.
- Accepted
- Images, CSV, TXT, Markdown and JSON
- Limit
- 5 files
- Text read
- First 20,000 characters per file
- Not accepted
- PDF and Excel .xlsx references
07 Model guide
Use the strongest model where judgment matters
Hatch divides the work into roles. This is why a mixed setup often beats paying for the most expensive model on every token.
| Role | What it does | What matters most |
|---|---|---|
| Blueprint | Defines the plan and helps judge the finished app | Reasoning, product judgment and vision |
| Implementor | Writes the actual app from the approved plan | Coding reliability, output capacity and speed |
| Fixer | Applies repairs and later refinements | Instruction following and cost efficiency |
| Final reviewer | Looks at the running app against the blueprint | The strongest available vision model |
Current provider guidance
| Provider | Strongest setup | Balanced setup | Hatch-specific note |
|---|---|---|---|
| Anthropic | Pin Claude Fable 5 for Blueprint/review if your account exposes it; otherwise Opus 5 | Opus 5 Blueprint, Sonnet 5 Implementor, Sonnet 5 Fixer | Current Hatch Auto defaults to Opus 5 / Sonnet 5 / Sonnet 5 |
| OpenAI | gpt-5.6-sol for Blueprint, Implementor and review |
gpt-5.6-sol Blueprint, gpt-5.6-terra Implementor, gpt-5.6-terra Fixer |
Pin these explicitly; Hatch may classify the whole 5.6 family as strong |
| OpenRouter | Use Best + Auto; Hatch assigns strong models throughout | Kimi K3 Blueprint/review, GPT-5.6 Luna Pro Implementor and DeepSeek V4 Flash Fixer | These are Hatch's current stage-specific OpenRouter Auto targets when present |
| Local | A strong vision-language coding model that your hardware can run reliably | Use a cloud Blueprint model and local Implementor/Fixer when possible | If the server exposes one model, Hatch uses it for every stage |
Preset behavior
- Cheapest: smaller clarification and repair models, mid-tier planning and building, with a strong final review
- Balanced: mid-tier clarification and repair, strong planning, building and final review
- Best: strongest available model at every stage
Local model reality
- Hatch warns about models that appear smaller than 20B parameters
- 32B+ is a practical starting point, not a quality guarantee
- The Blueprint role must accept images for visual review
- Local speed and context limits can dominate a large build
Model availability changes. Refresh the provider list before pinning. Anthropic describes Fable 5 as its highest-capability model, Opus 5 for complex coding and Sonnet 5 as the quality/speed balance. OpenAI's current guide positions GPT-5.6 Sol for complex reasoning and coding, Terra for intelligence/cost balance and Luna for cost-sensitive volume. Kimi K3 is a multimodal coding model with long-context and visual iteration strengths. Hatch's other OpenRouter stage choices are implementation defaults from the current app source. See the first-party model sources.
08 Hard capability boundary
What a generated app can and cannot do
| It can | It cannot | Practical alternative |
|---|---|---|
| Use forms, lists, tables, charts and modals | Build a website or phone app | Keep it as a desktop workflow |
| Store records locally | Sync a shared cloud database | Export to a file in a synced folder |
| Open files you explicitly choose | Scan arbitrary folders or disks | Select one or multiple files yourself |
| Save CSV, JSON, text, images and real PDFs through a dialog | Write files silently anywhere | Choose the destination each time |
| Use the clipboard and open links in your browser | Log in or act on a website for you | Prepare content, then open the target site |
| Show notifications while open | Run scheduled or in the background while closed | Show due items when the app opens |
| Use AI when the app has the AI permission | Call other APIs, fetch URLs, scrape or send webhooks | Paste or import data; use AI only where appropriate |
Prepare email text and a mailto: link | Send email, SMS or messages itself | Open a pre-filled draft for you to send |
| Perform calculations, search, filter and canvas image work | Run programs, shell commands or scripts | Keep computation inside the generated app |
09 Know where data goes
Data and privacy
Stays on your computer
- Records saved inside finished apps
- Generated app packages and version history
- Provider keys, held by the operating system credential store
- Local diagnostic logs and build transcripts
Sent to your chosen model
- Your app description and answers
- Attached images and text references
- Blueprint and generated code during review or repair
- Runtime AI prompts from apps that have AI permission
A finished app without AI permission works offline. An app with AI permission needs the connected cloud provider or local model server; its runtime prompt is sent there. Using local models keeps generation local, subject to the behavior and configuration of that server.
10 Keep cost in the formula
How model costs work
Hatch is free and adds no markup. Cloud API usage is billed directly by the provider behind your key. A ChatGPT or Claude subscription does not automatically include API usage.
- The home-page example used $0.16 in model calls on Balanced. It is a measured small build, not a universal average.
- Scope, model prices, retries, attachment size and later refinements all affect total cost.
- Balanced is the default value choice. Cheapest trades planning/build quality for cost; Best applies the strongest model throughout.
- Local models have no per-token provider bill, but use your hardware and can take much longer.
- Hatch tracks reported monthly spend and shows a guardrail, set to $20 by default. Treat it as tracking—not a provider-side hard stop.
- Set a real spending limit with the provider. Runtime AI inside each generated app has its own Hatch-enforced budget, $2 by default.
11 Two export formats
Share with or without Hatch
| Format | Recipient needs | Portability | Important limits |
|---|---|---|---|
.hatchapp | Hatch installed | Small and cross-platform | Import does not recreate the full editable builder project or conversation |
| Standalone ZIP | No Hatch; extract the whole folder | Same OS and CPU architecture as the exporter | Large; runtime AI features do not work because credentials are never bundled |
A .hatchapp import shows the author, description and
requested permissions before installation and runs static validation.
Current exports do not include the app's saved records. Standalone apps
may also trigger unsigned-app warnings from Windows or macOS.
12 Sandboxed, then reviewed
Safety model
Generated apps run with Node.js integration off, context isolation on and a restrictive content policy. They receive only declared capabilities such as local storage, file pickers, notifications or AI. Hatch scans generated files, launches the app in hidden empty and seeded test states, and uses a visual reviewer before presenting it as ready.
What this reduces
- Silent access to arbitrary files
- Shell and process execution
- Unapproved outside network calls
- Obvious startup and rendering failures
What it cannot guarantee
- Every business rule is correctly understood
- Every calculation or edge case is correct
- The interface is accessible to every user
- The app is suitable for regulated or high-risk decisions
13 Current release
Known limitations worth knowing up front
- No direct Google provider. Current connections are Anthropic, OpenAI, OpenRouter and OpenAI-compatible endpoints. A compatible gateway may expose other models.
- No internet except AI. Generated apps cannot fetch APIs, scrape pages, use webhooks or silently connect elsewhere.
- No background or scheduled work. Notifications work only while the app is open.
- No cloud sync or live collaboration. Saved app data is local to one computer.
- Limited build references. Up to five images/CSV/text/Markdown/JSON files; no PDF or Excel reference import.
- Imported apps are not full projects. A shared package does not restore the original build conversation for editing.
- No hosted gallery. Sharing is file-based.
- Unsigned installers and exports. Windows SmartScreen and macOS may display warnings.
- Model access varies. Your provider account, credits, regional availability and rate limits still apply.
- Quality varies. Long or underspecified apps can exceed a model's practical reasoning or output reliability even when token limits are sufficient.
14 When a build struggles
Common fixes
| Symptom | Likely cause | Try this |
|---|---|---|
| No model is available | No valid key or local endpoint | Connect a provider in Settings, refresh models and verify API billing separately from any chat subscription |
| Provider or rate-limit error | Credits, rate limit or temporary provider failure | Check the provider dashboard, wait, then resume or retry; the Hatch project remains local |
| Screenshot is ignored | Blueprint model lacks vision | Choose a vision-capable model for Blueprint and reviewer roles |
| Local build is poor or stalls | Model too small, slow or short-context | Use a larger local model, narrow the scope, or use a strong cloud model for Blueprint |
| The wrong app was built | Ambiguous or incorrect blueprint | Return to the plan when possible; otherwise state one exact mismatch and expected behavior |
| A refinement made things worse | Change affected another path | Revert to the known-good version, then request a smaller, testable change |
| Standalone AI does nothing | Credentials are intentionally excluded | Share the .hatchapp version for use inside a configured Hatch installation |
15 Before you rely on it
A short final checklist
- 01
The app has one clear user and a bounded primary job.
- 02
The blueprint names the right fields, terminology, calculations and exclusions.
- 03
The selected Blueprint model supports images and is strong enough for the scope.
- 04
You tested normal, empty and edge-case records with sample data.
- 05
You verified calculations, exports, deletion and recovery yourself.
- 06
You know whether build material or runtime AI prompts go to a cloud provider.
- 07
The provider—not only Hatch—has an appropriate spending limit.
- 08
The app is not being treated as independently verified high-risk software.
Sources Model guidance
First-party model references
Recommendations above were checked on 09 August 2026. Model names, access and pricing can change; consult your provider before a large build.