Author :
Diana Sharma
The question we get asked more than any other is some version of "is my idea right for this?"
It usually arrives apologetically. People tell me their idea is probably too small to count, or they worry it is far too ambitious for one person, and either way they are asking me to tell them whether to bother.
So here is the answer in public.
Almost no idea is wrong for this programme. Scope is what is wrong, or right. And scope is the thing we fix in the first fortnight, before you write a line of code.
Ten weeks sounds like a long time until you lay it out.
Weeks one and two are idea and validation. You bring an idea or you find one, you test it against real people, and you agree a scope with your mentor.
Weeks three and four are design and set-up. Your product and data model, your environment, your repo, your AI development workflow running properly.
Weeks five to eight are build, test and iterate. You build the core, put it in front of real users more than once, and change it based on what they actually do rather than what they say.
Weeks nine and ten are documentation and your pitch.
Which means the real building window is about six weeks. Six weeks, one person, learning while they build, most of them working around a job or a business that already exists.
That is the constraint that matters. Not your ambition, and not how clever the idea is. So when you ask whether your idea fits, the honest question underneath it is whether a useful slice of that idea fits into six weeks of work by someone who is learning as they go, with a working developer reviewing what they produce every week.
One question, and it holds up better than any framework I have seen:
Can one person, using this product, get one useful thing done from start to finish?
If the answer is yes, it fits. Everything else is version two.
That is a lower bar than most people set for themselves, and it is deliberately lower. A product that does one thing completely is worth more than one that does six things halfway, both to the person using it and to you at the end of ten weeks.
Here is what that looks like in practice.
The idea. You groom dogs, or you do mobile physio, or you mow lawns. Bookings arrive by text, Facebook message and phone call. They live in your head and in a diary on the passenger seat.
What you build. Customers see your real availability, book a slot, and get a confirmation and a reminder. You see today's jobs on your phone, mark them done, and the system stops you being double booked.
What you leave out. Payments, recurring bookings, staff rosters, route optimisation, a customer app. All version two.
Why it works. One user, one loop, and real users available from day one. You can test it with five people you already know by the end of week three, which matters more than almost anything else on this list.
The idea. Quoting eats an evening a week. Every quote gets rebuilt from scratch, and a good share of them never get sent at all.
What you build. A price list you control, a form that assembles a quote from it, a record of what you sent and when, and a button that turns the messy notes you typed on site into a first draft.
What you leave out. Invoicing, accounting integration, e-signature, job costing, multiple users.
Why it works. The AI does one contained job, turning unstructured notes into a structured draft, with a person reviewing the result before it goes anywhere. That is the shape of most good AI features, and it is the shape most people get wrong by trying to make the model the entire product.
The idea. Connecting tutors and parents, or growers and restaurants, or tradespeople and homeowners.
Marketplaces are the most common idea we see and the hardest thing on this list to do in ten weeks, because they need both sides to arrive at once or neither side gets any value. So you do not build the marketplace. You build one side of it as a tool that stands up on its own.
What you build. A tutor gets a profile, sets their availability, has a booking link they can share anywhere, and keeps a record of sessions and payments owed. Useful to a tutor who has no parents on the platform at all, because they already have their own.
What you leave out. The second side, search and matching, the payment split, reviews, trust and safety.
Why it works. You have something usable in week five, and you find out whether tutors actually want it long before the liquidity problem gets a chance to kill you. If they do, you have supply, which is the side everyone else struggles to get.
The idea. You work somewhere where shift handover happens on paper, or in a group chat, or in a spreadsheet nobody trusts. Everyone complains about it and nobody owns fixing it.
What you build. Structured handover notes, searchable history, and flags that carry forward until somebody closes them.
What you leave out. Single sign-on, integration with the system of record, a native app, any permissions model beyond two roles.
Why it works. Your users are down the hall, which makes user testing trivially easy. One caution: sort out with your employer early what you are allowed to build and own, and get their position in writing before you are deep into week three. Build against synthetic or de-identified data unless you have explicit permission otherwise. Raise it with your mentor in week one and we will help you work out what needs to be agreed.
The idea. You vibe coded something over a weekend and it half works. Then it broke, you could not find the problem, and you have quietly stopped opening it.
What you build. The same product, built deliberately this time, with a data model that makes sense, authentication that actually works, and code you can explain to somebody else. It may well end up smaller than what you have now.
What you leave out. Most of the features you added because they were easy to prompt for.
Why it works. You already have the hardest part, which is a clear picture of what the thing should do and evidence that you want it to exist.
Worth saying plainly: people find this route harder emotionally than starting fresh, because throwing away work you have already done feels like going backwards. It is not. You are keeping the understanding and discarding the scaffolding.
I would rather tell you now than in week six.
Anything where the hard part is hardware. If your product needs a physical device to exist before the software means anything, ten weeks is not the container for it.
Anything where the app store is the deadline. You can build for mobile, and you should if that is where your users are. Build it as a mobile web app. Native builds plus store review is a different project with a different timeline.
Regulated data. Health records, lending, credit decisions, anything that needs a licence or a clinical safety case. You can build the product. You cannot ship it inside ten weeks, and the compliance work will eat the build.
Anything that needs a data set or content library you do not have. If your product is only useful once there are two thousand recipes or ten thousand listings in it, the build is not your bottleneck.
Anything that only becomes useful at scale. Network effects, liquidity, community. Same problem as the marketplace, and the same answer: find the slice that is useful to one person on day one.
"An AI that..." where the value sits in training or tuning a model rather than in the product built around one. Using a model well is very much in scope. Building the model is not.
None of these means do not do it. It means the ten weeks buys you a slice of it, and we will help you pick which slice.
This happens with your mentor in the first fortnight, and it is one of the more useful conversations in the programme. Three questions:
The third one is the real question. If you cannot answer it, the scope is not agreed yet, it is just a wish list you have put in an order.
We sell this programme, so you should take my encouragement with the appropriate amount of salt. Here is what I would say anyway.
Scoping down is not so that you have less to do and we have less to support. Ruthless scoping is one of the habits the programme is actually there to build. Most solo ventures I have watched fail did not fail because the idea was too small. They failed because the founder spent nine months building version four before anyone had used version one.
Ten weeks forces the discipline. The discipline is the point. The product you end up with is the proof you did it.
Bring it. A fully formed plan, a note on your phone you keep reopening, a prototype that broke, or nothing at all beyond the sense that you want to build something. Weeks one and two handle all four starting points.
Applications for the founding cohort are open now. Founding pricing closes on Sunday 18 October and the cohort starts on Monday 19 October.
If you are not sure whether your idea fits, send it to us and ask. I would rather tell you honestly that ten weeks is the wrong container for it than take your enrolment and have you find out in week six.