Emergent for beginners: plan your first website

Pick a project with a visible finish line

A one-page consultant website has a clear finish line: visitors can understand the service and send an enquiry. “Build a platform for my business” does not. Write down the audience, the main action, and the essential content. Separate things needed for launch from things you might add later. This brief will help you judge the result instead of changing direction after every preview.

Bring the raw material

Gather your business name, real service descriptions, contact details, and images you have permission to use. Missing information should remain visibly marked as a placeholder. Decide on one tone and a small number of design preferences. A concrete instruction such as “large readable text and one enquiry button” is more useful than asking for something merely modern or premium.

Use the preview as a review tool

Emergent’s published workflow centres on describing a project, inspecting a preview, and refining it through conversation. Check the content and primary action before polishing small visual details. When something is wrong, describe what you see, what you expected, and which screen is affected. Ask for one focused change, then verify it before requesting another.

Move from appearance to behaviour

A form, login screen, or payment button can look complete without working. Identify each external service the site needs and check how it will be connected. Use sample data until those connections and access rules are understood. Before launch, run through the main visitor journey on both a phone and a computer.

Keep a short build record

Save the initial brief, the major changes, and any remaining issues. Record credit usage from your own account rather than assuming a tutorial’s usage will match yours. If you stop for the day, write the next task precisely so you can continue without redesigning the entire project.

A complete first-session plan

Use a small fictional service website for the first experiment. For example, a bicycle mechanic wants customers to understand available repairs and request an appointment. The first version needs a service summary, opening information, an explanation of the repair process, and a request form. It does not need customer accounts, automatic parts inventory, or online payments.

Prepare the business facts in a separate document. Include the name, service area, services, contact method, approved images, and what happens after an enquiry. Mark missing information explicitly. Decide which details are essential for the first draft and which can wait. This preparation makes it easier to judge the output because you know what the page is supposed to say.

Emergent’s Emmy tutorial describes using an assistant to scope an idea and prepare a build prompt before working with a building agent. We use that as documented product context; the exercise below is our own planning example, not a recorded test session. Source details.

Write a brief that can be checked

A useful brief describes the audience, main action, required sections, supplied facts, design constraints, and working behaviour. For the mechanic, the main action is an appointment request. It should not be labelled a confirmed booking because the workshop must inspect availability and repair requirements first.

Read the builder’s questions before approving assumptions. If it asks how messages should be delivered, choose a service you understand rather than asking it to guess. If it suggests accounts or payment features, check whether those are necessary for the stated goal. A feature can be possible without belonging in the first version.

Review the first draft in three passes

First review meaning. Is the business described accurately? Does the main action match the service? Are any prices, testimonials, opening hours, or claims invented? Correct those before polishing visual details. A beautiful page with incorrect facts is not a useful first draft.

Second review layout. Can a phone visitor find the service and request action without opening several menus? Is the text readable? Are images cropped sensibly? Does the page still work with longer real content instead of short placeholder phrases? Ask for focused changes with a clear reason.

Third review behaviour. Submit the form, inspect its destination, check error messages, and follow every important link. Ask which services are actually connected. A success animation is not evidence of delivery. Keep a short list of failures and resolve them one at a time.

Request revisions without destabilising working parts

Describe the page, affected component, observed problem, expected result, and what should remain unchanged. “Fix the mobile menu” is less useful than “At a narrow phone width, opening the menu covers the close button; keep it reachable and preserve the desktop navigation.” The latter gives the builder a target you can verify.

Save a known working point before a substantial change using the project’s available version tools. Record the reason for the change and the result. If the revision breaks a previously working form, you need to know which change introduced the problem. A simple notes document can be enough for a small first project.

Understand preview and published behaviour

A preview is where you inspect the current build. A published deployment is the address visitors will use. Configuration, records, callbacks, and connected services may differ between those environments. Do not assume that a test login or sample record in preview will appear in production.

Emergent’s deployment tutorial documents preview, deployment, and custom-domain configuration. Some numerical charges and interface details in that older tutorial should be checked against current project settings before you act. Source details.

Before publishing, remove sample content that looks real, confirm the form’s production destination, and check required configuration. After publishing, repeat the visitor journey on the live address. Test a direct link to an internal page and a nonexistent page as well as the homepage.

Keep a practical build record

The purpose is to make the next session easier, not to create administration for its own sake. If work repeatedly circles around the same issue, review the underlying assumption. The problem may be missing content, an unconfigured service, or an unclear requirement rather than a need for another broad prompt.

Know when the first experiment has taught enough

You have a useful first result when you can explain the workflow, make a focused change, verify the main action, and identify the remaining costs and responsibilities. You do not need to add every feature to justify the session. A small finished site teaches more than a large collection of incomplete screens.

Choose the next project based on the additional behaviour you want to learn. A booking workflow introduces time and availability. A portal introduces identity and permissions. A store introduces payment and order states. Add one category of complexity at a time so you can understand the new responsibilities instead of treating the builder as a substitute for product decisions.

Your starting prompt

Use this as an editable brief. Replace the brackets with your own details and review the result before connecting real services.

A sensible first session

• Write a brief with audience, purpose, pages, and primary action.
• Generate one small initial version.
• Check the content and mobile layout.
• Fix the most important issue, then review again.
• Save the result and list what still needs connecting.