A USEFUL START / FREE RESOURCE
You do not need a technical specification to start a project. You need a shared picture of the problem, the constraints, and what useful progress looks like.
Free PDF · One US Letter page · No signup · Print and write, or use the prompts in your own document.
TRY A TWO-MINUTE SCOPE CHECK
Check what you know. Open questions are welcome in your brief.
0 of 5 starting points covered. You can start the conversation at any point.
Turn this into a project brief ↗BEFORE YOU ASK FOR A PROPOSAL
Leave an honest question wherever something is undecided. A required platform, an unassigned integration, or a missing piece of content is useful information.
Describe what happens today, who does the work, and what should become easier. Start with a real action: requesting an estimate, reviewing an inquiry, or updating a job.
A useful first release will let [person] complete [action] without [current obstacle].
List the existing website, tools, and information the project must work with. Say whether a platform is required or simply preferred, who will edit content, and which accounts or integrations need an owner.
For example: WordPress is required because our team already maintains the content there.
Choose three must-haves for the first release. Put useful later additions in a separate out-of-scope list. This makes it easier to discuss a focused build and compare proposals on the same basis.
For example: publish services, show project photos, and receive estimate requests. Leave a customer portal for a later decision.
Write three things a person should be able to do with the finished work. Include the destination of any inquiry, a failure or missing-information case, and a check on the devices or roles that matter.
For example: a visitor can complete the inquiry on a phone, incomplete entries explain what to fix, and the request reaches the intended inbox.
Name the decision-maker and the person who will maintain the work. Record any real deadline and why it matters. Keep open questions visible so they can be resolved before scope, costs, and delivery are agreed. Share requirements and public links; keep passwords and private customer records out of the brief.
FROM OUR OWN WORK
Owned projectThe website needed to make its capabilities tangible, give visitors a practical way to start a conversation, and make existing products easy to find. Twelve interactive examples across four areas became a useful place to start.
A visitor chooses a mission, tries a working concept, and saves useful ideas. Website, automation, software, and creative services each have a dedicated page with examples and scope guidance.
CanisCore OS opens its own product website and plans. The books link to Amazon. Visitors can explore those products without treating them as a custom project inquiry.
The brief flow prepares an email for the visitor to review and send. Checks covered field validation and prepared message content; the page explains when the message still needs to be sent.
Useful checks cover narrow and wide layouts, interactive examples, navigation and product links, keyboard access, and brief validation. Preparing a brief is a local action; a visitor still needs to send it through their email app.
TURN THE BRIEF INTO A CONVERSATION
Use the worksheet to organize your thoughts, then share the parts that matter through the project inquiry.