From prompt to a production candidate: a release-readiness guide
A generated app can become a verified candidate quickly. Production readiness begins after that, with product, security, data, operational, and ownership evidence.
Quick answer
A delivered Mythos website or app is a candidate for review. Its required TypeScript and Vite build checks establish that the source can build. The verification section below explains the limits of browser checks.
Choose a release path that matches the product. For a static portfolio or landing page, review its content, links, forms, mobile layout, metadata, and published URL. An app that stores private records also needs persistence, access, configuration, and recovery evidence. Record what passed for the exact version you intend to publish; a finished Preview alone does not decide readiness.
Separate prototype, candidate, and released service
Teams lose rigor when they use “app” for three different states:
| State | What it proves | What it does not prove |
|---|---|---|
| Prototype | The concept and interaction can be demonstrated | Durable data, real authorization, or reliable operation |
| Verified candidate | The reviewed version passed Mythos’s required type and build checks, plus any available rendering checks | Complete release readiness or production operation |
| Released service | A chosen version is serving in the intended environment | Ongoing reliability, security, or product correctness |
A beautiful Preview can still be a prototype if records disappear on refresh or actions are simulated. A candidate can contain real source and build successfully while still lacking deployment configuration, safe data migration, monitoring, or required policy review. A released service can regress later as dependencies, traffic, data, and providers change.
Choose the sections you need:
| Your project | Start with | Add when applicable |
|---|---|---|
| Static portfolio or marketing site | Content accuracy, every navigation and contact link, keyboard/mobile review, page titles, descriptions, and the published URL | Real submission and delivery checks if a form collects information |
| Interactive prototype | Sample-data labels, realistic states, and the complete demonstration path | A separate backend implementation before relying on saved data or roles |
| App with shared or private data | The product-path, source-review, configuration, and release sections below | Provider, backup, access, and recovery checks for each real dependency |
A static site does not need a database checklist simply because the same builder can create an app. Conversely, adding sign-in, payments, or shared records changes the work required before release.
Choose Plan, Build, or direct editing deliberately
Use Plan when release-relevant decisions are unresolved: who can access the app, which data is authoritative, what happens during provider failure, or which environments exist. Plan is read-only and produces an editable draft; approval passes the exact accepted version to the normal Build path.
Use Build when the change and acceptance criteria are settled. A Build creates and checks a candidate before delivery while the current Preview remains available. Manual code editing is available with an active paid workspace subscription; a manual save does not start an AI Build. Check the current plan features and editor documentation if that is your intended path.
This prevents a risky pattern: asking the generator to invent policy while implementing it. Product, legal, and security decisions should be visible inputs, not accidental consequences of generated code.
Use a candidate prompt with release evidence
The following prompt is for an existing data app with its backend already connected. For a new project that still has sample records, complete the separate backend implementation first. For a static website, use the narrower checks in the table above.
A release-oriented request should describe the critical path and its boundaries:
Prepare a production candidate for the existing support-request app.
Critical path:
1. A signed-in customer creates a request.
2. The request persists and appears in their history.
3. An authorized support agent changes status and replies.
4. The customer sees the updated state.
Preserve:
- the existing stack, auth boundary, routes, and visual system;
- unrelated project workflows and data contracts;
- server-only configuration outside client bundles.
Acceptance:
- empty, loading, validation, server-error, success, and retry states are clear;
- unauthorized users cannot read or mutate another customer’s request;
- duplicate submission and stale-update behavior are explicit;
- desktop and mobile keep the primary action reachable;
- the repository builds from a clean checkout using documented configuration;
- report any simulated service or missing production dependency honestly.
Do not publish, deploy, create paid resources, or substitute mock persistence for
the requested durable behavior.
This prompt does not ask Mythos to declare the app ready for production. It asks for a candidate whose behavior and remaining assumptions can be inspected. Adjust the path and risks to your app; do not copy controls that are irrelevant.
Understand what Mythos verifies
Before a Build becomes the current version, Mythos checks the TypeScript project and creates a Vite production build. When browser verification is available, it also renders the app at desktop and mobile sizes. A real page failure blocks delivery; if the browser check itself could not run, treat those viewports as unverified and test them separately.
These checks can catch invalid types, missing imports, build-time incompatibilities, and visible layout failures in the tested viewports. They are useful evidence, but they do not establish:
- complete route and browser coverage;
- server-side authorization for every data operation;
- vulnerability, dependency, or secret review;
- real external-provider behavior;
- data migration safety, backup, or restore;
- performance under representative traffic and data volume;
- complete accessibility conformance;
- product, legal, or compliance acceptance.
Treat the checks as one part of the release review. Keep the evidence they provide, then test the risks that depend on your users, data, providers, and operating environment. Building and editing explains the user-visible Build lifecycle.
Prove the critical product path
Write one path that represents the product’s value, then exercise it from the user boundary. A task manager might use sign in → create task → assign → change state → reload → verify. An internal approval tool might use submit → review → request correction → approve → export.
For every step, test:
- empty: there is no record yet;
- loading: the request is pending or slow;
- invalid: client and server reject bad input without losing valid work;
- unauthorized: the wrong identity cannot complete the action;
- failure: the server or provider rejects or times out;
- success: state persists and is visible after refresh;
- repeat: duplicate clicks or retries do not create unintended effects;
- stale: another session changes the same record first.
Use realistic content density and long values. Repeat at a representative mobile viewport and with keyboard navigation. A screenshot of the happy path is useful design evidence, not a product-path test.
Record the source revision and environment with the result. A test against one Preview cannot silently qualify a later revision.
Run a focused source and security review
Read the source as if the original prompt were unavailable. Routes, components, data access, and configuration should use normal project conventions and names a future maintainer can follow.
Review the boundaries most likely to create harm:
| Boundary | Questions |
|---|---|
| Authentication | Which requests require a verified identity? What happens when the session expires? |
| Authorization | Does the server enforce ownership and role checks for every protected read and mutation? |
| Input | Are external request bodies, provider responses, and persisted values validated? |
| Secrets | Can any private key, token, or server credential enter client code, logs, commits, or error messages? |
| External effects | Are emails, payments, deletes, and provider mutations idempotent or safely fenced? |
| Dependencies | Are versions reviewable, licensed appropriately, and free of known unacceptable risk? |
| Error handling | Does failure stop explicitly, preserve user work, and avoid leaking sensitive detail? |
Do not infer authorization from hidden buttons. Attempt protected operations as the wrong user through the actual server boundary. Do not retrieve secret values merely to “check” them; verify references, bindings, and exposure paths.
Prove a clean checkout can continue the work
For an independent source review or handoff, connect GitHub or download the project ZIP, then validate it outside the current workspace. Both features require an active paid workspace subscription; see pricing. Your code ownership is separate from access to those product features. A clean-checkout review is especially useful when another developer will maintain or host the app.
Use the repository’s documented runtime and inspect its scripts before running them:
git clone <private-repository-url>
cd <repository>
npm install
npx tsc --noEmit
npm run build
The exact commands depend on the generated package. Current Mythos projects use Vite, React, Tailwind, and TypeScript, but you should still read package.json instead of assuming every script name. A generated template may not yet contain a lockfile. Review the first dependency resolution, commit an intentional lockfile, and use npm ci only after that lockfile exists and matches the manifest.
Confirm that a new maintainer can identify:
- the supported runtime version;
- install, typecheck, build, and start commands;
- required public and server-only configuration names;
- the source of migrations or seed data;
- how to reproduce the critical path;
- which services remain simulated or owner-managed.
If the app only runs inside the original workspace, the handoff is incomplete.
Treat configuration and data as separate deliverables
Source alone does not recreate a service. Inventory configuration by name, purpose, environment, owner, and whether it may be exposed to the browser. Keep secret values out of the repository, chat, screenshots, logs, and build arguments. Use provider-native secret references or environment bindings.
For data, document:
- the authoritative database or service;
- schema and migration history;
- seed or fixture policy;
- backup and restore procedure;
- retention and deletion rules;
- ownership of external provider resources;
- rollback compatibility between old and new application revisions.
Never test a candidate by copying production secrets or user data into an uncontrolled environment. Create independent development credentials and synthetic data. A source revert cannot reverse a destructive migration or an external side effect, so design those operations with explicit recovery.
If the candidate uses sample data, label it. If a connector or backend is still required, state that dependency as a release blocker instead of swapping in browser storage and calling the path complete.
Make an explicit release decision
Summarize evidence in a matrix that a reviewer can challenge:
| Area | Required evidence | Result |
|---|---|---|
| Candidate identity | Exact source revision and artifact under review | Pass / fail |
| Product path | Recorded critical-path and failure-state results | Pass / fail |
| Authorization | Negative tests at the server boundary | Pass / fail |
| Build | Clean-checkout install, typecheck, and production build | Pass / fail |
| Configuration | Named variables, owners, and secret boundaries | Pass / fail |
| Data | Migration, backup, restore, retention, rollback plan | Pass / fail |
| Operations | Monitoring, alert owner, runbook, rollback action | Pass / fail |
| Accessibility | Keyboard, semantics, contrast, and target review | Pass / fail |
| Residual risk | Named limitations accepted by an accountable owner | Accepted / blocked |
Not every prototype needs every production control, but every release needs controls proportional to its users, data, money, and blast radius. Mark “not applicable” with a reason; do not mark an untested area as passed.
Publishing or deploying is a separate explicit action. Verify the released revision and critical path in its real environment after that action. A Git push, build log, or old smoke test is not evidence that the intended production revision is serving now.
When not to release this candidate
Do not release when critical behavior relies on mock persistence, when authorization is only visual, when required configuration is unknown, or when there is no recovery path for data-changing operations. Stop if the exact source under review cannot be identified.
Delay public or sensitive use when the app’s risk requires independent security, privacy, accessibility, legal, or compliance review that has not happened. A generated candidate can accelerate implementation; it cannot waive those responsibilities.
Do not treat this checklist as universal certification. A static marketing site, an internal finance tool, and a consumer health application have different threat models and operational duties. Add domain-specific evidence and accountable reviewers.
FAQ
Why call it a production candidate?
Because the source has passed the delivery checks, while release-specific decisions still depend on the product. A static portfolio and an app handling private records need different evidence; use the project table above to choose the relevant checks.
Does Mythos run a real production build?
Yes. Every delivered candidate passes TypeScript and a Vite production build. Mythos also runs desktop and mobile browser checks when that verification is available. That does not cover every user path or external service.
Can I use the Preview as release evidence?
Use it for the exact UI and behavior you observed. Also test clean-checkout reproducibility, server boundaries, configuration, data, and the real released environment.
Should I connect GitHub before release?
GitHub is optional for publishing a site with Mythos. It is useful when you need independent maintenance, a source handoff, or another hosting path. GitHub connection, synchronization, and project ZIP downloads require an active paid workspace subscription; pricing lists the current features. Test a clean checkout before relying on the handoff.
What if a Build fails?
Before delivery, the current version remains available. Billing depends on how the Build ended: a platform failure before delivery normally returns credits, while choosing Stop after AI work has begun keeps the fixed charge. Diagnose the reported failure; do not lower important acceptance criteria merely to obtain a green candidate.
Does a release checklist guarantee there will be no incidents?
No. It improves decision quality and traceability. Production operation still needs monitoring, response ownership, maintenance, and learning from real behavior.
Sources
Current Mythos documentation used for product behavior:
- Building and editing
- Plan mode
- Workspace editor
- GitHub integration
- Version history
- Writing good prompts
- Troubleshooting
The wider release matrix is editorial guidance. It is not a certification or a claim that Mythos performs every listed review.
Last updated
