Hypothesize

Why I built it

I'd already built a set of Claude skills to accelerate my own experimentation workflow — design briefs, test plans, test reports. What made them actually useful wasn't just the document generation; it was the context layer underneath. Connections to Jira, Slack, and Granola meant the model already knew what was in flight, what had already been discussed, and what the client had flagged as a priority before I'd typed a single word. The skills weren't doing the thinking — they were doing the gathering, the formatting, the second pass on metrics — so I could spend my time on the parts that actually need judgment.

The question was whether any of that could work for someone who didn't have my workflow, my connectors, or my context. To build something for a smaller team, I'd have to strip it back — take out everything specific to how I work and find what was left. What remained was essentially a structured research process and a set of output formats. The connectors went. The Jira and Slack integrations weren't useful to someone who might not have either.

But that raised a harder problem. My skills work because of what goes in — by the time I'm ready to generate a test plan, I've already pulled the data, done the analysis, mocked up designs, and pulled in client context from Slack and Jira and meeting notes. I also already know what's worked in the past. What comes out is a polished, structured version of thinking I've already done. The model isn't filling gaps with assumptions; it's working from a complete picture. Strip that away and you're back to generic advice that could apply to any page on the internet. The real challenge wasn't the output formats — it was figuring out whether you could encode enough of what an experienced experimenter knows that someone without that background could still get to a useful output.

What it does

That's what Hypothesize is trying to answer. You feed it what a product or growth team already has — a page URL, analytics data, session recording notes, heuristic observations — and it produces structured, developer-ready test briefs. The workflow is: audit a page, pull in your metrics, annotate friction points, generate hypotheses. Approve one and you get a complete brief in a single click — control and variant descriptions, success metrics, dev notes, QA checklist. And because the tool logs what's been tested, what worked, and what didn't, the outputs improve over time — gradually building up the kind of experience layer that usually only comes from running a lot of tests.

It still has limits. The hypothesis generator misses things an experienced practitioner would catch, and it works best when you put the effort in on the audit side. But as a starting point for someone who just needs to get unstuck? It does the job.

How it's built

Backend is FastAPI with all Claude API calls routed through a versioned prompt registry — every prompt version is immutable once released and every generation is logged. Frontend is Next.js with Tailwind, backed by Supabase for auth, database, and file storage. Screenshots are captured server-side via Playwright, and an annotation layer lets you drop pins on friction points before generation so the model has richer context to work from.

The prompt system is on its sixth iteration, built on UX best practices, common interaction patterns, industry-specific conversion drivers, and design system guidelines. Version 6 added routing across 12 page types and an industry context block covering 18 verticals, so the model knows whether it's looking at a consumer checkout or a SaaS onboarding screen and can reason from the right set of assumptions.

The bigger question underneath all of this is whether experimentation should be as inaccessible as it currently is. The barrier isn't really the platforms or the process — it's the judgment that takes years to develop. If a tool can meaningfully compress that learning curve, even partially, that feels worth pursuing.