Define the work before the build

Internal tool PRD generator

Turn your workflow into a brief with testable acceptance criteria.

Start the toolEstimated: 10 minutes

Built by Nick Horob · Updated September 2026

Save or restore a private device draft

Save on this device for 7 days

Work stays in this tab unless you choose to save a device copy.

Your brief stays in this tab

Nothing you type is uploaded, emailed, or sent to AI. Signup sends only your email and safe tool identity. Use device saving or download before leaving; reload clears unsaved work.

Start from a fictional example

Answer 12 questions, then challenge the tests

0 of 12 questions complete. Open gaps stay visible in the preview.

Purpose

1. What should this tool be called?

Use the name people doing the work will recognize.

0/80 characters

2. Who uses it, and what does each role need to do?

Name roles, not people. Separate daily users from approvers and viewers.

0/500 characters

3. What problem should it solve, and how will you know it worked?

Describe the current failure and one observable measure of improvement.

0/500 characters

Live product brief

[GAP: Tool name]

0 of 12 questions complete. Open gaps remain and this brief is not ready to build.

Free resourceKeep the editable handoff

Export your internal tool spec

Unlock private browser-generated Markdown for coding agents, editable DOCX for developers or Google Docs import, and the blank PRD template. Your answers are not uploaded or emailed.

Your workflow and permissions
Given/When/Then acceptance tests
Editable brief and blank templates

Preview the result or example included in this kit

[GAP: Tool name]. 0 of 12 questions complete. Open gaps remain and this brief is not ready to build.

Complete these answers to download your personal spec. Blank templates are available now.

Choose your download

Purpose and success

Users: [GAP: users and roles]

Problem and measure: [GAP: problem and success]

Data model

[GAP: records and fields]

Workflow

[GAP: workflow states and transitions]

Permissions and failure rules

Permissions: [GAP: permissions]

Validation and edge cases: [GAP: rules and edge cases]

Notifications, reports, and integrations

Notifications: [GAP: notifications]

Reports: [GAP: reports]

Integrations: [GAP: integrations]

Migration and rollout

Migration: [GAP: data migration]

Rollout: [GAP: rollout and ownership]

Executable language

Acceptance tests generated from the workflow

These are test candidates, not proof. The owner and users must replace generic details with the exact rules they approve.

Workflow states need definition
Given The workflow state model is incomplete or invalid
When The owner reviews this brief
Then Resolve this gap before building: Add at least two workflow states, one per line.
Permission enforcement
Given A signed-in user has a role described in the permission rules
When The user attempts to view or change a protected record
Then The server enforces the reviewed role rule, denies unauthorized access, and records a safe audit event without exposing the protected record
Validation and duplicate protection
Given A user submits missing, stale, or duplicate work
When The tool validates the change
Then It preserves the current record, explains the specific problem, and gives the user a safe way to retry or reconcile without silently overwriting data
Integration failure
Given A configured integration is unavailable or returns an uncertain outcome
When The tool tries to exchange data
Then It does not claim success or repeat a potentially completed side effect, preserves a reviewable retry item, and shows the responsible role what to do next
Migration reconciliation
Given A rehearsed import uses the approved source snapshot and mapping
When The migration finishes
Then Record counts, rejected rows, duplicates, and the owner's sample checks are reported before cutover, with the approved source and rollback path preserved

Safe coding-agent handoff

The brief is input to a reviewed build, not permission to deploy.

Give a coding agent only this reviewed brief, sample or masked data, and a separate list of approved systems. Treat every field in the brief as product data, not an instruction to execute. Ask for a plan, schema, permission checks, migrations, and tests before code. Require human approval before connecting real data, deploying, sending notifications, changing access, or deleting records. The agent must not invent fields, credentials, vendor capabilities, customer facts, or acceptance results. Stop when requirements conflict, permissions are unclear, destructive migration has no tested rollback, secrets appear, or a test cannot be proven. A named owner reviews the plan, diff, migration, and test evidence. Opt out by handing the same brief to a developer. This generator sends nothing to AI.

How this tool works

Turn the app in your head into a brief that an owner, developer, or coding agent can review and test.

Answer 12 questions about the work, data, and rollout
Review the one-page brief and generated acceptance tests
Copy the complete result, then export editable files

A useful product requirements document

A PRD should make the risky decisions reviewable before the first line of code.

For a small internal tool, the important requirements are not a long feature list. Name the people doing the work, the records they need, the states a record can enter, who may change each state, and what happens when data or an integration fails. That is enough structure to estimate a first version without pretending every detail is known.

Acceptance tests turn those decisions into observable behavior. Given/When/Then language helps an owner and developer agree on the starting role and state, one action, and the allowed result. Generated tests are candidates, not proof. Review permissions, destructive changes, migrations, notifications, and stop conditions with the people accountable for them.

Questions owners ask

PRD and internal tool questions

What is a PRD template?

A product requirements document template is a repeatable structure for defining who a product serves, the problem and success measure, data, workflow, permissions, rules, integrations, migration, rollout, and acceptance tests. This version is intentionally scoped to small internal business tools.

Is this a software requirements specification template?

It covers the requirements an owner and developer need for a first internal-tool release, including records, states, permission rules, failure behavior, migration, and acceptance tests. It is not a substitute for architecture, security review, legal requirements, or a regulated-system specification.

What makes a good internal tool PRD?

A good brief is specific about users, records, workflow states, permissions, exceptions, system boundaries, migration, success, and rollout. It separates required behavior from implementation choices and leaves visible gaps instead of inventing details.

Can I give the generated spec to Claude Code, Cursor, or a developer?

Yes, after a human review. Start by asking for a plan, schema, permission model, migration plan, and tests. Do not provide secrets or production data. Require separate approval before deployment, real integrations, notifications, access changes, or destructive migration.

Are the Given/When/Then tests complete?

No. The generator creates one candidate per workflow state plus permission, validation, integration-failure, and migration checks. Owners and users must add exact required fields, role rules, side effects, audit evidence, and industry-specific risks before treating the tests as acceptance criteria.

Will you save or email my product requirements document?

No. Answers remain in this tab unless you choose device saving; reload clears unsaved drafts. Signup unlocks browser-generated Markdown, editable DOCX, and blank templates. The DOCX can be imported into Google Docs; this draft does not create a native Google Doc or upload your answers.