Forem: Luke Hanner

SpecifyThat is live — and it makes context files, not specs

Luke Hanner — Sat, 28 Feb 2026 12:00:00 +0000

The last update on SpecifyThat said it just needed to work again. It works. It's live. But the more important thing that shipped isn't the status badge — it's clarity about what the tool actually makes. The clearest signal was trying to explain it to someone. A spec is a document you write before you build. A context file is a document your AI reads while it builds. One sits in Notion. The other gets used. I'd been calling it the wrong thing for months. ## What shipped - **The output is a context file, not a spec.** SpecifyThat now generates the file your AI coding tool reads at the start of every session — stack, architecture, conventions, non-goals — not a document for humans. That distinction matters. Specs sit in Notion. Context files get used. - **v2 flow: describe once, AI fills the rest.** You write a sentence or two about your project. AI works through all 13 questions behind the scenes and comes back with a full review screen. Everything pre-filled. You adjust what's wrong — most people change nothing — then generate. - **Works for every major AI coding tool.** Cursor, Claude Code, Windsurf, Bolt, Copilot. Each one expects its context in a different file at a different path. The generated file works for all of them. /how-it-works now explains where to drop it for each. - **Multi-part support.** If your project has distinct modules or you want to spec a backend and frontend separately, you can run the flow multiple times in one session and get a file per part. Those four changes shipped in the same push. They felt like separate things right up until I noticed they were all solving the same problem: getting from vague idea to a file your AI can actually use, with as little friction as possible. ## Why The old framing — "generate a spec" — was wrong. Nobody pastes a spec into Cursor. They paste context. Renaming it didn't change the output much, but it changed who the tool is for and how it gets used. Solo builders who want to start coding in ten minutes, not write documentation. The v2 flow exists because the original interview — question by question, one at a time — felt like homework. The point was always to skip the planning step, not to disguise it as a chat. I built this for me first. I skip the planning step too. Now I don't have to. ## What's next Three things in the backlog, in rough priority order: **AI confidence review.** After generating, a second AI pass reads the spec against the original project description and surfaces 1-3 gaps — things that are ambiguous, missing, or contradictory. You answer them or skip. The idea came from manually asking a model "review this until you're 95% sure you could build it" — that step should be automatic. Planning to use Claude Opus 4.6 for this, which is built for exactly this kind of sustained critical review. **UI/design constraints.** One new question in the interview: "Any UI/design constraints AI should know?" — mobile-first vs desktop, dark mode requirement, component library already in use. Not a brand exercise; just enough context so AI doesn't make arbitrary stack choices. Users with a brand.md can skip it. **Brand discovery mode.** A separate interview mode that generates a brand.md instead of a context file — vibe, tone, personality, emotional direction. Parked until there's user signal that people want it, but the interview pattern fits naturally. None of those ship before there's signal. The rate limit data will tell me when to add billing. Usage will tell me what to build next. The issues are parked until then. Right now it just needs to be used.

Why every tool I build will be local-first

Luke Hanner — Fri, 27 Feb 2026 12:00:00 +0000

I spent last night writing a manifesto that boils down to one line: **Your prompts never leave your device.** Not a promise. An architectural guarantee. The app runs on your machine. API calls go directly from your browser to the AI provider. My server only touches the billing layer. I never see your content. Here's why this matters and why I think the current model is broken. ## The gatekeeping problem Want to try an AI tool? Create an account. Verify your email. Pick a plan. Enter your credit card. Now you're locked in — paying $15/month whether you use it once or a hundred times, getting promo emails you never asked for, with your prompts stored on servers you can't audit. That's not a product. That's a trap dressed up as a product. ## What I'm building instead **No accounts.** You open the tool and use it. No username, no password, no "sign up to continue." **No subscriptions.** Pay for what you use, when you use it. Prepaid credits. Top up when you want, stop when you want. Like a transit card — not a gym membership. **No data harvesting.** I don't store, log, or mine your inputs. My backend handles credit deduction. The content of what you're asking bypasses me entirely. ## The business model I'm a utility reseller. AI providers are the power generators — I buy wholesale tokens, sell retail. The margin between what I pay per token and what I charge is the business. Simple, transparent, scales with usage. Free trial on launch. Rate-limited, using my API key, so you can experience the tool with zero friction. When you want more, you buy credits through a one-time Stripe payment. No account created. No subscription initiated. ## Where this goes In five years, on-device inference will handle most everyday AI tasks. The cloud API becomes reserved for heavy lifting. When that happens, "your prompts never leave your device" becomes even more true — and my costs drop because I'm not paying for API calls. The account-per-tool model will feel as outdated as remembering your AOL login. Device-level identity and native payment rails will replace it. I want to be building for that future. Starting now. ## First up: SpecifyThat SpecifyThat is the first tool getting rebuilt with this philosophy. Today it's a server-side app where my API routes see every prompt. The rebuild flips that: API routes become thin proxies that forward to OpenAI without logging or storing what you send. My server never writes your prompt to a database or a log. Same tool, fundamentally different architecture. More on that soon.

SpecifyThat — built for me, found by others

Luke Hanner — Thu, 26 Feb 2026 12:00:00 +0000

Before Modryn Studio existed, I shipped SpecifyThat. The problem: I kept starting projects with a half-formed idea and wasting the first hour of a build session figuring out what I was actually trying to build. So I built a tool to fix that. Thirteen targeted questions. If you don't know the answer, an AI fills the gap using "top 0.1% thinking" for that decision. At the end, you get a copy-ready spec to paste into Cursor, Copilot, or whatever you build with. I never marketed it. It's not on Google Search Console. But two people found it, signed up for updates, someone starred it, and someone forked it. That's enough signal. It's listed here now as beta. The AI backend is being swapped from Anthropic to OpenAI (cost reasons — a full spec gen costs fractions of a cent on GPT-5 mini). Once that's live, the status flips. The tool has a wish list a mile long. That's a later problem. Right now it just needs to work again.

How I set up my Copilot workflow

Luke Hanner — Thu, 26 Feb 2026 12:00:00 +0000

Every new project I start now gets the same setup: a .github/ folder that turns VS Code into a disciplined co-pilot rather than an eager yes-man. Here's what's in it. **@check** — a pre-ship agent. Before every push, I type @check and it reads all recently changed files, hunts for bugs, runs lint, runs a build, and commits any fixes. It never pushes. I review the diff, then push myself. That one habit has caught at least three dumb mistakes that would have gone to production. **/init** — new project setup. I fill in two files (context.md and brand.md) with the product facts and brand rules, then run /init. Copilot reads both and fills in the always-on instructions file that lives in every session. Takes 5 minutes instead of 20. **/seo** — pre-launch checklist. Generates sitemap.ts, robots.ts, manifest.ts, and JSON-LD structured data automatically. Audits for missing OG images and character counts. Then walks me through Google Search Console and Bing registration step by step. **src/config/site.ts** — single source of truth for the site name, URL, description, and brand colors. Change it once and the manifest, JSON-LD, sitemap, and metadata all update on the next build. No sync needed. The whole thing is in a public repo at github.com/modryn-studio/boilerplate. Copy the .github/ folder into any Next.js project and it works. Built for one-person studios that ship fast and can't afford to forget things.

The site is live

Luke Hanner — Wed, 25 Feb 2026 12:00:00 +0000

Shipped modrynstudio.com today. One page. Dark mode. Email signup. That's it. The plan: detect a rising trend, score it, ship a tool in 48 hours, capture traffic early. Repeat. Every tool gets a page here. Every decision, kill, and lesson gets a log post. That's the deal. First tool in progress: Trend Detector. Follow along.

I Wasted 6 Months Building Products Nobody Wanted. Then I Discovered the Real Problem.

Luke Hanner — Tue, 16 Dec 2025 17:56:04 +0000

The Grind (That Led Nowhere)

Six months ago, I was in full builder mode.

PropTools - A Bootstrap site comparing futures prop firms. Spent months building it. Clean UI. Good data. Launched it.

Then discovered PropTraderTools already existed. Exact same concept.

Modryn Studio - Weeks building a Next.js marketing site for my web development company. TypeScript. Tailwind. Beautiful animations.

Zero clients.

Client Portal - Built an entire customer management system. Authentication. Dashboards. The works.

Problem? No customers to manage.

I kept building. Nothing was working.

The Pivot (That Also Failed)

"Small businesses need websites. I'll build those."

I created a CLI tool with templates for contractors, restaurants, salons. Could generate a professional site in 2 hours.

Built a free salon website for a friend. She loved it.

Perfect. Time to scale.

Except cold calling isn't my thing. Couldn't sell a single site.

I was stuck:

✅ Fast at building
❌ Terrible at selling
❌ No idea what to build next

The Experiment That Changed Everything

Instead of building another product, I tried something different.

I asked GPT & Claude: "Give me coding tests. Small projects. I want to know what kind of developer I am."

I got specs. Real, detailed specifications:

PROJECT: Task Timer CLI

REQUIREMENTS:
- Start/stop timers with task names
- Store data in SQLite
- Export to CSV
- Show daily summaries

CONSTRAINTS:
- No GUI, CLI only
- < 500 lines of code
- Single executable

SUCCESS CRITERIA:
- User can track 3 tasks simultaneously
- Data persists across sessions

I finished it in 23 minutes.

Wait, what?

The same type of project that used to take me days.

The Pattern

I asked for more specs. More projects.

ToDo API: 18 minutes
Markdown blog generator: 47 minutes
URL shortener: 31 minutes

The difference wasn't my coding ability.

It was the specs.

When I had a clear specification:

✅ No analysis paralysis
✅ No scope creep
✅ No "wait, what am I building?"
✅ Just execute

When I wrote my own specs, I'd spend 2-3 hours staring at blank pages, second-guessing decisions, ending up with vague notes.

The Real Problem

I didn't need to learn more frameworks.
I didn't need better design skills.
I didn't need more business ideas.

I needed better specs.

But writing good specs myself? That was the hard part.

So I built a tool to do it for me.

Introducing SpecifyThat

A conversational spec generator that asks the 13 critical questions every project needs answered.

How It Works

13 Targeted Questions - Each maps to a section of a technical spec
AI Gap Filling - Click "I don't know" for expert suggestions
10-Minute Specs - From vague idea to executable spec

The Meta Part

I used Claude to generate a spec for SpecifyThat. Then I built SpecifyThat using that spec.

The tool generated the specification that built itself.

The Tech Stack

Frontend: Next.js 14 + TypeScript
AI: Claude Sonnet 4 (Anthropic API)
Styling: Tailwind CSS
Deployment: Vercel
Build Time: 2 days

Key Technical Decisions

1. Claude's `tool_use` for Structured Outputs

Instead of parsing text responses (which fail ~15% of the time), I used Anthropic's tool definitions:

const analyzeProjectTool: Anthropic.Messages.Tool = {
  name: 'analyze_project',
  description: 'Analyze a project description',
  input_schema: {
    type: 'object',
    properties: {
      type: { 
        type: 'string', 
        enum: ['single', 'multiple'] 
      },
      summary: { type: 'string' },
      units: {
        type: 'array',
        items: {
          type: 'object',
          properties: {
            id: { type: 'number' },
            name: { type: 'string' },
            description: { type: 'string' }
          }
        }
      }
    },
    required: ['type']
  }
};

const message = await anthropic.messages.create({
  model: 'claude-sonnet-4-20250514',
  tools: [analyzeProjectTool],
  tool_choice: { type: 'tool', name: 'analyze_project' },
  messages: [{ role: 'user', content: prompt }]
});

Result: 100% valid JSON responses. Zero parsing failures.

2. XML Wrappers Prevent Prompt Injection

User input gets wrapped in XML tags before sending to the AI:

function buildAnalysisPrompt(userInput: string): string {
  return `Analyze the following project description:

<user_project_description>
${userInput}
</user_project_description>

Determine if this is one buildable unit or multiple...`;
}

This prevents users from manipulating the AI's responses with instructions hidden in their project descriptions.

3. Gibberish Detection Saves Money

Launch day: Users typed "asdfasdf" and got AI-generated responses.

Added validation:

function isGibberishInput(text: string): boolean {
  // Check vowel ratio
  const vowels = text.match(/[aeiou]/gi)?.length || 0;
  const vowelRatio = vowels / text.length;
  if (vowelRatio < 0.08) return true;

  // Check for repeated patterns
  const pattern = /(.)\1{4,}/;
  if (pattern.test(text)) return true;

  // Check for keyboard mashing
  const keyboards = ['qwertyuiop', 'asdfghjkl', 'zxcvbnm'];
  for (const kb of keyboards) {
    if (text.toLowerCase().includes(kb)) return true;
  }

  return false;
}

4. Multi-Unit Detection

Complex projects get automatically detected and broken down:

interface AnalysisResult {
  type: 'single' | 'multiple';
  summary?: string;
  units?: {
    id: number;
    name: string;
    description: string;
  }[];
}

When a user describes something like "a SaaS with auth, billing, and dashboards," the AI detects 3 buildable phases and lets them spec one at a time.

Why this matters: Scope creep kills projects. Breaking them into shippable units increases completion rates.

Features I Didn't Plan (But Users Needed)

The "I Don't Know" Button

Insight: Developers don't struggle with coding. They struggle with making spec decisions.

Ideation Mode

Some users clicked "I don't know" on Q2 (project description) because they literally didn't have a clear idea yet.

Added a 3-step discovery wizard:

What problem frustrates you?
Who will use this?
What category? (9 options with icons)

The AI synthesizes these answers into a project description, which the user can edit before proceeding.

Result: Even vague ideas become actionable specs.

File Upload Support

Users wanted to paste existing docs. Added support for .txt and .md files (up to 10MB).

const handleFileUpload = async (file: File) => {
  const content = await file.text();
  await analyzeProject(userInput, content);
};

The AI analyzes both the text input AND the attached document together.

What I Learned

1. Good Specs Are Force Multipliers

With a clear spec, I can build in hours what used to take days.

The bottleneck isn't coding ability. It's specification clarity.

2. Users Know When They Don't Know

People struggle with decisions, not execution.

3. Build What You Need First

I built SpecifyThat because I needed it. Every feature exists because I ran into that problem myself.

That's why it works. I'm the target user.

4. Ship Fast, Iterate Later

2 days from idea to production. Bugs and all.

Bugs I fixed:

Gibberish input validation (added after seeing "asdfasdf")
Back button on multi-unit screen (wasn't clearing state)
Character counter on Q1

The 6-Month Lesson

Old approach:

Spend months building
Launch with no audience
Wonder why nobody cares
Repeat

New approach:

Identify YOUR problem
Build the solution fast
Ship publicly
Let the market tell you if it matters

SpecifyThat exists because I wasted 6 months learning this lesson the hard way.

Try It Yourself

SpecifyThat is free, requires no login, and works on mobile.

Try it: https://specifythat.com

Open source: https://github.com/modryn-studio/specifythat

What's your biggest challenge when planning projects?

Do you spend more time planning or building? Let me know in the comments.