Ham-Masir

Every year roughly one and a half million Iranian students sit the konkur, a single national exam that decides which university and which field they get into and, in practice, shapes a large part of their working life. For most people it's the highest stakes year of their education.

A whole industry has grown up around that one year. Its central figure is the moshaver, a paid academic consultant who plans the student's week, checks their progress and keeps following up. Consultants are expensive, they're usually booked through institutes that take a sizeable cut, and the student almost never gets to choose their own.

I started this project assuming the problem was price. It wasn't.

My role: everything. From research and positioning to brand and product design and the front end build. There was no team, no client and no brief. I took the whole project from zero to launch myself; the code was written with the help of vibe coding tools. So if any decision you read below was wrong, that's on me.

To start, I talked with seven students from grades 10 to 12 over Instagram DMs, and alongside that I had a few informal conversations with parents.

I did the interviews in writing, not over the phone. In my experience teenagers here reply to DMs much more easily, while they might not pick up a call. Writing also gave them time to think before answering and to say what they actually meant.

I was honest about who I was, too: someone building something and trying to find out whether there was a problem worth solving; not a researcher running a formal study.

The tension from finding #1 has no clean answer: persistence produces results, persistence is what students hate. Both are true and you cannot design one away.

The option I rejected first was the obvious one, daily check-in notifications from the mentor. It would have been simple to build and it would have reproduced the exact behavior students described hating, only from a person they'd chosen instead of one assigned to them. Choosing your own source of nagging doesn't make it less nagging; it just means you blame yourself for it.

What I did instead: I split persistence from the relationship.

The routine daily follow-up is carried entirely by the product; did you do today's list, are you behind, how much of this chapter is left. A calendar, a progress ring, a tick-able daily checklist. Software can ask the same question every single day without it costing anything socially, because software has no feelings to disappoint.

The mentor is pinged only when the student actually falls behind. So contact from a real human always carries information. It means something happened, not it's Tuesday.

Messaging between the two is bounded to an evening window and is asynchronous; the mentor answers within the window, not instantly, not at midnight. Weekly calls, four a month, are the synchronous contact.

The offering ladder originally had three rungs: a single one-hour session, a monthly support subscription, and specialized consulting, meaning real study planning, subject teaching, strategy. The third was the most defensible commercially. It also had the highest price, and it was what the market already pays for.

I removed it.

A second-year engineering student can honestly tell you how they got through a specific chapter and what they'd skip if they had the year again. They cannot professionally plan another person's entire exam year, and if the platform sold that, it would be selling something its mentors aren't qualified to deliver. Worse: it would have quietly turned Ham-Masir into the thing it was built to route around. Same service, same claim of expertise, younger staff.

The subscription that remains keeps planning, but reframed and bounded: the mentor drafts a weekly plan during the call from lived experience, then finalizes it with the student, who owns it and executes it. It's a day by day list, like Saturday: physics ch.3 reading + 30 practice questions, that flows straight into the student's daily checklist. That's a peer sharing a route they've walked. It is not consulting, and the product is careful never to describe it as consulting.

The cost of this decision is real: it caps revenue per user and rules out the highest-margin product. I took the cap because a peer-mentorship platform that also sells expertise isn't a peer-mentorship platform.

The discovery screen has an obvious best practice: put everything on the card. Bio excerpt, price, rating, university, response time; let people scan and compare without a tap. It's faster, and it's what every marketplace does.

I built that first. It made the mentors look like products.

Reduced to a comparable row of attributes, a mentor becomes a slightly worse or slightly cheaper version of the mentor beside them, and the student optimizes, which is exactly the wrong mental model for a relationship they'll be inside for months. The thing being chosen isn't a service tier. It's a person whose path they want to follow.

What the card shows now: only what's needed to establish trust and eligibility; who they are, where they study, which track, their rating. Nothing to comparison-shop on. No booking button.

The entire card is tappable and opens the mentor's full profile, where the narrative lives: their story, in their words, and reviews from students they've worked with. Booking happens there, after reading, not from a grid.

I iterated once more here. An earlier version opened a booking bottom sheet on tap, quicker to book, fewer steps, better on paper. It let students commit before reading anything. I removed it and sent taps to the full profile page instead, accepting the extra step. Friction placed deliberately in front of a decision that shouldn't be fast.

I designed the interface and built the front end myself: one Next.js codebase, TypeScript, Tailwind, mobile-first and right-to-left, with role-based routes for student and mentor rather than separate applications. Every color, radius, and type step comes from a central token file, with nothing hard-coded, because the brand was still moving while the screens were being built.

The build surfaced a design problem that no amount of Figma would have: each screen had been built against its own mock data, so a booking made for one mentor displayed a different mentor's name under my sessions. The screens were individually correct and collectively lying. Fixing it meant a single source of truth for mentors referenced by ID, and a persisted shared bookings store. It's the clearest reminder I've had that a screen is not a design; the state behind it is.

Twelve mentors are recruited and verified, covering all three subject tracks, with women and men in each, because the platform pairs students with mentors of the same gender, a requirement of the context this product ships into, not a preference.

The mark is two parallel curved lines rising together and never merging, holding a constant gap between them. Teal for the one who has walked the path, peach for the one walking it now. The gap is the point: the mentor accompanies, they don't absorb.

Everything downstream follows from a single refusal; this brand has no finish lines, no trophies, no leaderboards, no races. The konkur is already the most competitive year of a student's life. A product built around that year has no business adding to it.