Chris Learey/Selected work/Case study

AI-Native Product

A tool that refuses to look finished

Describe a screen, get a hand-drawn sketch you'll happily throw away, so teams argue about the idea, not the pixels.

Most tools race to look done. I made this one look exactly as done as the thinking is. Fidelity is a function of confidence, so polish is structurally impossible, not just discouraged.
Exhibit 01, Live product

Delible

Describe a screen; get four divergent, hand-drawn takes on it, pictured: the real picker, one prompt solved four ways.

The Delible picker, four divergent, hand-drawn ‘Diamond Recommendation Tool’ sketches generated from one prompt, shown in a 2×2 grid to pick one to iterate
delible.dev Open the live product
My role
Founder & sole builder, product strategy, the design system, the AI generation pipeline, the web app, and the MCP server
Context
A standalone product, originated as an internal tool ("Nivoda Sketch") to get a B2B marketplace's PMs off Lovable
Duration
Internal v1 to shipped SaaS, live at app.delible.dev
Stack
Next.js 15 · React 19 · Supabase · DeepSeek API · rough.js + blackchalk · MCP server · Stripe
What shipped
Live web app · open-source component library (~70 components) · 4-tool MCP server · permalink publishing · markdown + PDF brief export · eval harness
Blank repo to shipped, the thesis, the constraint, the AI pipeline, and the data layer behind it.

Polish arrives before the idea is ready

AI prototypes look finished on the first prompt. That's the trap:

  • Polish skews feedback. People critique the gradient, not the flow, and assume it's decided.
  • Context is disposable. Lovable drops the why on export; every handoff starts from zero.

Fidelity outruns confidence. The gap is wasted work:

high time → fidelity (AI tools) confidence (reality) the premature-polish tax
Fidelity should track confidence. The gap is feedback aimed at the wrong layer.
It started as "Nivoda Sketch", an internal tool with one metric: "PMs stop using Lovable." Real pain, real first customer.

Make polish impossible, not discouraged

Convention leaks ("please keep it rough"). So the constraint lives in the renderer: nothing Delible makes can look finished.

Everything's hand-drawn and monochrome; border-radius, box-shadow and gradients are banned at the system level. You can't polish your way out, so feedback stays on structure.

high time → fidelity = confidence no gap to pay for
Constrain the output and fidelity rises only with confidence, look as done as you actually are.

But the constraint is just the entry fee. The real product is underneath: as you sketch, Delible builds the brief, decisions, rationale, open questions, on a permalink that outlives the session. Type → see → steer → hand off.

Each limit forced the next piece

It began as a Claude skill, a /sketch command that called an MCP server and drew inside the chat. Useful, but every wall I hit built the next layer:

  • Sketch in Claude. Good, but trapped in the session, with no way to share it.
  • No permalink → a database. To share a sketch, it first had to live somewhere.
  • A link needs a home → a web app. Something had to surface and manage the sketches.
  • Building the frontend anyway → make it the product. Accounts, management, and a collaboration surface for comments and sharing.
  • Now back to an MCP. Wrap the mature features as a native Claude app, on top of the database and sharing already built.
Each wall bought the next capability, and the backend it forced into being is the moat.

Four layers, constraint to handoff

1 · A design system that can't be polished

The look is the enforcement, so it's a real system: blackchalk, a monochrome rough.js React kit, ~70 components, open-source. Two stroke tokens, greyscale only, banned-polish list in code.

What I believe: a constraint you can route around isn't one. A monochrome lint fails the build on any saturated colour, enforced by CI.

2 · AI generation you can trust

  • Rules as the prompt: one RULES.md drives humans, the app, and the MCP server.
  • A validator: generated JSX is checked against those rules, off-system output never ships.
  • An eval harness, not vibes: a fixed prompt set, currently 42/43 (97.7%).
  • Divergent options, then refine: up to four takes (A–D), not one, iterate the keepers down.
Prompt “a diamond search” DeepSeek + RULES.md system prompt · validator Option A Option B Option C Option D set aside set aside ↻ ↻ ↻ handoff refine ×4 ↻ set aside refine ×2
One prompt → four options; refine the keepers (A ×4, C ×2), hand off one. The rest are set aside, not deleted.

3 · The context layer, the actual moat

Anyone can clone the look, rough.js is open. The data layer can't be. Delible captures a versioned brief (markdown + PDF) and publishes a permalink from its own database, so the sketch outlives the session and reopens with context intact.

What I believe: the moat is the database and the brief, not the brushstrokes. A sketch tool is easy; the data layer is a different company.

4 · Two surfaces, one sovereign data layer

Two surfaces, one backend. The web app (app.delible.dev) is the home, accounts, data, permalinks. The MCP server (four tools) puts the same product inside Claude as distribution. The data stays Delible-owned, so platform risk never touches the moat.

The decisions that define it

A series of opinionated calls, the opinion is the artifact:

  • Monochrome, enforced by CI. Greyscale is a build failure, not a guideline.
  • Divergent options, never one-shot. One output invites "make this perfect"; four keep you comparing structures.
  • Open-sourced blackchalk. Credibility and funnel, a soft moat, deliberately not the business.
  • Positioned against Claude Design. Anthropic aimed hi-fi, leaving the lo-fi lane open: "it looks done; Delible looks exactly as done as it is."
The throughline: build the sharp opinion into the system, a wedge a platform won't copy because it fights their own bet.

Blank repo to shipped, solo

Beyond the code:

  • End-to-end ownership. Strategy, design system, AI pipeline, web app, MCP server, billing, empty repo to monetised product, solo.
  • Judgment as engineering. "Low fidelity" lives in tokens and a lint rule, not a deck.
  • Validated before generalised. It earned its keep internally before becoming a SaaS.
  • Quality instrumented. An eval harness makes "the output is good" a number, not a claim.
  • Built for the moat, not the demo. The sketch is flashy; the brief and permalink database are defensible, I prioritised those.

What shipped

  • Live and monetised, app.delible.dev, Google auth + Stripe.
  • Constraint holds structurally, monochrome lint, polish banned in code; output can't drift hi-fi.
  • Generation measured, 42/43 eval pass rate on the production validator.
  • Permalink is real, published sketches mint a public slug, independent of any session.
  • Two surfaces, one backend, web app as home, four-tool MCP server as distribution.
  • Open-source asset, blackchalk (~70 components), credibility and funnel.

Look as done as you actually are.

Next.js 15 React 19 Supabase DeepSeek API rough.js blackchalk (OSS) MCP server Stripe Tailwind TypeScript Eval harness