How to write a Moonlabs application that gets a yes
We read every application personally. We say no to about nine in ten. The yeses share specific patterns and the nos share specific failures. Here is the honest list, so you can write yours sharper.
We read every application to Moonlabs personally. Both of us. Every one. We say no to roughly nine in ten. This is not because the applicants are bad — most are perfectly competent — but because the things we are actually looking for are narrower than the things the application form appears to ask for, and only a minority of applicants notice the gap.
This essay is the list. It applies to both the Incubator and the Academy, with a few specific notes for each at the end. We are publishing it openly because we would rather get sharper applications than play a guessing game.
The thing nobody tells you about accelerator applications
The standard advice on applying to accelerators is to write the application like a pitch. Demonstrate the market, the team, the traction, the ask. This is the advice that gets repeated everywhere and it is almost right. The part that is missing is that for an operator-led incubator like ours, the application is not just a pitch — it is a sample of how you think. We are not deciding whether your business will succeed in the abstract. We are deciding whether the version of you that wrote the application is the version of you we would happily spend a year sitting next to.
That changes what we read for. We read for taste, judgment, self-awareness, and operating speed. The product idea is almost secondary. We have backed companies with weak initial ideas because the application showed the founder thinking clearly. We have passed on companies with strong initial ideas because the application read like the founder had been told to apply by someone else and was going through the motions.
If you take one thing from this essay: the application is the work product. Treat it as such.
The five signals that move you toward a yes
Signal one: you can name the buyer. Almost every weak application talks in abstractions. "Small businesses struggle with..." / "People want..." / "There is a gap in the market for...". Almost every strong application names a specific, identifiable buyer category and what they pay for today. "Independent letting agents in the East Midlands, charging £900-£2,000 in tenancy paperwork fees, lose two hours per let to a process that..." . The first sentence of a strong application is almost always a buyer description. Write yours that way.
Signal two: you can describe what hurts the buyer today, in their words. This is the strongest single signal in the entire application. Founders who have actually spoken to the buyer describe the pain in language the buyer would recognise. Founders who have not spoken to the buyer describe the pain in language the founder thinks sounds professional. The difference is unmistakable to anyone who has done both. If you have not spoken to ten of the people in your target buyer category before you apply, your application will read like the second category, and we will know.
Signal three: you know what you do not know. A surprising amount of weight in our reading goes to applications that are explicit about their open questions. "I'm not sure whether the right price is £200 a month or £2,000." "I do not yet know whether the cost-of-goods scales linearly with the AI inference." "I have not tested whether buyers will commit to a 12-month contract." These are stronger statements than confident answers, because they reveal that the founder has thought hard enough about the business to find the cracks. Founders who claim certainty on everything are either lying to themselves or have not done the work. Both are red flags.
Signal four: the writing is operator-direct. This is a specific stylistic preference. We respond well to applications that read like a Slack message from a competent operator, and badly to applications that read like a consulting deck. No buzzwords. No mission statements about "empowering" or "democratising". No quotes from McKinsey reports. Concrete sentences with verbs in them. If you are not naturally a punchy writer, this is the one place to spend an hour with a model that can sharpen prose. Most applications would be twice as good with half as many words.
Signal five: there is a hint of velocity. The single biggest predictor of who succeeds in the cohort is how fast they execute when the meeting is over. We can usually pick this up from the application by indirect evidence. Has the founder shipped something, even small, in the last quarter? Have they spoken to someone in the buyer category in the last month? Is the application written tightly, by someone who clearly does not waste time? Applications that read like they took six months of agonising and three drafts to compose are signals of low velocity, almost regardless of the words on the page.
The five failures that move you toward a no
Failure one: the application is a fund-raising pitch. Strong founders sometimes default to the deck they have spent six weeks polishing. The deck answers different questions. It is selling the business. The application should be selling you, and your understanding of the business. A polished deck pasted into the application box is, paradoxically, a weak signal.
Failure two: the market is sized but the buyer is not named. Anyone can find a £4bn TAM number for any market. The number is essentially meaningless. We have backed companies in £30m markets where the founder had a credible path to 30% share. We have passed on companies in £4bn markets where the founder could not name a single buyer who would commit to a pilot. Size is downstream of buyer, not the other way around.
Failure three: a co-founder is mentioned but never described. If you are applying as a team, we want to know how you met, how long you have worked together, what the worst week of working together looked like, and what each of you is responsible for. Applications that mention "my co-founder" without any of this detail are red flags because the failure mode for a founding team is not lack of competence; it is lack of resilience. We want evidence of resilience, not just an org chart.
Failure four: the ask is fuzzy. "I want to be part of the Moonlabs ecosystem." "I'm looking for a community of founders." "I need help with my pitch." These are real things you may want, but they are not actionable asks. The strong version is more specific. "I want technical co-founder leverage for the build and warm introductions to UK property-tech investors when the round opens in Q3." That is a thing we can decide yes or no on. The fuzzy ask is impossible to evaluate, so it defaults to no.
Failure five: the application reads like someone else wrote it. This is the most painful one to call out because the founder usually genuinely did write it, but they wrote it in someone else's voice — a startup blog they read, a YC application template, a guide they bought from someone on Twitter. The voice mismatch is detectable in the first paragraph. We would much rather read an awkward, specific, honest application in your real voice than a polished application that sounds like every other one we read this month.
A few specifics for the Incubator
For the Incubator specifically, the question we are most trying to answer is: would we put 1% of our equity into this person and this idea, knowing we will be in the trenches together for six months and on the cap table forever. That is a very specific yes/no. Things that move the needle:
- A buyer who is already on the hook for the problem in cash terms (not "we have interested users" — actual paying customers, even for the manual version of the service).
- A founder who has lost money on something before. Resilience is a learned skill and the cheapest way to learn it is to have spent £30,000 of your own money on a failed prior project.
- An idea that is unfashionable in a way that is legible. We are not looking for AI-coded T-shirts. We are looking for AI-flavoured operating businesses with a real P&L. The kind of company a non-tech-savvy uncle at a wedding would understand.
A few specifics for the Academy
For the Academy the bar is different. We are not asking whether your company will succeed — we are asking whether you will get more out of twelve weeks than anyone else in the cohort. Things that move the needle:
- A demonstrated track record of finishing things, however small. A repo with three projects shipped is worth more than a CV with three internships.
- A clear answer to "why now?" — what changes about you and your trajectory if you spend the autumn of 2026 in our Derby cohort versus doing the third year of your degree as planned. The honest answer is the right one.
- Some evidence that you have already tried to learn the material on your own and got stuck, or got far. We want to see effort that pre-dates the application. Effort that started the day the application opened is harder to weigh.
What we do not weigh much
Things you may worry about that we put almost no weight on:
- Where you went to university. Genuinely, almost zero.
- Whether you have prior startup experience. Helpful but not required.
- Whether the deck looks beautiful. We barely look at the deck on a first read.
- How polished the website is. We mostly check whether the product link works.
Final note
The strongest single thing you can do to write a better application is to read it as if someone else wrote it, the day after you finish, before submitting. Almost every application improves dramatically with one round of self-edit. Cut the things that sound like everyone else. Sharpen the buyer description. Make the ask specific. Add the one open question you are not sure about.
We will reply to every application within a week. If we are a no we will tell you why, in usable detail, so the next application you write to someone else is sharper. If we are a yes we will get on a call inside the same week.
Applications are at /apply. We look forward to reading yours.
James Freestone is co-founder of Moonlabs. He reads every Incubator and Academy application personally alongside Louis O'Connell-Bristow.
James Freestone
Co-founder, Moonlabs. Operator behind home.co.uk, Homemove and homedata.co.uk. AI-native since the week ChatGPT shipped.
Work with usKeep reading
All essaysTwelve deliverables — the anatomy of a Moonlabs cohort portfolio
Every Moonlabs Academy graduate leaves with the same twelve artefacts. This essay walks through what each one looks like and why we chose it...
Why sponsoring an engineer through the Academy beats hiring one
For most UK companies in 2026, the cheapest way to get an AI-native engineer onto the team is not to hire one. It is to send someone you alr...
Why the Incubator charges a £999 commitment fee
We added a £999 commitment fee to the Incubator agreement in 2026. It is credited back in full against the success fee at round close — so i...