Pagoti Homepage in a London office setting

Making Pagoti easier to understand at first glance

I’ve been tightening up the Pagoti homepage this week. Not by adding more, but by making the first few seconds clearer.

The prompt was partly this video by Justin Jackson.

It was a useful reminder that a homepage has a simple job: help someone understand what the product is, why it exists, and whether it is worth their next click. If the page feels generic, overdesigned, or too much like a checklist of features, it loses that job.

So I made a few changes.

Less feature grid, more product shape

The old features section had the familiar pattern: icon, heading, short paragraph, repeated six times.

It worked, technically. But it also felt too generic. You could swap the icons and copy into almost any SaaS homepage and it would still make sense. That is usually a bad sign.

The new section is simpler:

  • Write: markdown stays the source of truth.
  • Publish: hosted pages without the site build.
  • Reuse: pull the same content into anything.

That is much closer to how I think about Pagoti.

Pagoti is not trying to be a huge CMS. It is a lightweight content system for small, fast-moving projects where you want to write once and use the content in more than one place.

Moving proof higher up

I also moved social proof higher on the page.

Instead of asking visitors to read a product pitch first, the homepage now includes a short founder note near the top:

“Pagoti is the content system I wanted for small, fast-moving projects: write in markdown, publish without ceremony, and still keep the content useful through an API.”

That is not customer proof yet, but it is still useful proof. It explains why the product exists in a human way.

For a small product, especially one still early in its life, founder context matters. It tells people there is a real person behind it, a real use case, and a real point of view.

Surfacing the docs earlier

Pagoti has two main paths:

  1. Use it to publish hosted pages.
  2. Use it as a content API.

The API side is important, so the hero now links directly to the documentation. If someone arrives already thinking like a developer, they should not have to scroll around to find the technical details.

That small link does a lot of work:

Want the API details first? Read the docs.

It makes the homepage less of a brochure and more of a product entry point.

Tightening the visual tone

There were also smaller visual changes.

The homepage heading font moved to Playfair Display, which gives the page a more classic editorial feel. That suits Pagoti better than something overly neutral. Content products should feel like they care about publishing.

The testimonial card now uses the same kind of shadow language as the tilted product screenshots, and the extra border/decorative line was removed. It feels cleaner.

The animated GLSL background is now hidden on smaller screens too. It is a nice desktop flourish, but mobile needs to be direct and lightweight.

Small accessibility fixes matter

While making the page feel better, I also cleaned up a couple of accessibility issues.

The “Write / Publish / Reuse” labels now have stronger contrast. The testimonial attribution also no longer uses a heading element, because “Daniel Hudson” is not really a section heading. It is attribution text.

That kind of thing is easy to miss, but it matters. A homepage should look good, but it should also have a sensible structure.

The direction

The page now feels closer to the product I want Pagoti to be:

  • clear
  • lightweight
  • developer-friendly
  • good for publishing
  • useful beyond the hosted page

The next step is not more decoration. It is more proof.

Real examples, real use cases, and better demonstrations of how content can move from markdown to hosted pages to API-driven frontends.

But this round helped the homepage say the important thing faster:

Pagoti is for writing content once, publishing it cleanly, and keeping it useful wherever you need it.