Scope a website project from a discovery call

Goal

Turn a discovery call into a scope our developers could price without needing another call. You can work from a practice call, or from the written scenario below.

Choose your source

Option A: a practice call. Run a 20 to 30 minute practice discovery call with another intern or your team lead, playing the owner of a local business. They should decide the business's situation beforehand, so your questions get real answers.

Option B: the written scenario. Use these notes. The business is fictional, written for this exercise.

A family-run bakery with two shops in the same town. Their current website is a single page built years ago by a relative. It isn't mobile-friendly, and browsers show a "Not secure" warning on it. The domain is registered in the relative's name, and the bakery uses email on the same domain.

They want customers to find opening hours and directions for both shops, browse their cakes and bread, and order celebration cakes online for collection, paying a deposit when they order. Today cake orders come in by phone and message and are written in a paper book, and orders sometimes get muddled.

The owner's daughter will update products and prices from her phone a few times a month. The shops take card payments with a terminal from a payment provider.

They'd like the new site running before their busy season in December. They mentioned that a loyalty scheme would be nice "one day". They haven't set a budget, and asked what it would cost.

Steps

1. Summarise the situation and goals in the client's words, in no more than five sentences.
2. List the users and devices: who will use the site, and how.
3. List the pages and features, sorting each feature into must-have, nice-to-have or later, with a one-line reason.
4. Describe each feature specifically, as in the lesson "From discovery call to scope". "Online cake orders" on its own is not enough.
5. Cover editing, content and integrations: who updates what, who supplies content and by when, and which tools must connect.
6. Cover the technical setup: domain, hosting, email and HTTPS, including any access risks.
7. List constraints and risks: deadlines, content, approvals, access and third parties.
8. List open questions, marking each one for the client or for the developers.
9. Suggest a first phase in case the full scope doesn't fit the deadline, saying what it includes and why.
10. Write a short recap message to the client, as you would after a real call, summarising what you heard and what happens next.

Rules

• Don't estimate a price or promise a timeline; that is the developers' job. You can note which factors will make the project bigger.
• Don't invent answers. If the notes don't say, it's an open question.
• If you run a practice call, use a fictional business or a real type of business, and no real customers' personal details.

How to submit

Put everything in one shared document, give Skillhancer Labs staff view access, and submit the link below with any notes for the reviewer. If you chose Option A, include your raw call notes too.

What reviewers look for

• The scope is specific enough that two developers would picture the same project
• Features are sorted sensibly into must-have, nice-to-have and later, with reasons
• Technical risks, such as domain access and email, are spotted and flagged
• Open questions are listed instead of guessed
• No prices or dates are promised
• The client recap is short, clear and free of jargon