How I Built a Free Website Planning & Preview Studio

When someone approaches me for a new website, the first challenge usually isn't writing code. It's helping them explain what the website should actually do.

A business owner might know they need a better online presence but still be unsure about their pages, messaging, colors, services, or calls to action. A static mood board helps with visual direction, but it doesn't show how those decisions fit together on a working homepage.

That's the problem I wanted to explore with Website Planning & Preview Studio, a free, browser-based tool I built through Web by Mateen.

The idea was simple: turn a rough business idea into an editable website concept before development starts.

1. Start with the decisions, not the design

Instead of opening a blank canvas, the Studio guides users through five planning areas:

  1. Business and brand: name, industry, location, audience, logo, and colors.
  2. Value proposition: services, customer problem, solution, and main differentiator.
  3. Homepage structure: sections to include and the order in which they appear.
  4. Trust and contact: verified business facts, real testimonials, and contact actions.
  5. SEO and export: starting title/description suggestions, a checklist, and handoff files.

Breaking the process into steps makes the choices manageable for someone who isn't a designer or developer. It also gives developers a more useful starting brief than a vague request like “make it modern.”

2. Build the preview around one shared state

The live preview is not a collection of unrelated mockup images. The planning inputs feed a JavaScript-driven rendering flow. When someone changes a business name, palette, service, or section, the preview is rebuilt from the current project information.

At a high level, the approach is:

Form inputs → project state → rendered homepage → live preview.

The source uses functions such as renderSite(), updatePreview(), and renderAll() to keep the visible concept synchronized with the editor. It also switches between desktop, tablet, and mobile preview modes.

One useful lesson: the preview should reflect decisions immediately. Users shouldn't have to export a file or navigate to another page just to see whether a headline or color works.

Because the preview incorporates user-entered content, values inserted into generated markup need proper escaping and validation. That boundary matters when you generate HTML from editable forms.

3. Let the brand guide the design

A particularly useful interaction is logo-based color guidance.

When a user uploads a compatible logo, browser-side image processing samples its colors and suggests a starting palette. The user can still override the primary, accent, text, and canvas colors manually. For supported logo files, the Studio can also suggest a brand name; text detection depends on browser capabilities and available local processing.

This is deliberately a suggestion, not a promise that a logo can always be interpreted perfectly.

The same principle applies to industry-based starting content. The Studio provides an initial direction, but people can edit the copy, replace sample imagery, and choose the sections that belong on their website.

The goal isn't to remove creative control. It's to reduce the friction of getting started.

4. Make a saved draft genuinely useful

A planning tool isn't very practical if someone loses their work when they close a tab.

I used browser-side draft storage so people can save and restore their concepts without creating an account. The implementation uses IndexedDB for drafts that include larger image data, with a limited text-only fallback when richer browser storage isn't available.

Users can also export an editable JSON project and import it later. That makes the handoff less dependent on a single browser session.

I like this approach for an early-stage planning tool because the user can work locally and choose when to share. A saved browser draft is not the same thing as a cloud backup, so downloadable project files remain important.

5. Treat export as part of the product

The output needed to be more useful than a screenshot.

The Studio provides an editable HTML concept, a text brief, a project JSON file, and visual export options such as an image or PDF, depending on browser support.

The exported HTML is a planning concept, not a production deployment; it is intentionally marked noindex, nofollow until a real website is reviewed and built.

This distinction is important. A polished visual preview does not replace accessibility testing, real content checks, asset licensing, security review, hosting, or deployment QA.

For sharing, the Studio prepares material for email or WhatsApp. It does not silently send a message or publish a website on the user's behalf.

6. What building it taught me

Three lessons stood out:

A good tool reduces uncertainty. The most useful feature isn't always the most complex one. Sometimes showing the impact of a small choice immediately is more valuable than adding another setting.

Editable output beats a closed demo. If someone can take a concept to a developer, refine it later, or reuse their project data, the tool becomes part of a real workflow.

Clarity matters more than AI labels. The current Studio uses browser-based interactions and guided starting suggestions; it does not depend on a connected AI generation backend. I would rather be transparent about what works than market a planning preview as an automatically finished website.

Try the Studio

I built this for business owners who need a clearer brief and for designers and developers who want better discovery conversations before the build begins.

You can try it here: Website Planning & Preview Studio.

I'd be interested to hear from other developers: what part of the website discovery process do your clients struggle with most?

— Abdul Mateen, Founder of Web by Mateen