Blazonshots Blog
How to Validate a Campus App Idea in One Week Without Writing Code
Most student founders validate their idea by building it first and asking questions later. It feels productive, because code is visible progress. But it answers the wrong question at the wrong time. Before you know whether an idea is worth building, you need to know whether anyone actually wants it — and that can be tested properly in about a week, without opening a code editor.
Why building first is the expensive way to find out
Writing code creates a strong illusion of progress. Every commit feels like movement, and movement feels like validation. But a working prototype answers "can this be built," not "should this be built." Those are different questions, and the second one is the one that actually determines whether a campus app survives past its first semester. Testing demand before development flips the order: you spend a week finding out if the problem is real and painful enough, then you spend the following weeks building something people are already waiting for.
Day one and two: write the one sentence that has to be true
Start by writing a single sentence: "[Specific group of students] struggle with [specific problem] when [specific situation], and currently deal with it by [current workaround]." Every word in that sentence should be concrete. Not "students struggle with food" but "second-year students living off-campus struggle to find affordable meals between back-to-back afternoon lectures, and currently deal with it by skipping lunch or overspending at the nearest kiosk." A vague sentence produces vague validation. A specific one gives you something you can actually go and check against reality.
If you cannot write this sentence with specifics in every slot, that is useful information on its own — it usually means the idea started from a feature you wanted to build rather than a problem you watched someone struggle with.
Day three: go find twenty of the exact person in your sentence
Not twenty students in general. Twenty people who match the specific description you wrote. This matters because campus populations are not uniform — a problem that is real for final-year students commuting from off-campus housing may be irrelevant to first-years living in halls. Message coursemates, post in the right group chats, sit in the right part of the cafeteria. The goal for day three is simply securing conversations, not having them yet.
Day four and five: run the conversations, but do not pitch
This is the step most founders get wrong, and it quietly invalidates the entire exercise. The instinct is to describe your app idea and ask "would you use this?" Almost everyone will say yes, out of politeness or genuine but unreliable optimism about their future behaviour. That yes is worthless data.
Instead, ask about the problem, not the solution. How do they currently handle this situation? How often does it come up? What have they already tried? Would they have paid for a fix last week, and if so, roughly how much? Let them describe the pain in their own words before you say anything about what you are building. If they bring up the solution themselves — "I wish there was just an app that did X" — write it down verbatim. That is a far stronger signal than any answer to a leading question.
Advertisement
Build the fake front door
Alongside the conversations, put up a single landing page describing the idea in one paragraph, with one button: join the waitlist, or in some cases, pre-order at a stated price. No app behind it — just a page and a form. This is often called a "fake door" test, and it is the closest thing to real behavioural evidence you can gather in a week, because it costs the visitor something: their email address, and sometimes a small deposit. People who fill in a real form are giving you a different kind of signal than people who answer a hypothetical question kindly.
Share the page only with people outside your immediate friend group — coursemates you do not know well, relevant campus group chats, a flyer near the right building. Friends will click to support you, not because they need the product, and that skews the number in a way that will mislead you later.
Day six: look at the numbers honestly
By day six you should have two data sets: twenty structured conversations and a landing page with some number of signups. Look for two things specifically. First, did a meaningful share of the twenty people describe the same problem in similar language, without being prompted? Second, what percentage of landing page visitors actually signed up? As a rough guide, if fewer than one in ten visitors from a cold audience leaves an email address, the page is either badly written or the problem is not as urgent as you believed — either way, that is worth knowing now rather than after three months of development.
The honest part of this step is resisting the urge to explain away weak numbers. "They just didn't understand the pitch" is sometimes true, but it is also the exact sentence founders use to avoid hearing a no. If the numbers are weak, the more useful response is to revisit the one sentence from day one and ask whether it was actually specific and true, not to assume the market is simply slow to understand you.
Advertisement
Day seven: decide, and mean it
The final day is for making a real decision, not for finding reasons to keep going regardless of what the week showed. There are three honest outcomes. The problem is real and specific and people showed it through action, not just words — build the smallest possible version and go back to the people who signed up. The problem is real but not urgent enough that anyone acted on it — keep the sentence, shelve the build, and look for a sharper angle on the same underlying issue. Or the problem was not what you thought it was — treat the week as a fast, cheap education rather than a wasted one, and apply what you learned about talking to real users to the next idea.
A week spent finding out an idea is not worth building feels like a loss in the moment. It is not. It is six months of unpaid, unwanted development that you did not do. That is the entire point of validating before building: not to guarantee success, but to make sure the months you do spend building are spent on something that already has evidence of demand behind it.