Every product inside Unihub Network moves through the same three stages. We wrote them down early, mostly so that we could not quietly drop one when a deadline got close.
01 · Listen
Nothing gets designed until we can state the student's problem in one sentence.
That sounds like a formality. It is not — it is the stage that kills the most ideas, and it should. Interviews, application walkthroughs, and the questions people are already asking in forums and group chats all go in. What comes out is a written problem statement, not a feature list.
The difference matters. "Students want a document checklist" is a feature. "Students cannot tell which of their documents will be rejected until after they have paid the application fee" is a problem — and it admits several solutions, most of which are better than a checklist.
If we cannot write the sentence, we do not have the problem yet, and we go back.
02 · Build
Small teams, real data from day one, shipped in weeks rather than quarters.
The rule that does the work here is the second one. We prototype against the actual catalogue and the actual paperwork, never against invented sample data. Sample data makes everything look fine — every name is a sensible length, every requirement fits the layout, every edge case is absent.
Real data does the opposite, immediately and usefully. It surfaces the program title that is ninety characters long, the tuition quoted per credit, the requirement that depends on the applicant's passport. Those are the cases that decide whether the product is any good, and finding them in week one is much cheaper than finding them after launch.
03 · Scale
Only once a product has earned its keep with real students do we widen it — more destinations, more languages, more of the journey covered.
"Earned its keep" is doing real work in that sentence. It does not mean sign-ups. It means students getting to a decision they could not have reached on their own, which is harder to measure and much more worth measuring.
The other half of this stage is folding what we learned back into the network. The matching work from Gradsy informs how Unihub Community organises its rooms. The catalogue underneath both is the same catalogue. Each product should make the next one cheaper to build.
The stage everyone wants to skip
It is the first one, always. Listening is slow, it produces no demo, and there is a constant pull toward the part where something appears on a screen.
But every expensive mistake we have watched other teams make traces back to a problem statement that was never written down — a product built for a student who was assumed rather than asked.
So a product does not get a launch date until it has earned one. That is not caution. It is the shortest path we have found to something students actually use.