- Vibe coding helps test an idea quickly. Readiness for customers needs separate checks.
- Check the final outcome: a saved enquiry, a confirmed payment and a delivered email.
- The domain and hosting stay in the owner’s account. Back up code and data separately.
- A free review helps decide between improvements, maintenance and rebuilding the necessary part.
Vibe coding means building software by describing what you want to an AI tool in ordinary language. You ask for a website, booking form or customer account, the tool writes code, and you look at the result before asking for changes. It is a useful way to test an idea. Before that software handles real customers, money or personal information, someone needs to check what happens behind the screens.
If you have already built a site with Lovable, Bolt or Cursor and become stuck, start with the specific failure. Are enquiries disappearing? Has a customer paid while their order still says unpaid? Does fixing one page break another? These are problems with outcomes that can be checked. The fact that AI wrote the code does not automatically mean the project needs to be discarded.
What is vibe coding, and where did the term come from?
AI researcher Andrej Karpathy coined the term vibe coding in 2025. In its original sense, the person gives instructions, runs the generated software and follows their impression of the result without looking closely at the code. People now also use the term more loosely for building software through conversation with AI.
The distinction matters to a business. A developer can generate code and then read the changes, examine permissions and run tests. Tests check whether software behaves as expected. Saying that a site was built with AI tells you little about whether that work happened. Useful questions are who can read the data, where an enquiry is saved and how the working version can be recovered.
Lovable and Bolt let people build websites and applications from descriptions in a chat. Cursor is a code editor with an assistant that can change project files. Their capabilities and limitations differ. Business owners, designers, company staff and developers all use this approach. What they share is the ability to turn an idea into something they can try without first writing every line themselves.
Where an AI-built website is a good starting point
A small task with a clear result is a useful first project. A landing page draft lets you examine the offer and the order of its sections before commissioning a complete build. A customer account prototype lets prospective users try the screens and explain where the next step is unclear. Neither exercise needs real payments or a live customer database.
Internal tools can also be suitable: a task list, a report draft or a small calculator. Start with fictional or anonymised records. Calling an application internal does not protect its information if it is reachable from the internet. However, a limited working process is easier to describe, check and hand over for maintenance.
The saving comes from rejecting a weak idea early or clarifying a useful feature without a lengthy development project. It is not a guarantee that any finished product will be cheap. A prototype that helped you make a decision has already done valuable work. The next stage should be assessed against what real users need the service to do.
What needs checking before real customers arrive?
These are possible failure points, rather than a description of every AI-built site. A convincing screen does not prove that the process behind it finishes correctly. Owners can check some outcomes themselves. Other checks require someone who can read code and configuration.
Sign-in, roles and other customers' records
Sign-in establishes who is using the application. A role defines what a customer, manager or administrator may do. Hiding an administration button provides no protection by itself. The server, the part of the software that processes requests outside the browser, must refuse forbidden actions regardless of what the page displays.
Use two test accounts and confirm that each can see only its own orders. Check signing out, reopening a saved account link after signing out and resetting a password. Use your own test records. Ask a developer to test attempts to bypass permissions on a separate test copy.
The database stores the site's records. In Supabase-based systems, row-level security, or RLS, controls access to individual table records. A table exposed through a public interface without suitable restrictions may reveal more than the website shows. Switching RLS on is only part of the job: its rules must match record ownership and the permitted actions.
Secret keys and personal information
An API is a way for one program to communicate with another. A secret API key may allow someone to send emails, spend a service balance or manage an account. Visitors can read code delivered to their browsers, so secret keys belong outside it. Some keys are deliberately public; their presence in browser code does not by itself establish a leak.
Check what information each form collects, why it is needed and who receives it. Avoid extra fields added just in case. The privacy policy should describe the actual handling of information. Where your audience and cookies, small records stored in the browser, require consent, the banner must control when those cookies are enabled. Dismissing a notice is not enough. Applicable requirements depend on the market and the data, rather than on a generic policy template.
Payments and order confirmation
A page saying “Thank you for your payment” does not prove that money arrived. The payment provider needs to send confirmation to the server, and the site needs to verify it. This message is often called a webhook. The order must have the correct amount, currency and payment state. Receiving the message again must not trigger another delivery.
Use test payments to check success, refusal and a buyer closing the browser tab immediately after paying. Also ask what the manager sees when confirmation is delayed. The customer should not be promised a completed order before the system confirms it. An available payment connection helps connect the parts, but the whole purchase still needs checking.
Emails and notifications
A form can display success while the manager receives nothing. Submit a test enquiry, find its saved record and check the destination inbox. Sender configuration, rejection by the email service and spam filtering can affect delivery. If an email fails, the enquiry should remain available for someone to process.
Check password recovery and customer notifications separately. A working contact form does not prove that every email works. Repeat the relevant checks after changing the sender or email service plan. Agree where delivery failures can be seen and who will respond to them.
Google, link previews and mobile speed
Client-side rendering means that JavaScript, code running in the browser, builds the page. Google can execute JavaScript, but loading failures or access restrictions can leave it with an empty shell. A messenger's link preview crawler may not execute that code. Check readable page content, the title, description and preview image.
It would be wrong to say that all Lovable sites are invisible to search engines. Its current documentation describes server-side rendering for newer applications and pre-rendering for verified crawlers on older ones. Check the behaviour again after exporting to a different host. In Google Search Console, inspect a specific page URL rather than relying on the homepage appearing in search results.
Open the site on a phone using a mobile connection, reach the form, fill it in and wait for its result. Large images, unnecessary code and slow requests can make an attractive desktop page difficult to use. Our free check of an existing website can help reveal initial technical problems. It does not replace checks of permissions or payments.
Hosting, the domain and recovery
Hosting is the environment where the published site runs. The domain is its address. Both stay in the owner's account. Confirm that you receive billing and renewal notices and can sign in and recover access yourself. A working business site should not depend on an unrelated contractor's personal account.
Lovable and Bolt offer integration with GitHub, a service for keeping code and its change history. The owner should control the repository, which is the project's file store. But a code copy does not automatically include database records, uploaded files or external service settings. Ask what is backed up, how far back recovery goes and how restoration works. An archive alone is not evidence that recovery is possible.
Growing costs and circular fixes
Credits and tokens measure tool usage, rather than completed features. Lovable uses credits; Bolt documents token consumption. Check your own plan's current terms. Include the running application, email, file storage, payment fees and other connected services when considering ongoing costs.
If “fix everything” removes a necessary form, return to the last working state and describe one failure. Write down the steps, expected result and actual result. After the fix, repeat the connected scenarios too. Version history can help recover code, but you need to establish separately what it does to stored data. Do not approve an unexplained database clear just to make an error disappear.
A practical checklist before launch
Use a published test version with fictional records. Leave a question and a responsible person beside anything unconfirmed. A passing item means you saw the final result, rather than read an assurance in a chat.
The customer journey
- I opened the site on a phone, understood the offer and found contact details.
- I submitted the form using its button and Enter. The enquiry was saved and reached the responsible person.
- Field errors are clear and the information already entered is kept.
Data and money
- Two test customers cannot see each other's records. Account pages are protected after sign-out.
- A developer checked server permissions, database rules and where secrets are stored.
- Test payment success, refusal and a closed tab produce the correct order state without duplicates.
Search and trust
- Key pages open from a direct link, including after a refresh.
- Search readability and a messenger link preview have been checked.
- Contact details are real, the privacy policy matches the data use and cookie consent works where required.
Control after launch
- The domain, hosting and necessary services are in my account, with renewals under control.
- There is a code copy, a separate copy of necessary data and a tested recovery method.
- I understand service costs and know who checks failures after updates.
Skip payment or account checks if the site has neither feature. If customers can see other people's records or payment confirmations fail, pause those functions until they are fixed. Button colours can wait.
Keep it, improve it or rebuild it?
When the current version is enough
If the site does a limited job, checks pass, costs are understood and recovery is possible, AI involvement alone is no reason to rewrite it. For an early prototype, make the boundaries explicit: demonstration records, no real payments and a limited audience. A public landing page can also work on this foundation once its form, speed and search readability have been checked.
When a developer should step in
Bring someone in when you cannot explain where enquiries are stored, who has administrator rights or what confirms a payment. Another signal is having to repair the same failure after each change. Ask the developer to reproduce the problem and define the scope of the fix, then verify the outcome at its destination. For email, that is the inbox. For a payment, it is the order record.
When rebuilding may cost less
Compare estimates for the same outcome: repairing the existing code and rebuilding the necessary part. Rebuilding can make sense when the foundation conflicts with the business process, every change affects everything or the existing version cannot be reproduced. Include data migration, preserving page addresses, checks and launch in its cost. “Rewrite everything” without inspection is no better supported than expecting a chat to fix everything.
How to get help with a site built through vibe coding
Artbrain develops and maintains websites and business systems, including sites built by other developers. We start with a free review of the website and task, then agree an estimate. One-time fixes and improvements cost €45 per hour. Monthly maintenance starts at €200 per month with an agreed scope. Our guide to website maintenance costs explains ongoing work in more detail.
For a vibe-coded project, we first establish whether the code is available and whether we can take it on. We do not provide ordinary maintenance for closed hosted site builders. An exported application is assessed by its technologies, dependencies and required changes, rather than just the name of the tool that generated it.
Send the website link and a short description of the problem or improvement. Include the steps that cause the error and what should happen instead. For a code review, a project export or agreed repository access is useful. Do not send passwords in the first message. The domain and hosting stay in your account.
Request a free website review and an estimate for improvements. Even if you only have a working prototype, a useful starting question is which customer journey needs to reach a confirmed result.
FAQ
What is vibe coding in simple terms?
It means creating software by describing the desired result to an AI tool. The tool writes code, and the person tries the result and requests changes. It helps test ideas quickly, but data access, permissions, payments and recovery need checking before customers use it.
Can a business launch a website built in Lovable or Bolt?
Yes, provided the particular site passes the checks its purpose requires. A landing page and an application accepting payments need different checks. Verify form outcomes, record access, search readability, mobile use and backups. The tool name alone does not establish readiness.
Is an AI-built website safe?
Safety depends on the code, configuration and checks. Server permissions, data access rules and keeping secret keys outside browser code all matter. Automated scans help but cannot guarantee the absence of problems, especially with personal information or payments.
How much does it cost to finish a vibe-coded site?
Artbrain reviews the website and task for free, then agrees an estimate. One-time fixes and improvements cost €45 per hour. Maintenance starts at €200 per month with an agreed scope. We first check code availability and whether we can take the project on; closed hosted site builders are outside our ordinary maintenance service.
Will Google index a vibe-coded website?
The way a website was built does not prevent indexing. Pages need accessible, readable content and appropriate settings. Google executes JavaScript, but errors can prevent access to content. Inspect individual URLs in Search Console and check again after moving hosts. Indexing and rankings cannot be guaranteed.
