Landing pages that assemble themselves from structured choices

A developer named Pranav Sagar built a tool that turns rough product notes into a finished landing page without writing a single word of copy. The project, called jev-pages, runs locally with Python and an optional API key. You type a few lines describing what you are building. The system then asks a fixed sequence of multiple-choice questions. Each answer narrows the design space. Code renders the final page from those selections. Change any choice and the layout recalculates in about two hundred milliseconds.

How the questioning flow works

The interaction follows three phases. First, the tool reads your notes and classifies every line: is this a headline, a supporting point, a bare fact? It asks for the product name, what is being offered, what the page is for, and what should appear before a visitor reads anything. It also asks which facts deserve large type, whether the product has a signature color, and what imagery might be worth photographing.

Second, given that direction, the system presents design decisions: headline and subheadline wording, an overall look, what the opening section stands on, light and depth treatment, typography, motion and color rhythm, opening composition, how points are laid out, an image band, the ending treatment, and which photos to use. Every question is a pick from a fixed set or a yes or no.

Third, a single finishing question: which word in the headline receives emphasis.

The engine then builds the complete page from those answers. Click any earlier choice and the tool re-runs phase two around that constraint, producing a new layout almost instantly.

No generated text, only selected text

The core premise is that large language models are good at picking between options but bad at writing final copy that feels human. Jev never generates prose. It only selects. The words on the page come from your original notes or from a curated library of headlines, subheadlines, and micro-copy that ship with the project. The developer stays in control of voice. The system handles structure, hierarchy, spacing, and visual rhythm.

Running it locally

python3 serve.py

That command starts a local server at http://localhost:8787. A button in the bottom left lets you paste a Jev API key if you have one. On macOS you can also double-click Jev Pages.command. The only dependency is Python 3. No package manager, no build step, no node modules. Without a key the app still works using a simple offline preview that demonstrates the full flow.

File layout and extensibility

The repository is a single HTML file plus a handful of data modules:

  • jev-pages.html – layout, styles, and the interactive logic
  • data/photos.js – photo library and the topics Jev can pick from; add a photo with one line
  • data/looks.js – font families, color palettes, and shape presets for each visual style
  • data/colours.js – product color themes such as peach, matcha, coffee, and others a page can adopt
  • data/examples.js – the example pages shown on the home screen
  • serve.py – local server that proxies page calls to the Jev API

Your API key never leaves the browser except to travel through serve.py to the Jev endpoint. The architecture keeps secrets off disk and out of version control.

Why this matters for developers who ship

Landing pages are a tax on shipping. Founders and engineers spend hours tweaking hero copy, adjusting padding, hunting for stock photos, and wrestling with CSS frameworks. Jev-pages removes the tax by turning design into a series of discrete, reversible decisions. The constraint that every question has a fixed answer set means the system never hallucinates. It never produces a layout that breaks its own rules. The two-hundred-millisecond re-render loop makes iteration feel like a conversation rather than a build cycle.

For teams that already write product notes in markdown or plain text, the tool slots into the existing workflow. Paste the notes, answer the prompts, copy the resulting HTML. The output is a static page with no runtime dependencies. Deploy it anywhere that serves HTML.

Where the project goes next

The data files are plain JavaScript objects. Adding a new visual style means editing looks.js. Adding a product color means editing colours.js. The photo library grows by appending entries to photos.js. Because the rendering logic lives in a single HTML file, forking the project to match a house style is a matter of swapping the data modules and adjusting a few CSS variables. The author has kept the surface area small on purpose. The goal is not a general-purpose site builder. The goal is a focused tool that does one thing well: turn structured notes into a polished landing page without ever asking the developer to write CSS or choose a type scale.