← Learn & CreateCreate & launch

From an idea to a useful first website.

A beginner checklist that starts with the visitor, limits the first release and makes contact, privacy and launch tests part of the work.

Authorship: original AI-assisted AFTERHOURS draft. Technical/editorial review: 28 October 2026. Independent expert and legal review: not performed. Examples are illustrative, not research findings or personal testimony.

Choose the visitor before the platform

Write one sentence: ‘This site helps [a person] do [a useful thing].’ For a small portfolio, that might be helping a potential client understand your work and contact you. For an educational resource, it might be helping a learner complete one exercise. A first release can be small without being unfinished.

Your outcome is a usable checklist and one primary visitor action. Platform, budget and dates are constraints to work within, not guarantees of business demand. Do not assume that publishing creates an audience or revenue.

Draft the smallest complete journey

Write the first-screen invitation, the explanation a visitor needs, and a working next action. Give navigation plain labels. A beginner release often needs Home, About and Contact plus the specific page that delivers its value; do not add empty departments to appear established.

MDN's first-website guidance recommends planning content and design before building. Sketch the journey on paper, then test whether another person can explain what the page does without your introduction.

Case study, limited to this project's evidence: AFTERHOURS has two direct external game destinations and website-only supporter cosmetics. The website explains that game accounts and website purchases are separate. That boundary is an implementation fact, not a story about traffic, growth, profits or a founder's private circumstances.

Choose tools using requirements and real costs

For a simple information site, compare a hosted builder, a CMS such as WordPress, or a static site with suitable hosting. If you need accounts, database records and protected delivery, evaluate those capabilities explicitly. Consider maintenance, exports, accessibility, platform limits and total recurring costs as well as the first editor screen.

Runable describes hosted website building and custom-domain support. It is relevant if you want to build and iterate a website with managed infrastructure. Review its current pricing and product limits before choosing it. It is not universally the best option, and this guide does not claim free-forever service, commission rates or guaranteed savings.

AFTERHOURS uses Runable's managed stack, database and auth; the external games and Yoco remain separate providers. Portability needs planning around those dependencies. Choosing a builder does not remove your responsibility for content, testing, legal disclosures or reliable delivery.

Make privacy and delivery real

List the information each form collects, why it is needed, where it is stored and who can access it. Collect less when possible. Use a working contact route and say whether submitting actually sends an email or only saves a message. Review requirements that apply to your users and business; this is not legal advice.

If selling a download, create and test the files first. State formats, licence, price, support, refund process and delivery time. Establish the receiving account and verify payment before granting access. A redirect or receipt claim is not proof of payment.

Avoid ads beside forms or controls. Advertising approval and a suitable consent setup are separate from placing a script. Test mobile loading before adding more third-party scripts.

Check the release, not just the screenshots

Use the free launch planner to create an editable checklist. Then record evidence for each task. Test links, forms, keyboard access, small screens, errors and recovery. Keep backups and know how to reverse the release without deleting new customer records.

W3C's Easy Checks are a preliminary accessibility review, not certification. Google's Core Web Vitals guidance distinguishes lab tests from real-user measurements; a fast local test does not establish good performance for every visitor.

Publish only once the core journey works. Over the next month, observe useful visits, completed tool results and actual purchases after refunds and costs. Keep assumptions separate from measurements.

  • Write the audience, purpose and one visitor action.
  • Draft original content and check rights and factual claims.
  • Choose a maintainable platform within the real budget.
  • Test navigation, keyboard access and 360px layouts.
  • Review privacy, contact, payment and delivery requirements.
  • Record mobile performance and check metadata and sharing.
  • Back up, verify the release and document rollback.

Sources and further reading

Provider and reference pages checked on 28 October 2026. Some research is older; its date is not rewritten as new evidence. Linked claims are qualified in the guide.

Build your free launch checklist →

Preview the optional Focus & Create Pack