Outrank · Free Tools 2.0 · The plan

Tools that look like
the customer built them on purpose.

Right now every free tool we ship is the same centered form in the same two templates, with the customer's logo pasted on top. It reads as generic, so it converts and ranks like generic. This plan throws the template cage away, gives Sonnet 5.5 real creative freedom with a real design brief, and turns the in-app builder into something that thinks, researches and shows options before it touches anything.

Match the customer's site — default Creative mode — art-directed, tmaker-style Smarter builder chat with plans & options Same hosting, SEO, domains — nothing lost
01 — Where we are

The customer's site has a personality. Their tool doesn't.

Real tools generated this month, next to the websites they're supposed to belong to. Pebb is warm, beige, grid-lined, with heavy geometric type. SleekPost is monospaced and technical. Their tools are the same anonymous form, in the same font, in the same layout.

Customer sitepebb.io homepage
Their Outrank tool todayPebb turnover calculator tool
Customer sitesleekpost.com homepage
Their Outrank tool todaySleekPost audio transcriber tool

Why it looks like this (it's not the model's fault)

Two fixed layouts

Every tool must render Layout from templates/variant-1 or variant-2. A build-time check SSR-renders the page and fails the build if that Layout isn't there.

One colour of brand input

The only thing we pass about the customer's look is a single hex colour (plus logo/name). No fonts, no palette, no screenshot of their site. The model literally cannot match what it can't see.

Contradicting instructions

The prompt says "be creative like Linear/Vercel, use gradients" and, a few lines later, "stay inside the Layout, only use brand-color, template preservation is mandatory". The safe reading wins every time.

A chat that only types

The builder has a hidden planner but never shows a plan, never researches, never offers options, rewrites whole files for small edits, and checks only that the code compiles — never how it looks.

02 — The bar

What "good" looks like.

tmaker.io/tools: each tool is its own art-directed piece — an editorial headline, one strong idea, a custom interaction, data you want to screenshot and share. That's the ceiling for Creative mode. For Match-site mode the bar is "you can't tell it wasn't made by the customer's own designer."

tmaker app worth tool
tmaker.io/app-worth — custom dial input, serif display type, one accent colour, zero template feel.
tmaker real rating
tmaker tools index
03 — Two styles, one picker

Keep everything. Unlock the design.

Default

Match my website

Before the first build we capture the customer's site once: full-page screenshot, real fonts, colour palette, radius, spacing, button and input styles, header/footer pattern, imagery mood. That becomes a compact style brief + reference screenshot the model designs against — no predefined components, just "make it belong here".

Option

Creative freedom

The model art-directs the tool itself, tmaker-style: picks a concept, typography pairing and one signature interaction that fits the keyword. Brand colour and logo still respected, but the page is designed for the tool — not poured into a shell.

Classic / Modern stay available for anyone who likes them. Existing tools are untouched until the customer rebuilds or edits one. Hosting, custom domains, sitemaps, related-tools grid and the FAQ/HowTo schema injection all keep working — they become a light semantic contract (a few data-attributes), not a fixed layout.

04 — How the new build works

Design like a person: look, build, look again.

Style capture (once per site, cached)→ Concept & plan→ Free-form build (Sonnet 5.5)→ Render + screenshot→ One self-critique pass→ Publish
1

See the target

The model gets the customer's homepage screenshot as an image plus extracted design tokens. This one change does more than any prompt tweak.

2

See its own output

After building, we screenshot the result (desktop + mobile) and hand it back once: "does this look like it belongs next to the reference? fix the 3 worst things." That's the Claude Code secret sauce.

3

Stay cheap

Cached style brief, prompt caching, surgical edit tool instead of whole-file rewrites, one bounded review pass. Target: better tools at the same or lower tokens than today — measured, not guessed.

05 — Builder chat 2.0

A builder that thinks before it types.

Research

Web search + page reading, so "make it like Omni's calculator" or "add the 2026 tax brackets" actually works.

Shows options, asks which

For anything visual it renders 2–3 quick directions as thumbnails and lets the user pick before spending a full build.

Shareable plan link

Bigger changes come with a plan the user can open, read and approve — just like the plan you're reading now.

Checks its own work

Every edit ends with a rendered screenshot check, not just "it compiles".

Make the results feel more premium, it looks flat
I looked at your site and the current tool. Here are three directions — which one feels right?
Warm editorial
Dark data-viz
Paper & grid
The third one
Great. Here's the plan → open plan. Building now, then I'll show you a before/after.
06 — How I'll run this

Built locally, shown on video, polished for days.

  1. Access & local stackAll three tools repos running locally against staging: builder service, E2B sandbox template, serving gateway, plus the Outrank app. Example product created and onboarded end to end.
  2. Baseline & eval setGenerate ~10 tools across 5 real customer sites with today's pipeline. Screenshot, record tokens and time. This is the "before" every change is scored against.
  3. Style capture + free-form buildSite capture → style brief, remove the Layout lock, new prompts for Match-site and Creative modes, SEO contract kept. Re-run the eval set, side-by-side screenshots.
  4. Visual self-review loopRender → screenshot → one critique pass. Tune for quality vs. tokens until the numbers are better on both.
  5. Builder chat 2.0Research tool, design options with thumbnails, shareable plan links, surgical edits, screenshot verification. Screen recordings of real sessions.
  6. Polish until it's boringEdge cases (dark sites, sites that block scraping, RTL, mobile), failure recovery, migration path for existing tools, then PRs per repo, small and reviewable.

You'll get recordings after phases 3, 4 and 5, and a running before/after gallery.

What I still need from you
  • E2B API key for the team that owns the seo-tools-dev template (or invite me to the E2B team). This is the only hard blocker — without it nothing builds.
  • Write access to outrank-seo-tools, seo-tools-e2b-image, seo-tools-container so I can push branches and open PRs (I can read them already).
  • Optional: a separate dev R2 bucket for tool builds (otherwise I'll use a dev/ prefix), and AssemblyAI / CloudConvert keys if you want media tools in the test set.
  • Already have: all repos (read), Anthropic, staging Supabase, R2, Cloudflare, ScrapingBee, KIE.