What a template actually sells: the decision, not the file

A template is a decision somebody already made, written down so you do not have to make it again. Here is what those decisions look like when they are stated — and four lines you can add to any README tomorrow.

AI-assisted writing; every example below is taken from our own product files.

The problem: a file with no decision in it

The real objection to a template is not "is this pretty". It is "will this save me the hour I would have spent rebuilding it".

That question has an answer, and the answer is not the file. It is the decision the file encodes.

Take the budget template in our shop. It keeps planned spend and actual spend in two separate fields, and it carries a status — Planning, On Track, Watch, Over Budget. The reason is not tidiness. Most budgets fail on one technical detail: the planned number and the actual number end up in the same place, so the moment reality arrives, the plan is overwritten and there is nothing left to compare. A budget becomes a running total you look at in a mood.

Now imagine building it yourself. You would have to decide, before writing a formula, whether the plan and the actual live in the same field. You would decide it — maybe the other way — and decide it again the next time you rebuild from scratch.

That decision is the product. The file is only how it travels.

The same holds for a prompt pack, which is only text. "Code review checklist" is a title. What is worth paying for is the part where somebody decided what goes in, what comes out, and in what order: the role frame, the input slots, the output sections, and the rules about what the model may not invent. It is the only reason to buy a pack rather than typing the same four sentences into a chat window.

So what does a decision look like written down? Four things, and each one is checkable. You can verify a stated input and a stated output, and you can read a stated non-coverage, a version and a date. If one of the four is missing, you are looking at a file, not a decision.

Stated inputs: the field, the unit, the example

A template that does not say what to fill in is a blank page with nicer colours.

A stated input is stricter than a label. It names the field, the unit, and what a filled-in value looks like. Ours look like this — an excerpt from one prompt in the Developer Productivity Pack:

Act as a Senior Backend Architect. Design a set of RESTful API endpoints for a
[FEATURE_NAME] within a [DOMAIN_NAME] application. The system must support
[HTTP_METHODS] for interacting with [RESOURCE_TYPE] resources. …
Consider [SECURITY_REQUIREMENTS] to prevent unauthorized access to sensitive user data.

Five slots, named, each with an obvious right answer. A buyer can read that list in ten seconds and know whether they have those five things.

Our Notion templates do the same with properties. The budget template's Expenses database carries six: expense, date, category, amount, need/want, recurring. Two carry the argument:

• Need/Want is a select with three values — Need, Want, Investment — because two identical amounts are not the same decision, and a schema that cannot tell them apart will average them together.
• Categories carries a Monthly Cap (a number, per month) and a Type (Housing, Food, Transport, Health, Fun, Savings, Other), so the limit lives on the category instead of in your head.

Stated outputs and shapes: so you can check it instead of guessing

The second half of the objection is "what do I get at the end". Most templates answer it with adjectives.

The same prompt that takes five slots ends with an explicit output format, and the format is a list of five things in a fixed order:

Output format:
Endpoint URL paths
HTTP Method
Request Payload structure
Success Response body
Error Code list

That is not styling. It is a contract. Check the answer against the list: five sections, in that order, with an error code list that is not empty. If yes, the model followed the template. If not, the pack did not do its job.

Our Notion templates state their output the same way. The daily planner we ship is 5 pages, 4 databases, 20 properties and 52 sample rows, with formulas and views included with their real expressions. The budget template states its views — table and calendar for budgets and expenses, table and board for categories — and names its supporting block: an overspend formula comparing actuals against the category caps. A buyer can hold that against the tool they already use and say yes or no before paying.

Stated non-coverage: the line nobody writes down

Here is the part almost every template skips, and it is what makes the rest believable.

Non-coverage says what the template deliberately does not do. It is not a legal disclaimer and it is not modesty. It is a routing rule: it tells the buyer which need this is the wrong answer to, before they pay.

Three of ours, in our own words:

Research Wiki:    does not replace a citation manager or a document repository.
Daily Planner:    does not provide legal, financial, tax or medical advice.
Developer Pack:   if you are looking for a validated methodology, a document you can sign
                  or file as-is, or prompts that promise to win clients or grow your
                  business, this is not that.

Each one is short, each one is checkable, and each one is a decision.

It is also the line that does the commercial work. A buyer who knows what a thing does not do can decide in minutes; a buyer who has to work it out from a sample download spends an hour on the thing the template was supposed to save them. Stating the limit is what makes the rest of the page trustworthy: a template that will not say what it does not cover has not earned the right to say what it does.

Version and date: so you know what you are looking at

Fourth, and boring, and not optional.

Our template manifests carry a version — the daily planner and the developer pack are both at 1.1.0 — and the planner's README is footed 2026-11-05. A version and a date answer two questions the file alone cannot: which one am I holding, and is it still the one the listing describes.

They also make staleness visible. A template last updated two years ago tells you, before you buy, that the host tool it assumes may have moved on. Without the date, it looks exactly like one updated last week.

Four lines you can add tomorrow

Add this to any template's README tonight. It is the discipline above, compressed into a block the buyer reads first:

## How to use it

Fill in:      <the fields you supply — name, type, unit, one example value>
You get:      <the output shape — pages, rows or sections, in order>
Not covered:  <one line: what this template deliberately does not do>
Version:      v<major.minor.patch> · <YYYY-MM-DD>

What each line prevents:

Two rules make the block work. Every Fill in names a type and a unit, not a topic — "the transaction amount, in your currency" rather than "your data". Every Not covered is one sentence about that template, not a general disclaimer — "does not sync with your calendar" beats "no warranty".

What we deliberately do not ship

Three things we do not publish, and the reasons matter more than the virtues.

We do not publish a premium edition of a template we already sell. A second version of the same decision is not a second product; it is a second file to evaluate and a second thing to keep in sync, and the buyer pays twice for the same hour saved. If a template needs a bigger version, that should be a different template, with its own decision and its own link.

We do not ship templates that need a paid add-on to work. Ours are delivered as documentation plus machine-readable JSON plus CSV, and you paste them into your own account. The prompt packs state it plainly: no accounts, credits or API keys are included in the download, you use your own, and the free tier of a web chat is enough for every prompt in the pack. A template that stops working at a paywall is a subscription wearing a template's clothes.

We do not put customers' data in the template. The sample rows in our templates are ours, written so the views show something on day one. The example outputs in our prompt packs are AI-generated demonstrations, and our copy says so: they are not client case studies and not a benchmark. Shipping a customer's data would mean sending someone's private information to every future buyer, and turning the sample you are reading into a claim we cannot make.

What we sell

Notion Budget Tracker Template — $16, price listed on aukawave8.gumroad.com, Nov 2026.
https://aukawave8.gumroad.com/l/budget-tracker
Five pages, three databases, fifteen properties written out: plan and actual in separate fields, category caps, and an overspend formula that compares actuals against the caps.

Notion Research Wiki Template — $18.
https://aukawave8.gumroad.com/l/research-wiki
Three linked databases for notes, sources and claims, with the citations attached. It does not replace a citation manager or a document repository, and it says so.

AI Prompts for Developers — $29.
https://aukawave8.gumroad.com/l/developer-productivity-pack
Twenty prompts for code review, schemas and API design. Every prompt opens with a role frame, carries at least four named input slots, and ends with an explicit output format, so you can check the answer instead of guessing.

If you take one thing away

A template is not a file. It is a decision somebody already made, and the file is only how it travels.

Say what you want filled in, say what comes out, say what you deliberately do not do, and put a version and a date on it. Four lines. Then a buyer can evaluate the thing in three minutes instead of an hour — and the hour they did not spend is the thing they actually paid for.

This piece was written with AI assistance.