A pre-launch checklist

Building in Vorx is fast, which is exactly why five minutes before you publish is worth spending. This is the pass that catches what people otherwise fix in public.

Walk the core flows

Start with the paths your users can't do without, clicked through in the preview as a real person would — not just the screens you happened to be editing.

• Sign up, sign in and sign out all work
• The main task your app exists for can be completed start to finish
• Creating, editing and deleting records behaves as expected
• Empty states look intentional rather than broken

That last one is easy to miss, because you've had data since the first build. Your first real user won't.

Check the data model

• Records connect the way they should — orders linked to customers
• Required fields are required, optional ones optional
• The test data you added while building is fake enough to be obvious, or gone

Confirm authentication and access

If your app has accounts, this is the area most worth a careful second look.

• New users can register and immediately use the app
• Signed-out visitors can't reach pages meant for members
• Each role sees only what it should

Test auth in a fresh session, as if you'd never logged in. Then try navigating straight to a restricted URL. It's the fastest way to find a page you forgot to protect.

Check the things publishing won't do for you

Two of these catch nearly everyone:

• Your live app starts with an empty database. Preview and production are separate, so reference data your app needs — categories, plans, settings rows — must be seeded by the app, not typed into the preview.
• Test keys stay test keys. If a payment or email provider is on test credentials, swap them under Settings → Cloud → Secrets before you publish, not after the first customer tries to pay.
• Pick the address you want in the Publish dialog. You can change the .vorx.live name later, but anyone holding the old link will need the new one.

Polish the content

Small rough edges undermine trust:

• Real page titles and button labels, no leftover placeholders
• Consistent wording and tone across screens
• Links go where they claim to
• The app holds up on a narrow, phone-sized window

Quick prompts for a polish pass:

• "Replace any placeholder text with real copy for a booking app"
• "Make the dashboard readable on mobile"
• "Rename the Submit button to Book appointment"

Publish and verify live

Then treat the live URL as its own check rather than assuming it matches.

• Open the production URL and confirm HTTPS is active
• Repeat one core flow end to end on the live site
• Submit any form that emails someone, and confirm the email arrives
• If you use a custom domain, confirm it resolves

When it all holds up live, you're launched. For what to do next, read Monitor and update a live app.

In the docs: Launch checklist and Environments.