Base44 App Before Launch Checklist

Use this Base44 app launch checklist after feature work has stopped and against the exact release you intend to publish. Test with fictional users, marked records, the live URL and realistic phone widths. A pass means the underlying result was verified, not that the interface displayed a success message. If a critical workflow, permission or data check fails, pause launch, repair it and repeat the affected tests.

This is the most practical gate for a Base44 project. Mark every line Pass, Fail or Not Applicable and keep the result with the release record.

Release and ownership details

• Release candidate, publish time and Base44 project are named.
• The previous stable version and revert route are known.
• The business controls the workspace, project and custom domain.
• Owners, collaborators and live-app administrators are listed separately.
• Connected services and their account owners are documented.
• No feature changes will be mixed into launch testing.

Open the current Base44 Version History and understand what a rollback would restore. Do not assume a code or app rollback automatically restores production records created after that version.

Core workflow checklist

List the three to five journeys that make the app useful. Write each as a starting state, user action and verified outcome. Examples include creating a booking, submitting a request, approving a record, inviting a user or producing a report.

• Each journey starts from the route a real user will receive.
• Required fields and invalid input produce clear responses.
• The final record or external outcome is verified independently.
• Cancellation and reasonable mistakes do not corrupt the workflow.
• Repeating an action does not create dangerous duplicates.
• Failure leaves the user with a safe next step.

If no one can agree what the critical journeys are, use a Base44 launch-readiness diagnosis before inviting users.

Production data checklist

• Preview/test data is not confused with published production data.
• Create, read and update operations pass for marked test records.
• Required values, dates, statuses and defaults are correct.
• Records belong to the intended user or organisation.
• Filters and relationships return the expected results after refresh.
• Old or incomplete production records do not crash current pages.
• A supported preservation or export route is understood.

Do not launch if data silently disappears, duplicates, changes owner or appears only in preview. A visible screen is not evidence that the production record is correct.

Signup, login and role checklist

• A fresh ordinary user can complete the intended signup or invitation.
• Verification and first login reach the right landing page.
• The session survives refresh and direct protected-route visits.
• Every real role can perform its required actions.
• One ordinary user cannot access another user’s records.
• Staff cannot reach owner-only settings.
• Sign-out removes protected access.
• Recovery or re-invitation is tested where provided.

Test allowed and denied outcomes. Do not promote users or open entities merely to get a green result.

Public pages and navigation checklist

• The home page and public information work signed out.
• Important routes open directly, refresh and share correctly.
• Menus contain no broken, private or obsolete destinations.
• Browser back and normal navigation do not lose essential state.
• Invalid record links fail safely.
• Public and private areas are visibly and technically distinct.

Test the built-in Base44 URL and custom domain separately. A domain fault should not be “fixed” by rewriting working routes.

Forms, notifications and integrations checklist

• Every important form is submitted on the published release.
• Validation, consent and success messages are accurate.
• The stored record contains the submitted values and correct owner.
• Email, CRM, payment or automation outcomes are verified.
• External failures do not falsely report complete success.
• Retries do not duplicate consequential actions.
• Secrets are stored through supported settings, not prompts or pages.

Use fictional information. Do not put customer records or credentials into screenshots sent for review.

Mobile and browser checklist

• Critical journeys complete at a practical 390px phone width.
• No horizontal scrolling or clipped content blocks actions.
• Menus, modals and fixed elements remain usable.
• Long headings, errors and real content wrap safely.
• The on-screen keyboard does not hide required controls.
• Buttons remain readable and tappable.
• Current browsers can open direct routes and refresh them.

Run this on the published app rather than trusting a scaled editor preview.

SEO checklist for public Base44 pages

• Only genuine public landing pages are intended for indexing.
• Pages open signed out at stable clean URLs.
• SEO is enabled and page-level index choices are correct.
• Title, description and visible H1 are distinct and accurate.
• Pages contain useful business-specific content.
• Canonical, sitemap, robots and preferred-domain behaviour are checked.
• Private app routes, login pages and thin utility screens are excluded.

SEO is only relevant where the project has a public search role. Do not delay a private internal app to optimise pages that should never appear in Google.

Privacy and security checklist

• The current Base44 security scan has been run and reviewed.
• App visibility matches the intended audience.
• Role and record permissions follow least privilege.
• Two-user testing proves private records stay isolated.
• Public forms and errors reveal no internal information.
• Credentials and external accounts are properly controlled.
• The app collects only information needed for the workflow.
• Appropriate privacy information and handling are in place.

Use the fuller Base44 security check when the app holds private or consequential business data.

Support, recovery and rollback checklist

• A named person owns launch and the go/no-go decision.
• User reports have a monitored contact route.
• The team knows how to pause a failed workflow.
• The previous stable version and post-revert tests are documented.
• Important production data has an appropriate preservation route.
• External-service owners and support details are recorded.
• A serious access or data incident has a containment path.

A rollback is not complete until core workflows, roles and production data are retested.

What to document for a developer or repair specialist

Provide the published and preview URLs, release version, exact reproduction steps, affected role, expected result, actual result, last known working time and a redacted error capture. Include the marked test-record identifier and the relevant recent prompt or setting change. State whether the fault appears in preview, live or both.

Do not send passwords, API keys or private customer data. If the fault is still unclear, a structured diagnosis should establish the boundary before a developer changes the project.

Run a timed launch rehearsal

Ask one person who did not build the app to complete every critical journey from the published URL while the owner observes the records and notifications. Use the roles and devices expected at launch. Time the work and record confusion as well as technical failure.

Then exercise the recovery route: sign out, revisit a protected link, correct an invalid form and recover from one controlled external failure. The rehearsal should prove that support instructions and rollback decisions are usable under pressure.

Monitor the first live period

• Check failed forms, duplicate records and integration errors.
• Review login and permission reports by role.
• Watch whether mobile users abandon a critical step.
• Confirm notifications reach the people responsible for action.
• Keep feature changes out of the initial observation window.
• Record incidents against the exact release and route.

Monitoring should respect privacy and collect only what the business needs. Decide in advance which failure triggers a pause or rollback rather than debating it after users are affected.

Final go or no-go decision

Launch only when every critical workflow, data, access and security line has evidence. Separate minor cosmetic improvements from launch blockers so a polished screen does not hide a failed business outcome. Use the Base44 publishing checks for the final live transition.

A controlled no-go is a successful checklist result when it prevents lost data, broken access or a confusing release. Repair the failed item, rerun the affected sections and publish one known version.

Classify failures before the meeting: a launch blocker affects data, access, security or a critical outcome; a major issue harms an important but recoverable journey; a minor issue is cosmetic or low-impact. Do not let several minor passes outweigh one unresolved blocker.

Save the completed checklist, release version, named approver, known limitations and first monitoring time. That record becomes the starting point for support and the next controlled update to the live app.

Share a short launch note with the people supporting users. It should name the live URL, release, known limitations, expected user roles, escalation contact and actions that must not be attempted on production data. Support should be able to recognise a genuine incident without asking the builder to reconstruct the launch.