Relume, sitemaps and wireframes from a library

Relume, sitemaps and wireframes from a library

Relume does one thing, and it does it exactly where website projects usually stall: it turns a description of a company into a sitemap, and the sitemap into wireframes for individual pages, assembled from ready made sections.

Worth settling immediately what this is not. It is not a tool for designing appearance, since the wireframes are deliberately raw. Nor is it a code generator in the ordinary sense, although export exists. It is a tool for the phase before design, meaning deciding how many pages there will be and what goes on them.

Where the real value sits

Worth naming concretely, since marketing suggests something broader than the tool actually does.

The biggest time sink on a company website is neither design nor coding. It is deciding which pages should exist at all and in what order a reader should meet the arguments. That conversation can drag on for weeks, because it happens in the abstract: with nothing on screen, every participant holds a different site in their head.

The tool shortens that phase by giving something concrete to criticise within minutes. A sitemap with twenty pages, generated from a description of the business, is imperfect and works precisely because of it: the discussion stops being about imaginings and starts being about a specific list.

The same applies to wireframes. A page layout assembled from sections that genuinely exist shows proportions and order, and along the way rules out ideas impossible to build in reasonable time.

Beyond that phase the value drops. Refining appearance needs a design tool, and building a working site needs something else entirely.

The section library

The tool's core is a library of over a thousand ready sections: headers, feature grids, pricing tables, testimonials, footers. The sections exist in three forms: for the design tool, for the site building platform, and for React.

That is simultaneously this approach's greatest strength and its greatest limitation.

The strength is coherence. Every section comes from one system, so a page assembled from them looks like a whole rather than a collection of pieces. Colour variables and the spacing scale map across forms, so a wireframe carried into a design tool keeps its proportions.

The limitation is that you get a page built from recognisable elements. Somebody who has seen a few sites made with this tool will recognise the next one. On a company site, where legibility matters, that is no problem. On a product meant to stand out, it is.

The practical route: treat the output as a skeleton to rework rather than a design to ship. Changing typography, colours, and a few layouts suffices for the result to stop looking like a catalogue.

Export and what follows from it

Export exists to three destinations and differs in quality enough that knowing what you are reaching for matters. It also differs in availability by plan, which at purchase time often matters more than quality itself: the free tier gives export to the design tool alone, and the lowest paid plan unlocks all three destinations at once, React included. Higher plans add no further formats and merely lift the project and page limits, so code export is no reason to climb past the first paid step.

Export to a design tool is what this tool was built around. You receive layers, components, and variables, so further work proceeds normally.

Export to a site building platform gives working code with responsive behaviour preserved. That route makes sense if you work in that platform and none at all if you do not.

Export to React is what technical teams ask about, and here precision is needed. The components use Tailwind, so they fit a typical stack, while this is not a component system you add as a dependency. It is code to copy and rework, much like with shadcn/ui, with the difference that there the code is designed for copying and here for carrying over from a graphic design.

The practical consequence: a team working in Next.js gets structure and layout from this above all, rather than a ready component layer. The value is real and narrower than the description suggests.

A sensible way to work with that code is reworking it once, on first use, into a component with props rather than pasting the same section across four pages.

type HeroProps = {
  heading: string
  description: string
  cta: { label: string; href: string }
}

export function Hero({ heading, description, cta }: HeroProps) {
  return (
    <section className="flex flex-col gap-4 px-6 py-16 md:px-12">
      <h1 className="text-4xl font-semibold">{heading}</h1>
      <p className="max-w-prose">{description}</p>
      <a href={cta.href} className="w-fit rounded-md px-4 py-2">
        {cta.label}
      </a>
    </section>
  )
}

That single operation decides whether, six months on, changing the spacing in the opening section is one edit or four. The export gives you layout, while component boundaries are yours to draw, because the tool does not know what repeats across your site.

The sitemap as a project document

Worth spending a moment on what appears first, since it gets treated as a by product and is the most durable result of working with this tool.

A sitemap is not a list of addresses. It is a decision about how many threads exist, how they divide, and which way a reader travels. A good sitemap answers why a given page exists rather than merely that it does.

The tool generates one quickly and usually with excess. That is the right behaviour, since removing is easier than inventing, and an over long list shows possibilities nobody thought of. The work starts with shortening.

Three questions deserve asking while reviewing the output. Does this page have its own reason to exist, or is it a section of another pulled out separately. Will anybody search for it, or will they only arrive from the menu. And does its content have an author, since a page with no text is worse than no page.

The last question eliminates the most entries and gets asked least often. A sitemap with twenty pages looks solid until somebody has to write twenty texts, and then it turns out six will appear and the rest stay empty.

Maintain that document outside the tool, since it outlives the project. On every later change to the site, the question of what exactly is here then has a ready answer.

An ordinary file in the repository suffices, holding beside each address the page's reason to exist and the person responsible for the text.

pages:
  - path: /
    goal: Explain in five seconds what we do and for whom
    text: Anna
  - path: /pricing
    goal: Answer the cost question without contacting sales
    text: Anna
  - path: /case-studies
    goal: Proof we have done this in this industry before
    text: Mark
  - path: /about
    goal: Credibility on larger orders
    text: none

That last row matters most and shows up in every such list. A page with nobody assigned usually never gets written, so it is better removed now than left empty for a year.

The same file then has a second use that tends to be forgotten. A list that has been through the pruning is a ready source for the search engine sitemap, so it need not be typed out a second time.

import type { MetadataRoute } from 'next'

export default function sitemap(): MetadataRoute.Sitemap {
  return [
    { url: 'https://company.com', changeFrequency: 'monthly', priority: 1 },
    { url: 'https://company.com/pricing', changeFrequency: 'monthly', priority: 0.8 },
    { url: 'https://company.com/case-studies', changeFrequency: 'yearly', priority: 0.6 },
  ]
}

Treat the priority and frequency values as a hint rather than an instruction, since search engines need not honour them. The real value here is enumerating the addresses at all, particularly those no menu link leads to.

Wireframes versus graphic design

Separating those two is the heart of the process where this tool makes sense, and it deserves describing, since they get confused.

A wireframe answers what is on a page and in what order. A graphic design answers how it looks. Mixing those questions turns a conversation about structure into a discussion of button colour before anybody settled whether that button is needed.

The rawness of wireframes is a design advantage here rather than a shortcoming. A layout stripped of colour and photography forces attention onto proportion and hierarchy, the things deciding a page's effectiveness more than aesthetics.

The practical consequence concerns showing them to a client. Presenting a wireframe requires saying up front what it is, otherwise the first reaction concerns its being grey. A sentence explaining that this conversation is about content while appearance comes later saves that entire round.

The last item: freeze the wireframe before moving to design. Structural changes introduced while working on appearance cost several times more, since each drags a rework of something that already looks finished.

Relume against the alternatives

These tools rarely compete, since they serve different moments. A sensible arrangement for a company site: structure and wireframes here, appearance in a design tool or directly in a publishing tool, code in whatever the team uses.

The last row deserves honest consideration. If the site is meant to differentiate rather than merely inform, ready sections work against you. Faster does not mean better when standing out is the goal.

Note too that a sitemap alone requires no tool. A list of pages in a document does the same thing, only it reads worse. The value appears with wireframes, where proportions and order become visible.

Pricing and the entry threshold

The tool runs on a subscription and bills per person rather than per team. Every plan carries two rates, since annual billing runs thirty percent below monthly, and that gap is what second hand write ups tend to confuse.

The free tier is narrowed to one project, one page, and thirty components in the React and site builder flavours, so it serves for looking around rather than for work. The design tool library is the exception, staying complete even on the free plan.

More important than the rate is how to compute the return. The tool saves time in one project phase, so it pays across several projects a year rather than one. An agency building ten sites a year recovers the subscription on the first project. A company building its own site once every three years probably does not.

The second thing is role dependence. A designer gains most, receiving a starting point and a library. A developer gains less, since code export is secondary to the main purpose.

Per person billing is the line that, across several participants, changes the bill more than the rate itself. The team plan starts at three seats, so a two person studio either pays for a seat it will not use or stays on separate accounts.

Fitting it into a process

A few things make the tool deliver more than a generated sitemap.

Start with a description holding specifics. A description stating what the company does, who it addresses, and what should happen after somebody lands on the site produces a far better result than an industry name. That is the same principle as with models: specifics in the input become specifics in the output.

Review the sitemap before generating wireframes. Fixing the page list takes minutes, and generating layouts for pages that will be cut anyway wastes time.

Treat the output as material for a conversation rather than a proposal to approve. The greatest value appears when a client or a team looks at something concrete and says what is missing.

Move to a design tool early. Wireframes exist to show structure, so refining them inside this tool is work in the wrong place.

The last item: record the sitemap outside the tool. A page list with each page's purpose is a document useful throughout a project, including for people who never open this tool.

Translating that list into a directory structure takes a minute and immediately shows whether the sitemap holds together.

app/
├── page.tsx                  # /
├── pricing/page.tsx          # /pricing
├── case-studies/
│   ├── page.tsx              # the list
│   └── [slug]/page.tsx       # a single case study
└── about/page.tsx            # /about

If while transcribing it turns out two pages land in the same directory, or that one has no sensible place in the tree, that is a signal to fix the sitemap rather than to bend the structure. The test looks trivial and catches divisions invented during generation and never thought through afterwards.

Common mistakes

The first is expecting a finished design. Wireframes are deliberately raw, and refining them is separate work in another tool.

The second is treating the React export as a component library. It is code to copy and rework rather than a dependency you install and update.

The third is an input description limited to an industry name. The result is then generic, since the tool has nothing specific to draw on.

The fourth is generating wireframes before fixing the sitemap. Layouts for pages that fall out of scope get produced for nothing.

The fifth is shipping a site without changing typography and colours. The result is recognisable, and on a product meant to differentiate that works against the goal.

The sixth is subscribing for one project across several years. The tool pays back on repetition rather than on a single use.

The seventh is showing a client a wireframe without saying what it is. The first reaction then concerns everything being grey rather than whether the structure makes sense, and a whole round goes on explaining instead of discussing content.

The eighth is leaving pages in the sitemap that nobody will write. A page with no text harms more than no page, and a list of twenty entries looks solid right up to the moment the writing gets divided.

FAQ

Does Relume generate a finished website?

No. It generates a sitemap and wireframes assembled from ready sections, meaning material for the phase before design. Refining appearance happens in a design tool, and building a working site elsewhere.

Can I export code to React from it?

Yes, the components use Tailwind and fit a typical stack. It is code to copy and rework rather than a library installed as a dependency, though, so for a technical team the main gain remains structure rather than code.

What does it cost?

Starter costs 26 USD monthly or 18 USD on annual billing, Pro 58 and 40 USD respectively, and the team plan 52 and 36 USD per person with a three person minimum. A free tier exists, but at one project and one page it serves for looking around. The return appears across several projects a year rather than one.

Do sites made with this tool look alike?

Yes, if the defaults are left in place, since the sections come from one library. Changing typography, colours, and a few layouts suffices for the result to stop being recognisable, and on a product meant to differentiate that is necessary.

When is working without this tool better?

When appearance is meant to differentiate the product, when you build one site every few years, and when the structure is obvious and needs no agreeing. In those cases ready sections save no time and merely constrain.

The capability description sits on the product site, and plan terms in the pricing.