Claude Projects for Small Business: Stop Re-explaining Yourself

The problem a project solves is specific: you explain the same things in every conversation - what the business does, how you price, what tone you write in. A project holds the context, so every conversation inside it starts already knowing.

The first mistake: one project for the whole business

The instinct is to build "the business project" and put everything in it - price list, contracts, service descriptions, procedures, marketing material.

And that produces a project which answers everything vaguely. When the material contains prices, legal wording and marketing tone all at once, every answer is an average of the three.

The useful unit is a recurring job, not an organisation:

A simple test: if you cannot describe the project in one sentence, it is too broad.

What to put in

Examples, not descriptions

This is the point that most changes the quality of the result.

A paragraph explaining "we write in a friendly but professional tone" is worth far less than three real proposals you sent. The example contains the tone, the structure, and what you do and do not write - everything that is hard to articulate.

The same principle applies to any generated document: the material you supplied determines the result more than any instruction.

Whatever you find yourself typing again

It is worth noticing this over a week. Anything you typed more than twice as context belongs in the project.

The boundaries

Not only what to do - also what not to. What not to promise a client, which service you do not offer, which wording is not in use. A written boundary prevents an embarrassing answer.

What not to put in

• Personal data that is not needed. A customer list is not required to write a proposal - the proposal structure is.
• Secrets. Passwords, keys, access details. Never.
• A superseded document. That is the next problem.
• Everything, just in case. Material that is too broad dilutes.

The real failure mode: content that went stale

This is the big problem, and it is silent.

A project holding last year's price list will answer with complete confidence using last year's prices. Nothing in the answer signals that it is out of date - it sounds exactly like a correct answer.

And it worsens over time: three versions of the same document accumulate, and there is no telling which one the answer rested on.

Two rules:

1. Replace, do not add. A new version removes the old one. If both are in, both can be drawn on.
2. Put a date inside the document itself. "Price list effective from..." on the first line - so that even if an old one stays, it is visible.

And a worthwhile check: once a quarter, open each project and ask of every file - is this still correct? Ten minutes that prevent a proposal with a wrong price.

The difference from a connector

A point that confuses people: a project holds material you uploaded; a connection reaches material where it lives.

Which when: a project for what needs to be fixed and exact - the price list you work from, your tone. A connection for what changes and cannot be uploaded in advance.

If you have employees

A shared project does something hard to achieve otherwise: the same context for everyone. A new employee does not need to know how you write - it is in the project.

Two points:

• Who updates it? Without an answer, the material goes stale. That is a role, not a habit.
• The output is a draft. A good project produces drafts that sound like you, which is exactly what makes them persuasive even when they are wrong. Someone reads before it goes out.

What it is not

• It is not automation. Nothing runs - someone starts a conversation. The project removes the re-explaining, not the asking.
• It is not a source of truth. The real price list lives where it lives; the project holds a copy, and that is precisely what creates the staleness risk.
• It does not fix a disorganised business. If there is no settled price list, a project will not create one - it will reflect the disorder.

How to start

1. Pick one job that recurs weekly and where you explain the same things.
2. Collect three to five examples of your own output.
3. Write five lines of context - what the business is, who the audience is, what not to do.
4. Use it for two weeks and add only what you noticed was missing.
5. Put a quarterly review in the calendar.

The common mistake is starting at step two: spending a day building a perfect project, then discovering most of what went in was unnecessary and what was missing never went in. Start narrow and expand where it gets stuck.