From Problem Discovery to ₹26K+ Revenue

Gradely started from something pretty ordinary: I kept watching classmates hit deadlines with no reliable way to get help, and turning to WhatsApp groups and word-of-mouth instead, which meant a lot of getting scammed, ghosted, or handed low-quality work with no way to push back. Before I wrote a meaningful amount of code, I tested the actual willingness to pay by manually matching people myself, basically acting as the broker by hand. Once that held up, the real product problem revealed itself: it wasn't matching, it was trust. Students needed to know their money and their deadline were both safe, and freelancers needed to know they'd actually get paid for the work they did. Gradely, the platform version, exists to standardize that trust instead of leaving it to chance in a group chat. It's generated Rs. 26,000+ in revenue so far, which I think of as an early signal that people will pay for reliability, not proof that the business model is fully sound yet.

I didn't start with a marketplace idea, I started with a pattern I kept noticing: friends panicking near submission deadlines, asking around for anyone who could help with a project, and getting stuck between two bad options, paying a stranger on Instagram and hoping for the best, or not getting help at all. My first move wasn't to build anything, it was to just manually connect people myself over WhatsApp and see if they'd actually pay for that. They did. That told me the demand was real. What it also told me, once I was in the middle of it, was that the actual hard part wasn't finding people who could do the work, it was making both sides trust that the exchange would go through fairly. That's the moment the idea shifted from "matching service" to "trust infrastructure," which is really what the platform ended up being.

The student freelance market, at least in the informal way it exists on campus, is fragmented and genuinely risky on both sides. A student who needs help is afraid of paying upfront and getting nothing back, or getting something so low-quality it doesn't help them. A student who's good at the work and wants to earn from it doesn't have a steady, trustworthy stream of people to work with, they're stuck constantly hunting for the next gig and then chasing payment afterward. Neither side has a place that solves both problems at once.

There were really three kinds of people showing up around this problem. Students under real deadline pressure, who mostly just want reliable help fast and care less about price than about not failing. Skilled peers who want consistent work and a way to build a track record, not just a one-off gig here and there. And, less centrally but still present, people organizing help for a whole group project, who needed some guarantee of quality before trusting a stranger with a shared grade. Underneath all of that, the core need was something like: when a deadline is closing in and I'm overwhelmed, help me find someone reliable so I can actually finish this without falling apart.

I didn't start by building software, I started by acting as the matchmaker myself, by hand, to see if people would actually pay for a trustworthy version of what they were already doing informally. That worked well enough that I moved to a thin, mostly-manual version of the product, where I was still doing a lot of the matching and quality-checking myself, just with more structure around requests and payment than a WhatsApp thread could offer. Revenue crossing Rs. 26,000+ came out of that process. I want to be honest that I don't have precise numbers on exactly how many conversations, orders, or specific conversion percentages backed that up, if I dig those up from my own records, I'd rather cite the real number than a rounded guess.

I haven't formalized these into a structured research report, but the recurring signal from people on the demand side was fear of getting scammed by a stranger, which told me the platform's real job was to be the trust broker, not just the introduction service. On the supply side, the recurring theme was less about maximizing what they earned per project and more about not having to constantly hunt for the next client, steady work mattered more than squeezing the highest possible price. And the operational lesson for me personally was that manual brokering is a fine way to validate an idea, but it very clearly does not scale, everything that worked because I was personally involved needed to eventually become a real system.

It usually starts with real deadline anxiety, which pushes someone to look for help in the first place. Discovery is messy if there's no central, trustworthy place to look, so a clear, simple way to describe what you need matters a lot here. Once a request comes in, vague requirements cause real problems downstream, so getting the scope right upfront saves everyone pain later. Matching is where trust either gets built or breaks, since this is the moment someone's committing money to a stranger's work. Delivery is where missed expectations show up, and having some kind of checkpoint before the final handoff matters. And when something goes wrong, which it inevitably does sometimes, having a real way to resolve disputes is what keeps one bad experience from turning into a totally lost customer.

Payments held securely until the work is actually approved were the single most important piece, because that's what turns "trust me" into something structural. Curating who's allowed to take on work mattered almost as much, since one bad delivery can undo a lot of earned trust. Forcing some structure into how a request gets scoped upfront turned out to matter more than I expected, vague asks led to vague, disappointing results. And having some kind of dispute resolution path, even a manual one, gave both sides enough confidence to actually transact.

Fiverr and Upwork are built for a much broader, more anonymous freelance market, and they can feel intimidating and expensive for a student who just needs one project done. WhatsApp groups have real liquidity, people are already there, but they offer zero structural trust or recourse if something goes wrong. Formal agencies solve the trust problem but are usually too slow and too expensive for what a student actually needs. Gradely's angle was narrower on purpose, a smaller, higher-trust, more accessible version of the same idea.

I kept the first real version deliberately thin. A structured request form instead of an open text box, because unstructured requests led to people not really knowing what they wanted until it was too late. Manual matching, meaning I was personally curating who got assigned to what, rather than any kind of automated system. Payments held until the student approved the final work. And a very basic rating signal, nothing elaborate, just enough to start building a track record for people doing good work repeatedly.

I chose curated matching over open bidding, which meant slower matches but noticeably better quality control, a trade I made because early trust matters more than early speed. I chose manual payouts over an automated payment integration early on, which meant more manual work for me but let me skip a chunk of upfront engineering complexity I didn't need yet. And I chose standardized pricing tiers over letting freelancers set their own prices, trading some flexibility for supply for a much simpler, less confusing experience for students trying to decide whether to commit.

Project scope varies a lot, so I used complexity-based tiers instead of one flat price, to keep pricing predictable for people making a quick decision under deadline pressure. For genuinely urgent requests, I added a rush premium, partly to compensate the freelancer for dropping other things, and partly because urgency is a real cost that should be priced rather than ignored. And the platform's own cut was set as a standard marketplace-style take rate, though I'd want to actually pressure-test whether that rate holds up as volume grows before treating it as settled.

The metric I care about most is something like weekly completed projects, not just requests or signups, since a completed, accepted project is the only thing that actually proves the trust mechanism worked. Revenue crossing Rs. 26,000+ is the headline number so far. I don't have a reliably tracked refund rate or take-rate-at-scale number yet, and I'd rather say that plainly than attach a specific percentage I can't actually back up if asked.

Early on, letting people describe their project in free text led to a lot of confusion, people often didn't actually know what they needed until partway through, so I moved to more structured, dropdown-style scoping to force clarity upfront. I also initially let the category list get too broad, which spread thin liquidity across too many types of projects, so I narrowed it down to a small number of core categories where I could actually build up trustworthy supply. And early pricing was too opaque, which created hesitation, so I moved to clearer, simpler pricing bands that made the decision easier for someone under time pressure.

The single biggest lesson: the hardest problem in a two-sided marketplace usually isn't the software, it's the operations, matching well, managing expectations on both sides, and building trust one transaction at a time. I chose quality control over speed and automation early on, on purpose, because I think brand and trust are much harder to rebuild than they are to build carefully the first time. What I'd genuinely want to figure out next is whether the pricing model holds up as volume grows, and how much of the trust I've built manually can actually survive the transition to something more automated.