Build and Launch a Website with AI
Adding forms and login to an AI website (2026): a beginner's guide to data storage, backends and managed services
Using a portfolio contact form and private member records as examples, learn where submitted data goes, how authentication and access permissions work, and how to validate the production site with two test accounts.
An AI tool has generated a contact form. Clicking Submit displays “Success,” yet the site owner cannot find the message. Or a member can sign in but cannot see previously saved content after switching phones. In either case, check three things separately: who receives the data, where it is stored and who is allowed to read it.
A contact form and a member area have different requirements. A form usually just needs to deliver messages to the site owner. A member area must also identify the user and control which records each account can view and modify. Start with one small feature, verify the complete path from submission to retrieval, then add the next feature.
| What the visitor needs to do | A starting approach | How to verify it after launch |
|---|---|---|
| View work and click an email contact link | A static website with an email link | The link opens an email client with the correct recipient |
| Submit a message that only the site owner handles | A managed or third-party form service | A submission from the production site appears in the owner's dashboard |
| Sign in to view their own applications or saved items | Authentication and a managed database with access rules | The same account can retrieve its records on another device; another account cannot |
| Route approvals to reviewers or synchronize several systems | Evaluate an application backend or integration service for the workflow | Approvals, failed-operation retries and data destinations have inspectable records |
Web hosting makes pages available to visitors. Form handling, authentication and database storage can come from separate managed services or a single application backend. Whether you need to maintain a server yourself depends on the features and operating requirements. Does an AI-built website need its own server?
Suppose your portfolio only needs visitors to leave an email address and a message. First decide which service will receive submissions, who can sign in to review them and how messages will be handled. For the first version, two fields—email and message—can reduce the effort of filling out the form and make it easier to check that each value is saved correctly.
If the project is already deployed on Netlify, its managed forms can be a starting point. For a static HTML page, enable form detection on the project's Forms page. Ask the website builder to set a unique form name, submission method and detection attributes according to the documentation, then deploy again. The platform must be able to identify the form in the deployment output. For JavaScript-rendered pages or frameworks using server rendering, follow the relevant documentation for the published output and submission method. Netlify form configuration
You can give the following requirements to the generation tool and ask it to list the steps you must complete in the hosting dashboard.
Connect a working contact form to this portfolio, collecting only an email address and a message. Configure submission handling according to the current hosting platform's documentation, and explain where I can view the submitted records. Display success only after the receiving service confirms success. If submission fails, preserve the visitor's input and explain how to retry. List the tests to perform after publishing to production.
Use the production URL to submit a test message with a unique marker, such as “Portfolio acceptance 01,” then open the form dashboard and check the marker and both fields. If email notifications are configured, also check the actual inbox. If the dashboard has the record but no email arrives, investigate notification settings. If there is no record in the dashboard, first check whether the submission was delivered, whether the form was detected and whether the dashboard classified the submission as spam.
Next, submit with a required field missing and check that the page gives a clear explanation. If the site has a custom domain, repeat the same flow on that domain to check the version visitors actually use. Custom-domain setup for an AI-built website
Consider a feature where signed-in users can only view their own applications. Authentication establishes who the current visitor is. Each application must also be associated with its owner, and the server or database must check whether the current account is allowed to access it. The site owner's ability to process all applications should use separate, controlled administrative permissions.
With Supabase, for example, Auth can handle authentication, application data can be stored in separate tables and database row-level security policies can control individual records using the current identity. If the browser calls the data API directly, ask the implementer to check access authorization for exposed tables and configure policies separately for the reads and writes actually required. Saving data must also validate ownership so that users cannot assign records to someone else by altering submitted parameters. Supabase Auth documentation · Row-level security documentation
Putting test conditions in the prompt makes the result easier to verify than asking only for a login box.
Implement real sign-in and sign-out. Signed-in users can create and read their own applications. Signed-out visitors and other accounts must not be able to read an application through either the pages or the data API. Configure server or database permissions for the operations that are actually allowed. Explain where records are stored and how to verify this with two test accounts.
Check the different key types offered by the platform during integration. A Supabase publishable key can be used in the client, while authorization and policies still govern data access. Privileged secret keys and the older service_role keys belong only in a trusted server environment; they can bypass row-level security. Supabase API key documentation
- Sign in as account A, create a fictional record and confirm that it is still readable after refreshing. Sign in as A in another browser and check again to verify access across sessions.
- Sign in as account B in a different browser. Check that B can perform its own operations and cannot see A's record. If records have detail links, open a known link to A's record while signed in as B.
- If the page reads or changes records through a data API, ask the implementer to test A's record directly while authenticated as B. Check the response and confirm that B cannot read or modify A's data.
- Sign out and revisit the member area and a known detail URL. Confirm that both the page and API reject signed-out access as intended.
- If email verification, password resets or third-party sign-in are enabled, test each relevant flow and confirm that its links return to the current production site.
Choose a sufficiently small path for the first launch. For a portfolio, first complete “the visitor sends a message and the owner receives it.” For a member area, first complete “the account can save and retrieve its own records,” then use a second account to check permissions. Keep dated validation results and repeat the same checklist after changing domains, updating forms or modifying the login flow.