Build the smallest version someone can actually use

• Define the useful ending before choosing screens or features.
• Keep enough information and working actions for a person to reach that ending.
• Use a manual handoff when it fits the business, and explain what happens next.
• Give your first Build a clear boundary and concrete content.
• Add the next feature in response to a problem you have observed.

A first version can have one page and still ask too much of its visitor. It can also have several screens and do one job well. Page count is a poor way to decide whether an idea is small enough.

Start with the sentence someone should be able to say after using it: “I found a repair service that covers my area and sent the details they need.” That ending gives every element a purpose. A service description helps the visitor decide. A contact action helps them continue. A decorative activity dashboard probably does neither.

Write down who arrives, what they already know, and what they need to leave with. Someone searching for help with a puncture has different questions from a cycling club comparing annual maintenance packages. Choosing the first audience does not commit the business to serving only that audience forever. It gives the first version a coherent job.

Then name the point where the website's work ends and the business takes over. That boundary will shape both the interface and the promise in its copy.

Imagine an independent mobile bicycle mechanic who already handles inquiries by email and agrees appointment times personally.

A useful first website could help a cyclist answer four questions:

1. Do you repair the kind of bicycle and problem I have?
2. Do you visit my area?
3. What information should I send?
4. How will I find out whether you can help?

The page needs the mechanic's actual services, confirmed service area, photographs they may publish, and a monitored contact address. It can explain that the cyclist should send their neighborhood, bicycle type, and a short description of the problem. The action can open an email draft while also showing the address as selectable text.

This version does not need to claim that a slot is booked. The mechanic reads the message and proposes a time. The page should say that the appointment is confirmed only after their reply. An honest handoff makes this small website useful without pretending to be a scheduling system.

Once the ending is clear, examine each proposed feature by asking what happens to the customer without it. Some removals simplify the product. Others break the journey.

The manual reply is still part of the product experience. Decide who reads the inbox and what happens if the inquiry is outside the service area. Only publish a response-time promise the business can keep.

Keep the required information easy to find. Removing pages should not force visitors to guess at coverage, search a photo for a phone number, or click a vague “Get started” button to discover what it does. A smaller site needs precise language.

In Mythos, use Plan when the audience or handoff is still unsettled. It lets you discuss the approach and review a draft before approving implementation. If those decisions are already made, describe the result in Build. The Plan and Build guide explains the distinction.

Prepare the business facts before adapting this request. The bracketed fields are yours to fill; they are not content to publish.

Build a one-page website for [business name], a mobile bicycle mechanic
serving [confirmed neighborhoods].

Audience: cyclists who want to ask whether a repair visit is possible.
Primary outcome: they understand our services and send a useful inquiry.

Use these sections in order:
1. A short introduction and the primary contact action.
2. These services and exclusions: [approved descriptions].
3. Our service area: [confirmed coverage].
4. How an inquiry works and what information to send.
5. Contact details: [monitored address and other approved details].

Use the supplied photographs and this business copy: [content].
The contact action should open an email draft to the supplied address.
Show that address as text too. Ask for neighborhood, bicycle type,
and a short description of the problem.

Explain that we confirm appointment times by reply.
Keep the first version to this inquiry flow, with no accounts,
live booking calendar, payment collection, or invented reviews.
Make the page readable and the contact action easy to use on a phone.

This gives the design room to develop while fixing the business decisions that must remain true. You can judge the first result against a specific outcome instead of an open-ended request for a better website.

The contact action is the most important part to try after the first result appears. An email link opens the visitor's email application when one is configured; it does not send a message itself. Showing the address gives people another way to continue when that action does not suit their device.

Open the page on a phone, follow the link, and inspect the recipient and draft. Send a separate test message and confirm that it reaches the person handling inquiries. Read the instructions from their perspective: do they receive enough information to respond, or must every conversation begin with the same missing question?

If the business needs an on-page form instead, treat it as a deliberate addition. Decide where submissions go, who may read them, and what the visitor sees when sending fails. A success message alone cannot answer those questions. The service-business guide goes deeper into contact paths and the facts to prepare.

Choose the handoff the business can operate today. There is little value in automating appointment requests while leaving nobody responsible for answering them.

Give another person a situation: “Your bicycle has a puncture, and you want to know whether this mechanic can visit.” Let them use the page without explaining where anything is.

Listen for the question that slows them down. If they cannot tell whether their area is covered, rearranging the service-area copy may help more than adding another page. If they expect an immediate booking, the action label and confirmation language need work. If they find the address but do not know what to send, improve the message instructions.

Write down the specific point of confusion, what the person tried, and what they expected. Avoid turning one person's reaction into a claim about all customers. It is a useful lead for the next edit, especially when it exposes something you can reproduce.

Review that edit in Preview using the same situation. A clearer flow should require less explanation from you. For the separate checks involved in putting a site into public use, use the release-readiness guide.

After people begin using the site, keep a short record of the questions that repeat. Useful notes sound like “Several inquiries omit the neighborhood” or “People ask whether we service electric bicycles.” Each suggests a specific response: improve the inquiry prompt, or make the service description more explicit.

A booking calendar earns consideration when arranging times becomes a recurring problem and the mechanic can keep availability accurate. A customer account earns consideration when returning customers need something worth signing in for. Neither needs to be included merely because it is common in larger products.

When proposing the next feature, finish this sentence: “We observed this difficulty, so we will change this step, and we expect people to be able to do this.” Then check the result with the same care as the first version.

The first useful workflow gives you more than a smaller development task. It gives the business something people can use, someone a clear responsibility after the click, and the next decision a basis in experience.

• Writing good prompts
• Building and editing
• Plan vs Build in Mythos
• Build a service-business website with AI
• From prompt to a production candidate