The one-page scope doc that stops AI project creep

You hired a freelancer, bought an AI tool, or finally said yes to building something — and three weeks later the project looks nothing like what you imagined. The budget is bigger, the timeline is longer, and nobody can quite explain how you got here. That's scope creep, and it's even sneakier on AI projects because "we could also make it do X" is always technically true.

The fix isn't a 40-page requirements document. It's one page. Fill it out before a single line of code is written or a single prompt is tested, and you'll have a shared source of truth everyone can point to when the "what if it also…" conversations start.

1. Write one sentence that says what it does

Not a paragraph. One sentence. "This AI tool answers customer questions about our return policy via WhatsApp." If you can't write it in one sentence, you don't know what you're building yet — and that's the real problem to solve first.

Pin that sentence to the top of the document. Every decision made later gets tested against it. If a new idea doesn't fit the sentence, it either changes the sentence (and everyone agrees to that) or it goes on a future-features list. There is no middle ground.

2. List exactly three to five things it must do on day one

Call this section Must do at launch. Number them. Stop at five. These are the non-negotiables — the outcomes that mean the project succeeded. For an AI customer-service bot, that list might look like:

1. Respond to the 10 most common questions accurately.
2. Hand off to a human when it doesn't know the answer.
3. Reply within 60 seconds during business hours.
4. Log every conversation somewhere the owner can read.
5. Never promise a refund it isn't authorised to give.

Five items forces ruthless prioritisation. If everything is a priority, nothing is.

3. Write an equally firm "not in scope" list

This is the part most people skip, and it's the most important section on the page. Every idea that sounds good but isn't in the must-do list goes here. Explicitly. By name.

Something like: This tool will not post to social media, process payments, collect email addresses, or personalise responses based on purchase history. Writing it down makes it a decision, not an omission. When someone says "could it also send follow-up emails?" you can point to the document and say "that's out of scope for this phase — want to add it to the next one?" That's a very different conversation than a shrug and a "sure, why not."

4. Name one person who owns the final call

AI projects attract opinions. Your developer has ideas. Your marketing person has ideas. The AI tool's support docs suggest seventeen more. Without a single decision-maker named on the document, every opinion carries equal weight and nothing moves.

Write: "[Name] is the decision-maker for this project. Disagreements that can't be resolved in the team get escalated to them and only them." That person should be the one who lives with the outcome — usually the business owner. Name them on the page, make sure they know it, and watch how much faster decisions get made.

5. Set a hard "done" date and a review date

AI projects have a particular failure mode: they never officially finish. There's always one more thing to tune, one more edge case to handle, one more integration to consider. You need two dates on the page.

Done date — the day the tool goes live in its current scope, even if it's imperfect.
Review date — 30 days later, when you look at what's working, what isn't, and what (if anything) to add in the next phase.

The gap between those two dates is protected time. No scope changes, no new features. Just learning from the thing that actually exists.

---

One page. Five sections. You can fill it out in 20 minutes. The discipline isn't in the writing — it's in the decision to write it before anything else happens.

If you're running AI projects alongside everything else that comes with owning a small business, that 20 minutes is exactly the kind of task you can hand off. Message a Sidekyk on WhatsApp, describe what you're trying to build, and get a draft scope document back before your next coffee. That's what Sidekyk is for — so you can move fast without losing the thread.