Test a task, not just a picture
Write the visitor's journey before testing. For the cleaner: open Home, find a service, reach Contact, and use the approved contact method. Open every page directly, refresh it, and test Back and Home. Use both a computer and phone. Ask someone unfamiliar with the site to complete the task without coaching. Record where they get stuck instead of assuming they are doing it wrong.
Check success, failure, and permission
A real form needs tests for valid input, missing fields, delivery failure, and repeated clicks. Confirm the result at the actual destination, such as the owner's inbox or authorized request list, using harmless pretend information. If sign-in exists, test signed-out access and accounts with different permissions; the owner view alone proves little. Test payments only through supported test mode and check the provider's records. Do not describe an unconnected or demo feature as verified.
Troubleshoot one observable problem
Write the page, device, steps, expected result, and actual result. A useful report is 'On my phone, tapping Contact in the open menu does nothing; I expected the Contact page.' Ask the builder to investigate that specific behavior. If there is an error message, copy only non-private parts. Never paste credentials or customer records. Try the same steps after the fix and check nearby features too. If the cause remains unclear, pause the feature and use official support or qualified help.
Common beginner mistakes
Publishing before checking all links leaves visitors stranded. Keeping sample phone numbers or invented reviews makes the business look dishonest. Adding accounts or payments before there is a need creates extra responsibilities. Treating a green success notice as proof of delivery hides failures. Changing everything at once burns time and can use more credits. Assuming GitHub is a complete backup risks losing records. Slow down: finish one small reliable journey first.
Understand costs and credits
Check Lovable's current pricing and workspace usage before building. Credit allowances, refill or rollover rules, and feature access can vary by plan and change. Ask a question before launching a large change, keep requests focused, and inspect usage after work. Building credits are not the only possible cost: domain renewal, Cloud usage, email, external services, and payment-provider fees may be separate. Make a monthly cost list and set supported usage alerts or limits where available; do not assume an alert caps every bill.
Publish only an approved real version
Keep this course's practice website unpublished. For a real business site, review content, permissions, contact destinations, phone layout, security, and ongoing costs before approving Publish. Use the current official publishing steps, then visit the actual public address and repeat the journey. Check that old drafts and sample details are not visible. Publishing makes pages available; it does not guarantee search visibility, customer traffic, accessibility compliance, or business results.
Maintain the site in small regular checks
Choose a review routine you can keep. Check contact delivery, broken links, service descriptions, renewals, costs, and who still has access. Repeat key tests after a substantial change or connected-service update. Keep approved images and recovery information organized. Remove unused accounts and connections, and use two-factor authentication where offered. A custom app needs continuing care; if that is too much, simplify features or seek qualified help rather than leaving a risky feature running.
Example prompts to copy and adapt
Replace [BRACKETS] with approved details. Use pretend information for practice, never passwords or customer records.
Full beginner test plan
Create a manual test plan for [SITE PURPOSE]. Cover each page, menu, Back/Home links, phone layout, keyboard use, forms with valid/missing input, real destination read-back, failed requests, signed-out and different-role access if relevant, and payment test mode if relevant. Distinguish working connected features from demo or unconnected features. Do not publish or use real customer details.
Focused repair
At [PAGE], on [DEVICE/BROWSER], these steps [STEPS] produce [ACTUAL RESULT] instead of [EXPECTED RESULT]. Investigate and repair only that behavior. Preserve [WORKING FEATURES]. Tell me how to repeat the test and any unresolved issues. Do not publish.
A real-world example
The practice cleaner's site passes the menu test but still has no sending form. That is fine because Contact honestly says no requests are accepted. A later real form is not finished until a test request arrives where the owner can read it and an unrelated visitor cannot see it.
Steps to take
- Write and run the practice site's full visitor journey.
- Ask someone else to repeat it and note one confusing point.
- Locate current pricing and list build, hosting, domain, and service cost types.
- Exercise: write a maintenance checklist with a review date and person responsible.
- Keep the practice unpublished; record any feature you could not verify.
Testing and maintenance check
This checklist is optional and not saved. Copy it to keep a personal note. Do not enter sensitive information.
Go deeper in related modules
Not sure what a word means? Check Business Words Made Simple.
Official provider guides
Independent resources, not P.E.A.C.E. partners or recommendations. Check current terms before buying.
- Publish an approved site (opens in a new tab)
Follow current controls and verify the actual public version.
- Lovable current pricing (opens in a new tab)
Check today's allowances, feature access, and terms; this lesson promises no fixed price.
- Lovable frequently asked questions (opens in a new tab)
Use official guidance and support for product-specific questions.