How to build something worth talking about.

Part One

Find a problem worth solving.

Most students start with "I want to build an app" or "I should make something with AI." That's backwards. You're starting with a solution and hoping a problem appears. It never does, and you end up with a project that solves nothing and excites nobody.

Start with friction. What's annoying in your daily life? What do your parents complain about? What does your school do badly? What takes ten steps when it should take two? Write down five things that genuinely frustrate you over the next week. Don't filter. Don't try to be clever. Just notice.

Now pick the one where you can see the people who have the problem. Not billions of people. A classroom. A sports team. Your family. The tighter the group, the easier it is to talk to them and the faster you'll understand what they need.

Part Two

Scope it so you can ship in 12 weeks.

Twelve weeks sounds like a lot until you subtract school, exams, weekends you lose, and the two weeks you'll spend stuck on something you didn't expect. You have about 50 real working hours. That's it.

So you need to cut. Ruthlessly. Take your idea and ask: what is the smallest version of this that a real person could use and get value from? Not a demo. Not a mockup. Something that works. If your scheduling tool idea needs a login system, a database, notifications, a calendar view, and admin controls, you don't have 50 hours. You have a login page and a broken promise.

Pick the one feature that solves the core problem. Build that. If it works, you can always add more. Nobody has ever been penalised in an interview for saying "I built the core and it worked, and here's what I'd add next." That's what people who ship things sound like.

Part Three

Talk about it so people care.

This is where most students fall apart. They build something decent and then describe it like a spec sheet. "It's a web app built with React and Node that uses a PostgreSQL database to..." Nobody cares. Not the admissions tutor, not the interviewer, not the investor.

Here's the structure that works every time. Four parts, in this order:

The problem. Who has it, how bad is it, how did you find out. You want the other person nodding before you've even mentioned what you built.

What you built. One sentence. Keep it plain. "So I built a tool that shows every room change on one screen, updated live." Done.

What went wrong. This is the part that separates you from everyone else. Talk about the thing that broke, the assumption that was wrong, the week you nearly scrapped it. This is where interviewers start paying attention because it proves you did the work rather than outsourced it.

What you learned. Not "I learned teamwork and time management." Something specific. "I learned that users don't read instructions, so I redesigned the whole flow to need zero onboarding." That's a real lesson from a real project.

Now what

You have the framework. The hard part is doing it alone.

This playbook gives you the structure, but structure isn't the bottleneck for most students. It's knowing whether you've picked the right problem, whether your scope is tight enough, whether your story lands. Those are judgement calls, and they're hard to make when you're inside the project looking out.

That's what I do with my mentees. We meet every week, work through this framework together, and I push back on the things that aren't working before you waste three weeks on them. If you want that, book a call and we'll figure out if it's the right fit.