Build Sprint · Open now
Build a Real MVP.
Turn one real idea into a small product that a real person can try, and prove you owned it from start to finish.
The brief
What you are asked to do
The goal in one line. Ship the smallest product that solves one real problem for one real kind of person, and show the thinking behind it.
An MVP (minimum viable product) is the smallest working version of a product that a real person can use and give you feedback on. It is not a demo that only works on your laptop, and it is not a long list of features. It is one clear promise, kept.
In this sprint you pick a real problem, talk to the people who have it, write the epics, and steer AI agents to build the first version. You decide what to build and, just as important, what not to build. The agents do the typing. You do the thinking.
You finish with a Product Package: an honest picture of where the product is today, a public page, a name, a catalogue of what it does, a roadmap you can defend, a short demo, and the evidence that you managed the work.
We suggest two to four weeks of part-time work. This is a suggestion, not a deadline: the brief is open until we announce otherwise on this page.
Who it is for
Is this challenge for you?
Good fit
- Learners on the Developer path who want to practise on a real product before, during, or after the six weeks.
- Career changers who want one finished, public project that shows how they think.
- Developers who are moving from typing code to steering AI agents.
- Small teams of up to three who want to build something together in the open.
Not a good fit
- Copying an existing app without a real user in mind.
- Work that hides which parts were written by AI.
- Products that collect real personal data without a clear, lawful reason.
You do not need to be an expert. You need to be curious and honest. Plain English is fine. You can take the free Developer path alongside.
What to hand in
Your deliverables
- A product brief. One page: who it is for, the problem, the promise. Start from the product brief template in the library.
- Evidence from real people. Notes from talking to at least three people who have the problem, written in your own words. Names can be removed.
- Epics and a roadmap. Three to eight epics written by you, in order, with a reason for each place and a list of what is out of scope.
- A working MVP. Running software that a stranger can open or install. A public link is best; clear run instructions in the README is the minimum.
- A five-minute demo. A recorded walk-through or a written script of the real journey, using fake data.
- Product Package folder. The eight-part folder from the Product Package standard, linked from your README.
- An AI-use note. What you used AI for, what you did by hand, and what you checked.
Rules
The rules of this sprint
These come from The Way. Two of them decide most disagreements: people write epics, and you disclose AI use.
- People write the epics and the roadmap. You write every epic and every roadmap sentence yourself, in your own words. AI never does. This is Rule 1 of The Way. Plain, simple English is welcome; clear thinking matters more than perfect grammar.
- Disclose all AI use. Keep an AI-use note in your repository: which tools, for which tasks, and what you checked yourself. Honest use is welcome. Hidden use is the only real way to lose points.
- Everything lives in a public git repository. Your work is a public repository on GitLab.com or GitHub. History matters: judges read your commits, issues and decision log, not only the final result.
- Open source first, and honest licences. Prefer open-source tools. Say which licence your own work uses, and give credit for anything you reuse.
- Fix forward. When something breaks, write down the cause and ship the fix. Do not hide it or quietly undo it. Your decision log should show this.
- No private data, no secrets. Use fake data in demos. Never commit passwords, keys, or real customers’ details. Do not submit anyone else’s work as your own.
- Team size: one person, or up to three. You may work alone or in a small team of up to three people. AI agents are tools, not team members. Name every human who took part.
- Follow the code of conduct. Be kind and specific when you give feedback. The Developer Dojo code of conduct applies to every submission and every conversation about it.
- This brief. The MVP must solve one problem for one kind of person. If you cannot say it in one sentence, shrink it.
- This brief. The roadmap must say what you chose not to build, and why.
Read more: People write epics, Disclose AI use and The Way: five rules.
How it is judged
Judged on the Product Package
Reviewers do not count lines of code. They read your Product Package and score six skills from 1 (beginning) to 4 (strong). The target is level 3 on all six.
A. Whole-product view
Does your map show every part of the product and how the parts connect?B. Customers and personas
Are your personas based on real evidence?C. Journeys and touch points
Did you map what users and customers actually go through?D. Writing epics
Are your epics clear, measurable and in your own words?E. Roadmap and priorities
Can you defend the order, and say what you chose not to do?F. Hand-off to agents
Do agents get instructions clear enough to do the right work?
- Does the product do what the brief promises, for a person who is not you?
- Does the evidence show you learned something from real people and changed your plan because of it?
A missing part of the package is a gap to fix, not a score. Full levels and examples are in the Product Package rubric; the eight parts are in the Product Package standard. Rewards are being finalised, and no prize is promised.
How to submit
Six steps. No form on this site.
You hand in a public repository. This website collects nothing from you.
Make a public repository
Create a free account on GitLab.com or GitHub if you do not have one. Create a new public repository. Use a plain name such as
build-a-real-mvp.Put your work in it
Copy the templates you need. Add the Product Package folder, your epics, your decision log and your AI-use note. Commit as you go: your history is part of the result.
Add a SUBMISSION.md file
In the root of the repository, add the short file shown below. It tells the reviewers where everything is.
Check it as a stranger
Open the repository in a private browser window. If you can see everything without signing in, so can the reviewers.
Send us the link
Use the Curiosity Research Corporation contact form (it opens on the CRC website). Use the subject Build Sprint: Build a Real MVP. Include your repository link and the names or handles of everyone on the team.
Wait for your review
Reviewers score the six rubric skills and write short feedback. We cannot promise a date yet. You can keep improving your repository while you wait, and tell us when you have a new version.
SUBMISSION.md
# Submission: Build a Real MVP
- Team: <names or handles of every human who took part>
- Product: <name and one sentence>
- Product Package: ./product-package/README.md
- Demo: <link or ./product-package/06-demo/>
- AI-use note: ./product-package/08-evidence/ai-use.md
- Licence: <the licence of your work>
- I confirm that I wrote the epics and the roadmap myself.