Saurav Jalui – Blog

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 — and 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.