Projects as reusable setups

A Project is a container for context. Used properly it's the difference between a good afternoon and a changed process.

Reviewed September 2026. This page names fast-moving vendor detail, so it carries a review date.

What goes in the project, and what you still type each time

Stated once, in the project

Who the business is and what it does, in three lines.
House style: the words you use and the ones you never use.
The standing boundary — what must never appear in an output.
Reference documents: your templates, a good past example, the current fee schedule.
The format you want back, if it is always the same.

Typed fresh in each conversation

The specific job, in one or two sentences.
Who this particular output is for.
Anything unusual about this instance.
The material for this job, if it is not already a reference file.

The test of a good setup is whether a new starter could produce an acceptable first draft using the right-hand column alone.

What goes in one

Instructions: who you are, who reads this, the standing rules, the refusals.
Examples: three past documents of the type you want produced.
Reference material: the style guide, the checklist, the scope inclusions.
The boundary: what this Project must never produce.

One per document type, not one per client

The common mistake is a Project per client, which multiplies maintenance and puts identifiable material in a container that gets shared. A Project per document type — vendor report, progress report, quote, scope letter — stays maintainable and keeps client detail out.

Keeping it current

One named owner per Project.
A quarterly read against a recent real document.
Examples replaced when the house style moves, not added to indefinitely.

The equivalent elsewhere

ChatGPT’s custom setups do the same job with different mechanics. The content you write is the asset and it moves between them, which is the whole argument for learning both.

What goes in a Project, and what doesn't

In: the context that's true every time — your house style, two or three good past outputs as examples, the structure your documents follow, the things you never say, and the checking step.

Not in: anything specific to one instance of the job, and anything from your never list. A Project is shared and durable, which makes it exactly the wrong place for client material.

Why this is the block that makes training stick

A session that teaches method produces a good afternoon. A session that ends with two or three setups built on your real documents produces a change that's still there next month, because the effort of getting a good result has dropped to nearly zero for at least one job.

The part teams skip: writing down what to change when the template changes. Without that page, the setup is stranded with whoever built it.

A workflow build ends with exactly this, on one job, with your hands on the keyboard.

Start an enquiry

The questions we get asked about this

Does everyone need a paid plan for this?

Shared setups are a paid-tier feature at the time of writing, and it's one of the few places we'd say the paid plan earns its money for a team. We confirm the current position at the start of an engagement rather than quoting it here.

Get a training plan built for your business. Nine questions about how your business actually runs. You get a plan ordered for your work, a reading on where you're exposed, and one clear place to start. No account needed. Build your plan.