Build a website that needs a server

Use Opportunora to create and refine the pages, then download them and continue in a separate development project. This gives you a starting point for a site that needs accounts, stored bookings, a customer area, or a connection to a private service.

Opportunora generates and publishes static HTML, CSS and browser JavaScript. It does not build or deploy a custom backend for a generated site. The server features, their hosting and their ongoing maintenance become part of your external project.

1. Create the site in Opportunora

Start from the business's company page or deal and choose Generate website preview. In the generation studio, choose the sections and generate the site. See Generate a website for the full walkthrough.

Use this stage to establish the public pages: what the business offers, the content, the photographs and the overall design. A booking button or a sign-in screen can show where a feature will go; it does not make the feature work.

You can generate, edit and download without publishing first. You do not need to connect Cloudflare or set up an Opportunora publishing domain for this workflow.

2. Refine the pages in the editor

Choose Open editor on the Websites screen. Ask for changes to the copy, layout, navigation and mobile presentation. Walk through every page and check the contact details, images and links. See Edit a website.

Write down what the new feature must do before leaving the app. For example:

Visitors can request an appointment with their name, email and preferred date. Save the request so the business can review it later. Only staff may read the requests. Show the visitor a confirmation only after saving succeeds.

That describes the behaviour your next tool needs to implement. A form that looks complete in the preview is still only the interface; check what handles its submission when you add the backend.

3. Download the files and prepare a project

On a desktop, use Download files in the editor toolbar. The generation studio also offers Download all files. Both download a ZIP of the current version, even when the editor is previewing an older version.

1. Keep the original ZIP as a reference copy.
2. Extract it into a dedicated project folder on your computer.
3. Check that the pages and images are present. The home page is index.html, other pages use folders such as about/index.html, and bundled images live under assets/. CSS and browser scripts are usually inside the HTML pages.
4. Preview the folder through a local web server. Your code editor or AI coding tool can help start one. Directory links such as /about/ need that server to resolve them, so double-clicking an HTML file is not a complete check.

The ZIP contains the generated site. It does not include a backend, database, the editor's chat history or earlier versions. Keep the folder structure intact until your development tool has inspected it.

A repository is optional. A local AI coding tool can work directly with a folder if it supports that workflow. Some cloud coding tools and hosting services require a Git repository, so check the tools you choose. A repository records changes and lets you return to a working version; it does not run the site's server.

If you use Git, start a repository in the extracted folder and save the export as the first commit. Connect a private remote repository if your workflow needs one. GitHub's guide to adding an existing local project is one example; another Git host works too. Keep credentials and local environment files out of commits.

4. Continue with your preferred AI coding tool

Open the whole project folder in your chosen coding tool, or connect the repository to a tool that works online. Use whichever AI provider you prefer; it needs access to the files to make changes. Give it the feature description and ask it to inspect the existing pages before choosing an approach.

Server code handles work such as validating submissions, saving shared data and deciding which user may read it. Browser interactions such as menus and filters may need no backend at all. MDN's introduction to the server side explains the distinction.

The amount of new code depends on the feature:

Start with one working feature. Converting every page to a new framework is only useful if the project needs it. A serverless function still runs server code; the hosting provider manages the servers for you.

You can begin the conversation with:

This folder is a static website exported from Opportunora. Inspect its pages, styles, scripts, images and links. I want visitors to request an appointment, save the request, and let only staff review it. Suggest the smallest suitable implementation and explain any services it needs. Preserve the existing design and URLs where possible. Then implement one complete working flow, including server validation, access checks and useful error messages. Keep secret credentials on the server. Document how to run it locally, test it and deploy it independently of Opportunora.

Replace the appointment example with your own requirement. Ask the tool to include setup commands, required environment variables and deployment steps in the project's README. External AI usage and hosting are arranged separately from your Opportunora workspace.

5. Test and launch on separate hosting

Choose hosting that supports the server language or framework you added. It must also support any database, file storage or background work the feature needs. Uploading the original ZIP to static hosting alone will not run the new server code.

Before connecting the public domain:

1. Run the project locally and test the whole flow. For the appointment example, submit a request, check that it was saved and open it as a staff user. Also check invalid input, failed requests and access while signed out.
2. Create a separate hosting project and any required services. Set production secrets in the host's environment settings, outside the public site files.
3. Deploy using that host's instructions, through a connected repository or another upload method it supports. Apply any required database setup.
4. Test the deployed address, including direct links to inner pages, images and the server feature. Check that saved data survives an application restart or a new deployment.
5. Connect the domain using the new host's instructions and verify HTTPS. If an older site is live, test the replacement before switching its address.

Launch this project through your external host. Opportunora's Approve & publish publishes the static version stored in the app. It cannot deploy the server code you added outside it. Use a separate hosting project even if you stay with the same provider: Opportunora rebuilds its managed publishing project from app data, so manual additions there can be replaced.

Continue making changes in the external project and deploy updates through its host. There is no repository sync or project import back into Opportunora. Downloading again gives you the app's version, so compare any later page edits before copying them into your extended site.

For a client handover, record who owns the hosting and service accounts, who pays for them, and who handles updates, backups and support.