Saurav Jalui – Blog

The Most Ambitious Thing I Haven't Built Yet

Thu, 23 Jul 2026 00:00:00 +0000

Everything our marketing team knows about a prospective student lives in someone’s phone. A parent enquires through the website, someone WhatsApps them, a trial gets scheduled in a message thread, the student either turns up or doesn’t, and somewhere in that chain the only record of what happened is a coordinator’s memory. We know how many leads arrive. We are much fuzzier on where they die.

So I’ve spent the last stretch designing a marketing portal to sit inside the platform we already run: lead capture, pipeline stages, WhatsApp at each stage, tasks, campaigns, reporting. None of it is built. What exists is a clickable prototype and a five-sprint plan, and I’m writing this before a line of production code on purpose. More on why at the end.

Why not just buy a CRM

This was the first question, and it deserved more than the answer I wanted to give.

Plenty of CRMs do pipelines and messaging better than anything I’d build in five sprints. HubSpot, Zoho, and LeadSquared are all more mature than what I’ve drawn, and buying one would have been faster. The honest case for buying is strong, and I want to state it properly rather than knock down a strawman.

The case for building comes down to one thing: a bought CRM doesn’t know our students. It sits outside the platform, so it sees a phone number and a form submission. It cannot tell you that the lead you’re about to send a cold SAT welcome to is already enrolled in your IBDP course, or that their sibling took a trial in March, or that the tutor they’re being pitched is the one who taught them last year. That context is already in our database. Getting it into an external CRM means building and maintaining a sync, and a sync is a thing that breaks quietly.

In the prototype, this shows up as an unglamorous detail: a small STUDENT badge on leads who already exist in the portal. It’s the whole argument in one label. Same student records, same teacher records, same admins, same permissions model, the one we already fought for during the migration off spreadsheets. Nobody needs a second login or a second set of roles.

If that badge turns out not to matter, the build-versus-buy call was wrong. I’d rather write that sentence now than defend it later.

Making “WhatsApp Sent” a stage

The pipeline has six stages: lead captured, WhatsApp sent, trial scheduled, trial taken, feedback collected, enrolled or nurture.

Most CRMs wouldn’t make the second one a stage. Sending a message is an activity, something you log against a lead, not a place the lead sits. Modelling it as a stage is arguably wrong.

I did it anyway, because of what it forces the funnel to measure. If “WhatsApp sent” is just an activity, the funnel tracks how prospects behave. If it’s a stage, the funnel also tracks how fast we respond. A lead sitting in “captured” for two days becomes visibly our failure rather than an unremarkable row in a list. Most of our leakage, I suspect, isn’t people saying no. It’s people not being contacted while they still cared.

Messages are mapped to stages automatically, and branch on exam type: an SAT lead gets a different welcome from an IBDP lead. Eighteen templates covering welcomes, tips, trial invitations, demo confirmations and reminders, post-demo follow-up, enrollment, cross-sell, re-engagement, deadline nudges, new batches, and festival greetings.

The part that nags you

The last internal tool I worked on taught me an expensive lesson: adoption is a trust problem, and a tool that arrives as something done to people gets rejected no matter how fast it is.

So the feature I care most about isn’t the pipeline. It’s the task queue, the tab that tells a coordinator what’s gone wrong: leads with no WhatsApp after 24 hours, demos that finished with no follow-up, anything stale for a week or more. A database waits to be searched. This is supposed to interrupt you.

That’s the difference between a system of record and a system that does work, and it’s the thing I’d protect if scope has to be cut. Alongside it sit two guardrails that exist purely because messaging at volume goes wrong in predictable ways: duplicate detection when logging a call, and a spam-health warning when someone is about to bulk-send to a segment that’s heard from us too recently.

Sequencing is the strategy again

Five sprints: core pipeline, then WhatsApp and bulk send, then trial and enrollment, then tasks and campaigns, then reports and calendar.

The constraint I set was that every sprint has to leave behind something usable on its own. Sprint 1 with nothing after it is still a shared lead list with stages, which beats a phone. Sprint 2 makes the messaging real. Nothing depends on sprint 5 existing.

This isn’t a project-management preference, it’s the same lesson as the spreadsheet migration: what determines whether a rollout works is the order you do it in and how much people can trust each step. If the first thing the team touches is half a product that only makes sense once all five sprints land, I’ve already lost them.

What the prototype gets wrong

There is no consent model in it. Not a weak one. None.

Leads get messaged automatically on stage transition, and there is no opt-in captured, no unsubscribe path, and no record of who asked us to stop. WhatsApp’s own rules require opt-in for template messages, and under the DPDP Act this isn’t a formality. I built an automation engine and forgot to build the brakes, which is a fairly damning thing to notice about your own design, and exactly the kind of omission that’s cheap to fix now and expensive after the first complaint.

It goes into sprint 1. Not sprint 5.

What I think will happen

Here’s the part I’d normally leave out. Predictions, on record, before the build:

The biggest leak is trial scheduled → trial taken. Not enquiry-to-contact, which is where everyone assumes the problem is. People book and then don’t turn up.
The task queue gets used more than the reports. Reporting is what gets asked for in meetings; the overdue list is what people open on a Tuesday morning.
Automated messages will out-perform manual ones on speed and under-perform on replies. Faster, and slightly more ignorable.
The STUDENT badge will matter more than I can currently justify, mostly by preventing embarrassment rather than by creating revenue, which makes it hard to measure and easy to cut.
Something in sprints 4–5 won’t survive contact with the team. I don’t know which. Campaign tracking is my guess.

Why publish this now

Because a plan you wrote down can be wrong in a way you can check, and a plan you kept in your head gets quietly edited to match whatever happened.

Once this ships, I’ll come back and grade every prediction above. That’s the actual point of putting it up before the build: not to look decisive, but to make the follow-up honest. If I’m wrong about most of it, that’s a more useful post than the one where I explain how it all went according to plan.

From Hashnode to Hugo: Notes From the Move

Sun, 19 Jul 2026 00:00:00 +0000

This blog has a new home. It used to live on Hashnode; it now runs on Hugo with the Hextra theme, builds on GitHub Actions, and serves for free from GitHub Pages: same domain, same URLs.

Why move

Hashnode was a great starting point, but in 2026 custom domains moved behind their new Pro plan, and that nudged me toward something I’d been meaning to do anyway: own the whole stack. Now every post is a Markdown file in a Git repo. No platform, no lock-in, no surprises.

The stack

The setup is small enough to describe in one breath: Hugo builds the site, Hextra makes it look good, a GitHub Actions workflow deploys on every push, and four DNS records point the domain at GitHub Pages. Keeping the old URL structure was one config line:

permalinks:
 blog: /:slug/

That single line is what preserves years of links and search rankings across the move.

What broke along the way

Almost nothing, except the time I copied a shortcode block from a rendered Markdown view and it silently injected blockquote markers into the file, breaking the build with the world’s most cryptic error. Lesson learned: always copy from the raw source.

What’s next

Migrating the full archive over from the Hashnode export, rehosting the images, and then getting back to actually writing. If you’re reading this on sauravjalui.com over HTTPS, every piece of the pipeline above did its job.

The Tool Was Faster. They Still Wanted the Spreadsheet Back.

Sat, 18 Jul 2026 00:00:00 +0000

We spent a long time building a scheduling portal to kill the spreadsheets it replaced: thousands of students, hundreds of teachers, a shared pool of video links, all of it held together in Sheets and WhatsApp until the whole thing started tearing at the seams. The portal was, by every measure I cared about, better. Booking a year of recurring classes went from copying a weekly sheet dozens of times to a single click.

And the team still wanted the spreadsheet back.

I sat with that for a while, because it didn’t make sense on paper. The tool was faster. People hated it anyway. That gap, faster and still rejected, turned out to be the whole story, and unlearning my first instinct about it was the most useful thing I did on this project.

It wasn’t the tool

My first instinct, of course, was that we’d built it wrong. More polish, fewer bugs, better UX: the usual reflexes. And there was real breakage to fix, so that wasn’t nothing. But it wasn’t the thing.

The thing was upstream of the code entirely. Features were landing in the portal because management wanted them, not because the people scheduling all day needed them. And they’d show up with no warning, no training, no one asking the team first. So every release, even the good ones, made the tool feel a little more like something being done to them rather than something built for them. The portal wasn’t failing on what it could do. It was failing on trust. And you can’t patch trust with a sprint.

The problem was trust, not speed

That reframe changed what the actual work was. If the problem is speed, you optimize code. Because the problem was trust, the work was about who gets to decide what ships, which is a governance problem wearing a technical costume, and a much less fun one to fix because it means telling powerful people no.

What actually moved the needle

A few decisions did most of the lifting.

The first was just naming who the tool is actually for. Internal tools have a pile of roles (coordinators, managers, teachers, everyone), and when their needs collide, somebody has to win. So I said it plainly: the coordinators living in this thing all day are the primary user. Everyone else is secondary. And management is a stakeholder, not a user: they don’t operate the tool, so their requests don’t get to walk straight into it. Writing that sentence down was uncomfortable and clarifying in equal measure.

From there came the rule I’m proudest of: requests from the people who use the tool are needs; requests from management are good-to-haves. A good-to-have only ships after the people it affects sign off, and only when nothing they actually need is still waiting. It’s a small rule that deliberately makes someone senior wait their turn, which is exactly the point, and exactly why it was hard to hold.

The last piece was figuring out how we’d even know if it worked, and this is where I almost fooled myself. Usage was mandatory, so every usage metric was a lie: logins looked great because nobody had a choice. What I actually needed to measure was whether people would leave if they could. So: an anonymous monthly pulse, anonymous being non-negotiable, because a team that’s nervous will tell a survey with their name on it whatever they think management wants to hear. And alongside it, just watching people work, because you can’t intimidate someone’s behavior into politeness the way you can a feedback form.

The sentence I didn’t want to write

The part I’m most sure about is the part that was hardest to write: the line where I said, out loud, that if we stabilized and polished the thing and people still wanted the spreadsheet, then scheduling should go back to the spreadsheet, and the portal should keep only what a spreadsheet genuinely can’t do. That’s a deeply uncomfortable sentence to put in a memo about a tool you helped build. It’s also the only thing that made the rest of the plan believable, because it proved I was trying to fix the problem and not defend the tool.

What I’d carry into the next one

If there’s one thing I took from this that outlives this one project, it’s that adoption is a trust problem far more often than a capability problem. When you force people to use something, you lose the only honest signal you had. You stop being able to tell whether they’re using it because it’s good or because they can’t escape. And at that point the most valuable thing you can build isn’t another feature. It’s a way to find out whether they’d stay if you opened the door.

Getting a Company Off Excel Without a Revolt

Sun, 12 Jul 2026 00:00:00 +0000

Case Study · Migration

For years, the entire operation ran on spreadsheets. Scheduling, teacher availability, who owed how many hours: all of it lived in a sprawl of Sheets, held together by a handful of people who just knew how it worked. It had run the business for half a decade, and to its credit, it mostly worked.

Until it didn’t, on every axis at once. A typo in the wrong cell quietly broke someone’s schedule. Anyone with the link could edit anything, so there was no real notion of permissions. Nothing was logged, so when something went wrong there was no way to reconstruct what happened or who’d done it. And none of it scaled: every new teacher, every new cohort made the sheets heavier and the humans holding them more overloaded. The sheet wasn’t one problem. It was four, and they were compounding.

The easy version of this project would have failed

The tempting way to do this is a big-bang cutover: build the whole portal, pick a Monday, turn off the sheets, send an email. It’s clean on a Gantt chart and it’s a disaster in practice, because it asks an entire organization to abandon five years of muscle memory overnight and trust software they’ve used for a week. The day something breaks (and something always breaks), everyone’s instinct is to reach back for the spreadsheet they know, and now you’re running both, badly, with no plan for it.

So I didn’t do that. The migration went team by team, deliberately, and the sequencing was itself a design decision.

Starting where it would break

I didn’t start with the easiest team. I started with one of the harder ones, the group whose workflows were the least standardized and most likely to surface the ugly edge cases. The logic: if the portal could survive the messy team, the tidy teams would be easy. And if it couldn’t, I wanted to find that out early and cheaply, with one group, instead of discovering it mid-rollout with everyone watching.

That group knew they were the stress test, and I told them so plainly. Being the guinea pig is more palatable when it’s framed as your feedback shapes what everyone else gets rather than you’re the ones we’re experimenting on. The distinction is entirely in the framing, and it matters more than it should.

Running two systems on purpose

For each team, the sheet didn’t die the day the portal arrived. They ran in parallel for a stretch: portal for real work, sheet as the safety net nobody was forced to let go of yet. This is inefficient and I did it anyway, because the alternative, demanding a leap of faith, is how you turn nervous users into hostile ones.

What actually retires a spreadsheet isn’t a mandate. It’s the moment someone realizes they haven’t opened it in two weeks and don’t miss it. You can’t order that feeling into existence; you can only make the portal good enough that it happens on its own, and give people the safety net until it does. Once a team stopped reaching for the sheet, then it went away, team by team, on their timeline, not mine.

The hard part was never the software

I could have gotten the permissions model, the approval chains, and the timezone-aware scheduling technically right and still failed completely, because none of that was the actual obstacle. The obstacle was that I was asking people to give up the thing they trusted for the thing they didn’t, and no feature list wins that argument. Trust does.

Building the trust looked like small, unglamorous things. Migrating a team’s real data in clean so their first impression of the portal wasn’t a mess they had to fix. Making the single most common task genuinely faster than the sheet had been, before touching anything fancy. Sitting with people while they used it instead of reading their complaints in a form. Letting the pilot team’s frustrations visibly change the product, so the next team could see that feedback here actually went somewhere. None of that shows up on a roadmap. All of it was the real work.

What I’d carry into the next one

The lesson that outlives this project: a migration is a trust exercise disguised as a technical one, and the sequencing is the strategy. Who goes first, how long the old thing survives alongside the new, whether people feel like participants or test subjects: those decisions determined whether this worked far more than any feature did. Excel is gone across the org now, but not because we switched it off. It’s gone because, one team at a time, people stopped reaching for it.