The 5-step framework

Step 1 — Map your manual work

Before you write a prompt, list every task your team does more than twice a week that follows a pattern. Not everything should be automated — but you can’t evaluate what you haven’t named.

Format: task, frequency, who does it, rough time cost.

Step 2 — Score for AI fit

Rate each task on three axes: pattern clarity (consistent inputs and outputs?), error tolerance (what’s the cost of a bad output?), and volume (does the time saving compound?). High on all three = strong AI candidate.

Step 3 — Choose your layer

Decide whether you’re building at the prompt layer (use an existing tool with a well-crafted prompt), the workflow layer (chain steps with something like Make or n8n), or the product layer (build a purpose-specific feature into your app). Most founders start too deep.

Step 4 — Build the smallest useful version

Before you wire anything up, test the core prompt in the playground. If you can’t get a reliable output there, you can’t get it anywhere. Once it works manually, then automate.

Step 5 — Measure the asset, not the feature

An AI feature that saves 3 hours/week is worth ~$7,500/year at a $50/hr blended rate. Track it that way. This framing helps you prioritize next iterations and make the case to investors or customers.

Prompt library

These prompts are organized by use case. Each works best with Claude or GPT-4 unless noted.

Code review & architecture

Dependency audit — “Review this package.json and flag any dependencies that are: (a) outdated by more than 2 major versions, (b) have known security issues, or (c) have better alternatives for a [stack type] project. Explain each flag.”
Endpoint security scan — “Review these API routes for common security issues: missing auth checks, unvalidated inputs, over-exposed data, and N+1 query risks. Flag each with severity: critical / high / medium.”
Refactor proposal — “Identify the three highest-leverage refactors in this codebase that would improve maintainability without changing behavior. For each, estimate effort in hours and explain the long-term benefit.”

Spec & decision writing

Feature spec from user story — “Turn this user story into a technical spec. Include: acceptance criteria, edge cases, data model changes, API contract, and open questions that need answering before building.”
Build vs. buy analysis — “We need [capability]. Help me think through build vs. buy vs. wrap. Consider: time to value, ongoing maintenance cost, lock-in risk, and what we’d lose by not owning it.”

Vendor evaluation

Vendor comparison — “Compare [Vendor A] and [Vendor B] for [use case] across: pricing model at [your scale], integration complexity with [your stack], data residency options, and exit path if we need to switch.”

Decision template: Build vs. Buy vs. Wrap

Use this for any AI tool decision:

Capability needed: ___
Current solution: ___

Build
  Dev time estimate:      ___
  Ongoing maintenance:    ___
  Lock-in risk:           None
  Control:                Full

Buy (SaaS)
  Cost at current scale:  ___
  Cost at 10x scale:      ___
  Integration effort:     ___
  Lock-in risk:           ___

Wrap (API)
  API cost at volume:     ___
  Integration effort:     ___
  Prompt engineering:     ___
  Lock-in risk:           Low

Decision:     ___
Revisit when: ___

What to do next

Run Step 1 this week. Block 30 minutes, open a spreadsheet, and list every repeating manual task your team does. That list is your AI roadmap. Everything else follows from it.

If you want to talk through your specific situation, reach out directly.