The most detailed free FDE + DevOps library: 140+ lessons, 70+ labs and 80 long-form articles, in English and Turkish. Start learning →

TürkçeSearch

Build with AI: From Zero to Your First App · Module 2: Writing useful prompts and briefs · Lab

Sort the Scope: Version One, Later, Out

30 min hands-on · Core

Browser only. The feature pile below is provided as starter material; you need no account anywhere.

Three ways to do this lab. A: the browser steps below, the main path, free with no account. B: try the same task with your own AI tool if you have one (its terms and quotas apply). C: work from the provided material and the worked solution below, which teaches the same skill. No path claims you used a live AI tool when you did not.

Objectives

  • Sort a mixed feature pile into version one, later and out
  • Strip payment, login and reservation dependencies from version one
  • State the dependency reason for every parked item in one line

  1. Step 1

    Sort the pile

    Below are twelve requested features for the same pide house. Sort each into VERSION ONE (max three), LATER (named release) or OUT (explicitly rejected with a reason). Version one must work with no payment, no login and no reservation system.

    feature-pile.mdmarkdown
    FEATURE PILE (synthetic practice material)\n---\n1. Menu with prices\n2. Opening hours\n3. Phone-order form (name, items, pickup time)\n4. Online card payment\n5. Customer accounts and login\n6. Table reservations\n7. Delivery tracking map\n8. Photo gallery\n9. Customer reviews\n10. Multi-language menu (two languages)\n11. Order confirmation echo\n12. Loyalty points

  2. Step 2

    Write the reasons

    For every LATER and OUT item write one line: the dependency or cost that parks it (needs payment provider, needs accounts, needs daily moderation, doubles content work). No item may be parked with 'maybe later' alone.

  3. Step 3

    Check version one

    Read your version one as a build plan: can it be built in small checkable steps with a browser only? If any item secretly needs payment, login or reservations, move it out and replace it.

How to confirm it worked

  • Version one holds at most three items and needs no payment, login or reservations
  • Every parked item carries a one-line dependency or cost reason
  • Photo gallery, reviews, second language and loyalty are parked or out, never in version one
  • Version one reads as browser-only buildable steps

Workspace

0/2 checks passing · Coverage only, not a quality score.

Draft kept in this browser.

Hints, in three stages

Stage 1: a nudge

Version one is menu, hours and the order form plus its confirmation echo. Everything else is a second project wearing a feature costume.

Stage 2: a direction

Reviews need moderation, a second language doubles every text change, loyalty needs accounts. Name the cost, then park it.

Stage 3: almost the answer

If you are unsure between LATER and OUT, choose OUT with a reason. A short out-list beats a long later-list that silently becomes scope.

Worked solution (open after an honest attempt)

Worked solution. VERSION ONE: menu with prices, opening hours, phone-order form (name, items, pickup time) plus the order confirmation echo (part of the form step, not a fourth feature). LATER: photo gallery (needs photo sourcing and compression work), second language (doubles every text edit), reviews (needs daily moderation). OUT: online payment (needs provider contract and fees), accounts and login (needs password storage and reset flow), reservations (needs table-state management), delivery tracking (needs driver app), loyalty points (needs accounts plus fraud thinking). Each parked line names its dependency, version one builds in a browser in six small steps, and the owner can still take lunch orders on day one.