Skip to content

Lesson 09 · 20 minutes

Build Something Real

Pick a role, take a mission, and finish with a working app you can send someone, plus the first case study for your portfolio.

Scroll

Lesson 10 — The road from beginner to AI engineer →All lessons

Build an AI app

Choose your role. Solve a real problem. Build something people can use & finish with a working link and the first case study for your portfolio.

Software Engineer

Make hard things easier to use

Turn a confusing benefits page into a simple checker

Turn a long policy page into six simple questions.

People checking if they can get council support. Many use a phone or speak English as a second language.

The page has 2,400 words and eleven hidden rules. There is no form. The PDF opens in a new tab.

68% of applications are incomplete. Many callers simply ask, "Can I apply?"

Constraints

  • Must work on a five-year-old Android phone
  • No login, no account, nothing saved to a server
  • Reading age 9 or lower
  • Must never say "you are eligible". Only "you look eligible, here is what to do next"

Required features

  • One question per screen, with a progress indicator
  • Simple questions with no policy terms
  • A clear answer: likely eligible / not eligible / need more information
  • If likely eligible: show the amount and what to bring
  • If not: explain why and what they can do next
  • A back button that does not lose answers

Test cases

  • Simple case: Income £19,000. Lived in the borough 3 years. Two children. £1,200 in savings. Never claimed before. — Clearly likely eligible, £340, and a list of what to bring. Should take under 90 seconds.
  • Missing detail: Not sure of exact income. "somewhere around £23,000 or £25,000". Everything else fine. — Should NOT guess. Should say the answer depends on this, explain where to find the figure, and let them continue.
  • Hard case: Income £21,000, lived in the borough 4 months, one child, £800 savings, claimed 14 months ago. — Not eligible because of the 6-month residency rule. Name the rule and say they can apply in 2 months.

Build a simple repair tracker for a housing association

Tenants report a repair and hear nothing. Fix that.

Tenants reporting repairs and the two staff who handle them.

Reports arrive by phone, email and a broken form. They all end up in one inbox. Staff cannot see what is happening.

They need one shared view of every report and its status.

Constraints

  • Two staff, neither technical
  • Must be usable on a laptop and a phone
  • No tenant login. They get a reference number instead
  • Must show a history, not just a current status

Required features

  • One list with filters for status and urgency
  • A page showing the full history of a report
  • Add an update in under ten seconds
  • Warn when two reports may describe the same repair
  • A tenant view: enter a reference number and see the status

Test cases

  • The everyday case: Staff member opens the app to answer a call about R-0412. — Show the status, history and next appointment with no more than one click.
  • Missing information: A tenant calls to report a leak but does not know their flat number, only "the block by the shops". — Allow the report with missing details. Mark what is missing instead of blocking the user.
  • Hard case: R-0416 is the same leak as R-0412, reported again by the same tenant who assumed the first vanished. — Show a duplicate warning. If the reports are joined, keep both histories and keep the original reference number.

Designer

Make it usable by people you will never meet

Fix a public-service form that is hard to use

Find what blocks people, then fix it.

People using screen readers, keyboards, or phones in difficult conditions.

A five-page form has problems many people cannot see. Labels are missing. Errors use colour only. The date field cannot be reached with a keyboard.

Build a tool that finds these problems and explains the fix in simple words.

Constraints

  • The tool must explain each problem and say what to change
  • Must catch problems faced by blind and colour-blind users
  • Must show the most serious problems first
  • Should work on pasted HTML, not require the site to be live

Required features

  • Paste HTML and get a report
  • For each issue: what is wrong, who it affects and how to fix it
  • Show the most blocking problems first
  • Check text colour contrast and show the number
  • Show the problem before and after the fix

Test cases

  • Simple case: The sample HTML from the brief. — Find all six issues: two missing labels, colour-only error, missing image text, button not usable by keyboard, and low-contrast link.
  • Unclear input: <img src="logo.png" alt="logo">. Technically has alt text. — Ask a person to review it. The image text exists, but "logo" does not explain the image.
  • Hard case: A form has correct labels, but keyboard navigation jumps from field 1 to field 4 to field 2. — The tool may miss this. It must say that keyboard order needs a person to test it.

Build a simple brand tool for a community group

Give volunteers a simple way to make consistent posters.

A food bank where volunteers make their own posters in Word, Canva and even Excel.

Every poster looks different, and some are hard to read.

They need a tool that makes good design easy.

Constraints

  • Volunteers, not designers. No software beyond a browser
  • Must work printed in black and white on a bad photocopier
  • Must be readable at two metres by someone with poor vision
  • Use only free fonts

Required features

  • Pick a poster type, add the words, and get a ready layout
  • Use only approved colours that are easy to read
  • Text must stay readable from two metres away
  • Show a black-and-white preview for photocopies
  • Let users print or download the result

Test cases

  • Simple case: "Free hot meals, Tuesdays 12–2, Bridge Street Hall, everyone welcome." — A clean, legible A4 poster in under five minutes with no design decisions required.
  • Too much text: A headline of 90 characters and a body of 400 words. — Keep the text readable. If it is too long, warn the user instead of shrinking it too far.
  • Hard case: The same poster photocopied twice in black and white, second-generation. — It must still be readable from two metres away after two black-and-white photocopies.

Marketing

Make a plan, then test it

Build a marketing plan for a struggling local shop

A real budget, real limits, and a plan that fits both.

The owner of a local hardware shop losing customers to a retail park.

Turnover is down 31% in two years. He has £600 a month, one part-time employee, no email list and little social activity.

He needs a plan he can start Monday and measure.

Constraints

  • £600 a month in total
  • Owner has about 3 hours a week, and hates being on camera
  • No email list, sales system or ad account
  • Must show results within 8 weeks or he stops

Required features

  • Enter the budget, time and limits. Get a plan that fits
  • Each action shows cost, time, expected result and how to check it
  • Show the next 8 weeks on a calendar
  • Show how many extra sales each action needs to pay for itself
  • Show what to cut first if the budget drops

Test cases

  • Simple case: £600/month, 3 hours a week, will not appear on camera. — A plan that fits all three limits with measurable actions, at least one free.
  • The budget drops: Budget cut to £150/month mid-plan. — The "cut this first" order should mean he can drop to £150 without the plan collapsing. And the tool should show what he loses.
  • Hard case: £0 budget, 1 hour a week, and he says the last leaflet drop "did nothing". — Produce a useful £0 plan. Do not repeat leaflets without addressing why they failed. Say if progress will be slow.

Rewrite one message for three types of buyer

Show how one message should change for three types of buyer.

A software team selling to businesses. Their homepage works for founders but not other buyers.

Founders like the message. The buying team finds it vague. Engineers find it annoying.

Build a tool that rewrites the message for each buyer and explains the changes.

Constraints

  • Do not just change the tone. Change the main point when needed
  • Explain why each version fits that buyer
  • Must flag when a claim cannot be supported
  • Use at least three buyer types. Define them by what they care about

Required features

  • Paste a message, pick audiences, get rewrites
  • Each rewrite shows what changed and why
  • A flag when a claim is not supported by the facts given
  • Show the versions next to each other
  • For each version, say what it leaves out

Test cases

  • Simple case: The current headline and subhead from the brief. — Three genuinely distinct rewrites, and "trusted by teams everywhere" flagged as unsupported.
  • Thin facts: A message with no supporting facts supplied at all. — Do not invent proof. Flag unsupported claims and ask for facts.
  • Hard case: A message containing a claim that is false given the facts. E.g. "set up in minutes" when setup takes 2 days. — Catch the contradiction and do not repeat the false claim.

Sales

Prepare better for every call

Build a simple sales call prep tool

Prepare for a sales call in three minutes.

A two-person software sales team handling 6–8 first calls each week.

Reps often prepare at the last minute. They make wrong guesses, miss key questions and end calls with no next step.

Build a tool that turns fifteen minutes of prep into three.

Constraints

  • Must take no more than three minutes
  • Works with whatever you have: a form, a LinkedIn line or an email
  • Must not make up facts about the company
  • Must be easy to read on a phone during the call

Required features

  • Paste what you have and get a one-page summary
  • Likely needs, based only on what the buyer actually said
  • Three useful questions and why they matter
  • Two likely concerns, with honest answers
  • One clear next step
  • Clearly separate facts from guesses

Test cases

  • Simple case: The sample form submission from the brief. — A usable one-page brief in under three minutes, with guesses clearly marked.
  • Very little information: Just an email address and the words "interested in a demo". — Produce a short brief that names what is unknown and what to ask first. Do not infer facts from the email domain.
  • Hard case: A form submission from a company with the same name as a much larger, well-known one. — Must not import facts about the famous company. This checks whether the tool makes up facts. It must not.

Build a tool to review lost sales

Review twelve lost deals and find what keeps going wrong.

A sales lead who thinks the same problems keep causing lost sales.

Every lost sale gets a one-line reason. Most say "price", but the real problem may be something else.

Build a tool that reads the notes and separates what the buyer said from what the evidence suggests.

Constraints

  • Works with messy notes, not neat spreadsheet fields
  • Must separate what the buyer said from what the notes suggest
  • Must not make strong claims from only twelve deals
  • Must suggest what to try next, not just describe the problem

Required features

  • Paste notes and get patterns with the evidence beside them
  • Show what the buyer said next to what the notes suggest
  • Show how sure the tool is, based on the number of deals
  • Show which deals support each pattern
  • Two or three changes to try

Test cases

  • Simple case: All twelve deals from the brief. — Find the company-login pattern in deals 2, 5 and 10. Find the single-contact pattern in deals 1, 4, 7 and 9. Question whether "too expensive" is the full reason.
  • Too little data: Only three deals pasted in. — Say clearly that three deals are not enough to support a pattern.
  • Hard case: Twelve deals where the notes genuinely contain no shared pattern. All different reasons, all different shapes. — Say "there is no clear pattern here". This is the hardest thing for the tool to do, and the most valuable.

Product Manager

Turn noise into a decision

Turn customer complaints into a ranked problem list

Turn forty complaints into five clear problems and rank them with evidence.

A product manager dealing with support tickets, feature requests and one very loud customer.

Complaints arrive from many places. The same complaint can hide different problems.

Today, the loudest customer wins. Build a tool that ranks problems by how much they matter instead.

Constraints

  • Must separate what users report from the real problem
  • Must rank by how much a problem matters, not by who complains most
  • Must show the tickets behind every problem
  • Must show when many complaints come from one customer

Required features

  • Paste complaints and group them into real problems
  • For each problem, show how many people are affected, what type of customer they are, and how serious it is
  • Show what users see separately from the likely real problem
  • Rank the problems and show why
  • Warn when many complaints come from only a few people

Test cases

  • Simple case: The twelve sample tickets from the brief. — Split export into speed, format and missing-column problems. Show dark mode as a few users. Show invites as a reason trials do not become customers.
  • Unclear complaints: Five tickets that all say some version of "it is slow" with no detail. — Should say it cannot identify the real problem and name what to ask next. Not invent three plausible-sounding real causes.
  • Hard case: One enterprise customer worth 40% of revenue files 15 complaints in a week. Everyone else files 3. — Show that the customer brings in a lot of revenue, but is still only one customer. Do not hide either fact.

Build a tool that ranks product work and challenges the scores

Show the guess behind every score.

A product manager whose work list changes with the loudest voice in the room.

The team scores ideas, but people often choose the score that supports the answer they already want.

Build a tool that shows the guess behind each score. The team can then debate the evidence, not just the number.

Constraints

  • Every score must include a written reason or guess
  • Must show what would make the order change
  • Must not treat a score as proof
  • Should work for a list of 8–20 items

Required features

  • Enter items with scores and the reason behind each
  • Show the reason or guess behind each score
  • A what-if view showing what could change the order
  • Check whether each item supports the quarter goal
  • Warn when a high score has no evidence

Test cases

  • Simple case: All eight work items with their scores. — Rank work by the goal of turning trials into paying teams. Item 3 should rise. Item 8 should be marked as a weak fit.
  • Missing reasons: Items entered with scores but no reasons. — Do not rank items with blank reasons. If you do, show a very clear warning.
  • Hard case: Two items have the same score, but only one supports the quarter goal. — Do not break the tie at random. Show which item better supports the goal and leave the final choice to a person.

CEO / Founder

Make decisions with the key guesses visible

Build a tool to compare a real business decision

Compare the options, risks and key guesses behind a £200,000 decision.

A founder deciding how to use £200,000.

The team has debated this for six weeks. Nobody has written down the key guesses behind each option.

Build a tool that shows exactly where people disagree.

Constraints

  • Must compare each option and show its key guesses
  • Must show what needs to be true for each option to work
  • Must include the option of doing nothing
  • Must not produce a single recommended answer. That is the human's job

Required features

  • Compare each option over 12 and 24 months
  • Let the user edit every input and see the guess behind it
  • A what-if view showing which guess changes the result most
  • Show the main risk for each option, including slow problems that are easy to miss
  • Compare the options without picking a winner

Test cases

  • Simple case: All four options with the key guesses given. — Compare all options over 12 and 24 months. Every number should link to a stated guess. Do not pick one winner.
  • Unknown value: The founder does not know how long new sales reps need to become fully productive. It could be 3 to 8 months. — Accept a range and show how much the result changes. Do not quietly choose one number.
  • Hard case: Set the drop in customer losses for option B to zero. The rebuild does not help at all. — Show the failure case and its cost. The tool must not assume every option works.

Build a hire, outsource or automate calculator

Compare what hiring, outsourcing and automation really cost.

A founder spending evenings on admin work that keeps growing.

The work takes 25 hours a week across new-customer setup, invoicing and reporting. The options are to hire, outsource or automate.

Comparing salary with an agency bill misses many real costs.

Constraints

  • Must include management time, training time, tools and ongoing upkeep
  • Must show what happens when the workload doubles or halves
  • Must include the ongoing work needed to maintain automation
  • Must allow a mix of options

Required features

  • Enter the workload and value your own time
  • Compare all three options and mixes. Include hidden costs
  • Show the result if the workload doubles or halves
  • Show when each option pays for itself
  • Show what becomes harder to change with each option

Test cases

  • Simple case: 25 hours a week, with the founder's time worth £120 an hour. — Compare all options, include hidden costs, and show when each one pays for itself.
  • Unknown value: Founder has no idea what their own hour is worth. — Show several possible values instead of forcing the founder to pick one number.
  • Hard case: Volume halves instead of growing. The workload drops to 12 hrs/week in month 4. — Hiring should look worse. Clearly show the cost of undoing that decision.