Coder Legion - Recent posts tagged founder

The 3 a.m. call: why every founder needs an Arun

Fri, 30 Oct 2026 12:30:00 +0000

When I'm stuck badly enough, I call Arun.
He's our CTO.
He's the one person I trust to pick up at any hour.

In the night I broke production, he got a short section.
Four lines and a photo.
This is the longer version, because I think the idea deserves more than four lines.

The idea is simple.
Every founder needs one person who picks up.
Not a mentor you email on Mondays.
Not a group chat.
One person, at any hour, who will actually answer.

The one person who picks up

Arun picks up at any hour.
Which, if you think about it, is frankly suspicious.
Does he sleep? Is he three people?
I've decided not to ask, in case the answer ruins it.

If you want to know who he is, his portfolio does a better job than I would.

What I think a person like that gives a founder is a floor.
"Stuck" stops meaning "stuck forever".
The bad nights still happen.
They just have a bottom.

TrackMy Tech is bootstrapped.
There's no board of investors waiting by the phone.
There's Arichandran, our co-founder and director, there's Arun, and there's the rest of us.
When something breaks, the people in the room are the plan.

Why going it alone is harder than it looks

I'm not the first person to notice this.
Paul Graham put "single founder" near the top of his essay The 18 Mistakes That Kill Startups.
His reasoning is blunt.
"Starting a startup is too hard for one person."
Even if you could do all the work yourself, he says, you need colleagues "to brainstorm with, to talk you out of stupid decisions, and to cheer you up when things go wrong."

That last part is the 3 a.m. call in one sentence.

He also writes that "the low points in a startup are so low that few could bear them alone."
I've had a few low points.
I can confirm they are, in fact, low.

The catch: the people can also sink you

Here's the uncomfortable flip side.
The people around you aren't only your safety net.
They can also be the thing that breaks.

Noam Wasserman, who wrote The Founder's Dilemmas, has studied this for years.
The Harvard Crimson reported that his research drew on data from "nearly 10,000 founders of technology and life sciences startups in the U.S."
His main finding, as the Crimson summed it up: "Startup companies are most likely to fail due to personal disagreements within their management teams."

Not the market. Not the tech.
The people.

The same article notes that 73 percent of founders in his survey decided how to split equity in the first month.
An equal split avoids tension early on, but can cause problems if a co-founder backs out later.
In other words: the hard conversations don't go away if you skip them.
They just wait for a worse moment.

So I don't think the lesson is "have a co-founder, done".
I think it's "have someone you trust, and do the work to keep that trust".

Trust is what makes the call possible

There's a reason the 3 a.m. call works with one person and not with others.
You have to be willing to say "I've messed this up and I don't know why" out loud.

Amy Edmondson has a name for the condition that makes that possible.
In her 1999 paper she describes team psychological safety as "a shared belief held by members of a team that the team is safe for interpersonal risk taking."
She studied 51 work teams in a manufacturing company.
Teams with more psychological safety showed more learning behaviour, and that learning behaviour was linked to better team performance.

Her examples of learning behaviour are worth reading slowly: seeking feedback, sharing information, asking for help, talking about errors and experimenting.

"Asking for help" and "talking about errors" are basically the job description of a 3 a.m. call.
If you're scared of looking stupid, you don't call.
You sit there alone for hours, checking the same code again.

Photo: Pathum Danthanarayana on Unsplash

What I'd tell another founder

None of this is a grand theory.
It's my opinion, from someone who makes that call when he's stuck badly enough.

Decide who you'll call before the crisis. Not during it. In the middle of an outage you won't think clearly enough to pick. Know the name now.
Make it mutual. If you only ever call, it's not trust, it's a helpline. Pick up for them too. Be the person who answers.
Say the embarrassing thing early. The call only helps if you're honest about how badly it's gone. Edmondson's research is basically a long argument for this.
Have the awkward talks on a calm day. Equity, roles, who decides what. Wasserman's findings suggest the skipped conversations are the ones that come back.
Write things down so the call is rarer. Passwords in the right place, deployment steps, when certificates expire, how to roll back. If the answer lives in one person's head, that person gets woken up a lot.

That last one matters more than it sounds.
The goal isn't to call Arun more.
The goal is to call him only when it really can't wait.
He picks up at any hour. That doesn't mean he should have to.

One last thing

Find your Arun.
Then try very hard to need him less.

And if you already have one, maybe send them a thank-you message.
During the day, for once.

FAQ

Do you need a co-founder to start a startup?

Not strictly. But Paul Graham lists "single founder" as one of the mistakes that kill startups, mainly because the low points are hard to carry alone. At the very least, have one person you can call.

What is psychological safety in a team?

Amy Edmondson defines it as a shared belief that the team is safe for interpersonal risk taking. In practice: you can admit a mistake or ask for help without being punished for it.

How do you make late-night emergencies rarer?

Write things down. Deployment steps, credentials, renewal dates and rollback commands should live somewhere the whole team can find them, not in one person's head.

Sources

What next

The outage night, in full: we blamed our code, it was SSL.
Another late-night call, from the other side: I said I would help a friend.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages.
It's built by TrackMy Tech.

Shipping Android and iOS solo (iOS: coming soon)

Fri, 30 Oct 2026 08:30:00 +0000

I built the Track My Academy mobile apps myself.
Both of them. Android and iOS.

The Android app is live in production.
The iOS app is coming soon.

That second line is the honest one.
It's also the one every solo founder ends up writing at some point.

So this post isn't a victory lap.
It's a look at what actually stands between one person and two app stores.
Fees, rules, testers, reviewers.
And why, for a product like ours, I think Android first is the sensible order.

Photo: Denny Müller on Unsplash

Building it is the part you expect

Track My Academy started as a web app, and the web app is live.
Real academies run on it.
The first version came together with AI tools, mostly vibe coding, in about three months.
That story, and the agency build that came before it, is in the app that arrived from 2006.

The stack behind it is React, FastAPI, MongoDB, Supabase, Firebase and a few friends.

Here's the thing nobody tells you when you're writing code at night.
Writing the app is the part you can control.
Getting it into a store is a different job, with somebody else's rules.

The two doors: Play Console and App Store Connect

Each platform has one front door.
On Android it's the Play Console.
On iOS it's App Store Connect, which needs a paid Apple Developer Program membership.

The price of entry is the first difference.

	Google Play	Apple App Store
Account cost	US$25, one time	$99 a year
Identity checks	Government ID and a card in your legal name may be asked for	Legal name for individuals; a D-U-N-S Number for organisations
Beta testing	Closed testing tracks	TestFlight, up to 10,000 external testers

For a bootstrapped team, one fee is a rounding error and the other is a yearly subscription.
Neither is the real obstacle.
But it does tell you something about how each store thinks.

Apple's organisation route has its own homework.
Apple's enrolment page says an organisation must be a legal entity that can sign contracts, needs a D-U-N-S Number, and needs a public, working website on its own domain.
The organisation's name then shows as the seller name on the App Store.
None of that is hard.
All of it takes time you didn't plan for.

Google's 12 testers and 14 days

Android is not a free pass either.

If you open a personal Play developer account today, you can't just upload and publish.
Google's rules for personal accounts created after 13 November 2023 say at least 12 testers must be opted in to a closed test when you apply for production access.
And they must have stayed opted in for the preceding 14 days, continuously.

For a big company, 12 testers is a Slack message.
For a solo developer, it's a favour you ask of friends, family and anyone who owes you one.
Then you wait two weeks and hope nobody uninstalls.

My opinion: it's annoying, and it's also fair.
Two weeks with real people on real phones finds bugs you won't find alone.

Apple's reviewers read the guidelines so you have to

On iOS the gate is a human review.
Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours.
That's quick.
Passing is the slower bit.

The same page says that, on average, over 40% of unresolved issues relate to guideline 2.1, App Completeness.
The App Store Review Guidelines put it plainly: submissions "should be final versions with all necessary metadata and fully functional URLs included".
Placeholder text and temporary content have to go.

There's also a line I like for its honesty.
If your app has a login, include demo account details "(and turn on your back-end service!)".
Someone clearly learned that the hard way.

A product like ours is almost entirely behind a login.
It's role-based, so different people see different things.
So a reviewer needs a working account and enough data to see the app do its job.

Then there's guideline 4.2, Minimum Functionality.
Your app "should include features, content, and UI that elevate it beyond a repackaged website."
If you already have a good web app, this is the trap.
Wrapping it and shipping it is the fastest route, and the one most likely to bounce.

Apple's list of common problems also includes broken links, a missing privacy policy, inaccurate screenshots and unclear data-access prompts.
Boring things.
The boring things are always the ones that get you.

Why Android first, for us

Here's where I'll be opinionated.

In India, Android isn't the bigger platform.
It's nearly the only one.
StatCounter's figures for September 2026 put Android at 93.89% of mobile OS share in India and iOS at 6.05%.

Track My Academy is for sports academies.
Attendance, fees, player reports, messages to parents.
The coach who started all this ran everything from his phone.
His story is in how a coach's complaint turned into a company.

If you're building for that person in India, the odds say their phone runs Android.
So for an Indian sports-academy product, I think Android first is simply the order the market hands you.
Add a one-time fee and a review flow you can test yourself, and the choice makes itself.

That doesn't make iOS optional.
Some parents and owners will be on iPhones.
And the web app covers anyone in between while the iOS app is still on its way.

What I'd tell another solo dev

Budget for the store, not just the code. Fees, verification, screenshots, privacy policy, demo accounts.
Line up your testers early. On Play, 14 days only starts once they're in.
Read guidelines 2.1 and 4.2 before you build, not after. It's cheaper to design for them.
Ship where your users are first. For us, that's Android.
Say "coming soon" out loud. It's fine. It beats pretending.

The iOS app is coming soon.
When it's out, you'll hear about it here.
Probably with too many exclamation marks.

FAQ

Is the Track My Academy iOS app out?

Not yet. The Android app and the web app are live. The iOS app is coming soon.

Do new Google Play developers need testers before going live?

Personal accounts created after 13 November 2023 need at least 12 testers opted in to a closed test for 14 days in a row before applying for production access.

How much does it cost to publish on both stores?

Google Play charges a US$25 one-time fee. The Apple Developer Program costs $99 a year.

Sources

What next

How the product got built in the first place: the app that arrived from 2006.
And what happens after you ship: we blamed our code, it was SSL.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages.

Switching from biology to computer science, with zero plan

Fri, 30 Oct 2026 04:30:00 +0000

In class 12, I was a bio-maths student.
Biology and maths. The combination that says, "I haven't decided yet."

Then I ended up switching from biology to computer science.
No plan, no grand vision, no robot built from spare parts at age nine.

This post is the honest version of that switch.
It's also for anyone choosing a stream after class 12.
Or anyone eyeing a career change into tech from somewhere else entirely.

Choosing a stream after class 12 (badly, in my case)

Bio-maths is the stream you pick to keep every door open.
Doctor? Possible. Engineer? Also possible.
Decision? Postponed, indefinitely.

Let me be very honest here.
I didn't pick biology out of passion.
It was mostly peer pressure, plus a very silly reason at the time.

My class 12 marks weren't great either.
Nobody was framing that mark sheet.

Until class 12, I had zero interest in computer science.
None.
Then I slowly realised I wasn't built for biology.
So I quietly switched to computer science.

No dramatic movie moment.
Hollywood will not be calling.

Today I'm doing a B.Tech in Artificial Intelligence and Data Science.
Which sounds very impressive on paper.

On paper, I also look like someone who sleeps eight hours.

Would I do it again?
Yes. Instantly.
Best decision I have ever taken, I guess.

The "I guess" is doing a lot of heavy lifting there.

Photo: Pawel Czerwinski on Unsplash

What biology and maths quietly taught me about code

People assume switching from biology to computer science wastes the first part.
I don't think it does.

Biology teaches you that systems are messy.
Nothing works the way the diagram says it does.
Everything depends on something else you forgot about.

Which, it turns out, is also a perfect description of software.

Maths taught me that being wrong is normal.
You just keep going until the answer stops being wrong.

Debugging is the same thing, but with more caffeine.

There's even a whole field where the two subjects meet.
Computational biology studies living systems using computer science, data analysis and simulation.
Its cousin, bioinformatics, builds software tools for huge biological datasets.

So no, the biology years were not a detour.
They were a weird, scenic shortcut.

Photo: Bozhin Karaivanov on Unsplash

Can a bio-maths student do B.Tech in computer science?

Short answer: usually, yes.
Long answer: check the fine print, because India loves fine print.

Bio-maths students normally study physics and chemistry too.
With maths, that's the classic engineering set, so most doors stay open.

In 2021, AICTE also relaxed its B.Tech eligibility rules.
Its handbook listed biology among 14 subjects that could count.
But the change was optional.
States, universities and JEE Main could still insist on physics and maths.

So here's my advice, and it's boring on purpose.
Read the admission brochure of the exact college you want.
Then read it again, slowly, like it owes you money.

What B.Tech AI and Data Science actually is

My degree is a B.Tech in AI and Data Science.
It's computer science with extra statistics, extra maths and extra hype.

Data science mixes statistics, scientific computing, algorithms and coding.
The goal is to pull useful knowledge out of messy data.
It also leans on domain knowledge from whatever field the data comes from.

That last bit matters if you're coming from a non-CS background.
Your biology, commerce or arts brain is not a handicap.
It's the domain knowledge.

Data without context is just a very large spreadsheet.

Should everyone pick AI and Data Science? No.
If you like building things, any CS-flavoured branch will do.
The branch name matters far less than what you build during it.

Photo: Vitaly Gariev on Unsplash

Learning to code from a non-CS background

Here's the part nobody tells you.

My first month of college was rough.
I was the non-CS kid in a room full of CS kids.
I felt properly inferior.

So I did something slightly unhinged.
I learned at extremely high intensity, every single day.
By the end of that month, I'd learned more than 12 programming languages.
More than the rest of the class had covered by then.

And the learning never really stopped.
Once I started building software as a business, I had to learn everything it needed.

Nobody taught me to code.
I taught myself.
My biggest teacher was freeCodeCamp.

It's a non-profit with free, interactive coding courses and projects.
I'm genuinely grateful for it.
Without freeCodeCamp, I honestly might not be where I am.
It kept me motivated, and it pushed my limits.

I learn by touching the thing until it makes sense.
I do it badly first.
Then slightly less badly.
Then, eventually, well enough to ship.

That approach is basically my whole career.

We once hired someone to build Track My Academy.
What came back was PHP, and it looked like 2006.
So I decided to build it myself.

The first night was a MacBook Air, a second-hand iPhone, ChatGPT and VS Code.
Mostly research, then a landing page I actually liked.

Later, I built the Android and iOS apps myself.
Android is live in production. iOS is coming soon.
No certificate. Just apps, and a lot of Monster cans.

If you're starting from zero, here's what I'd actually do:

Take one free foundation course. freeCodeCamp is what I used. CS50 is excellent too.
Pick one language and stay there. Python is a friendly first choice.
Skip the official Python tutorial at first. It says itself it's not for total beginners.
Build something you'd actually use. A tracker, a bot, a page for your football team.
Break it, fix it, repeat. That's the whole syllabus.

The CS50 page says two thirds of its students have never taken CS before.
So you'd be in very large, very confused company.

And yes, use AI tools.
Early on, we hunted down every free AI trial we could find.
Less elegant than it sounds. It worked.

Just understand the code before you ship it.
Production will teach you otherwise.
Ask me about the night I broke it.

Photo: Vishnu Kalanad on Unsplash

Biology found me again anyway

Here's the plot twist.

I left biology for computer science.
Then biology walked back in through the side door.

I'm now AI and Product Development Lead at BioPipeline.
It's a SaaS for plant molecular docking.
We built it from scratch with the founding team.
Compound uploads, docking runs, molecular interaction outputs, results.

It started because I said I would help a friend.

So the bio-maths kid ended up writing software for biologists.
The universe has a sense of humour.
Mostly at my expense.

Nothing went the way I expected

From the moment I switched, nothing followed a script.

I coached football part-time at an academy.
A coach's complaint about attendance and payments became an idea.
That idea became Track My Academy.
Then it became a company, TrackMy Tech.
I'm now its Executive Director, while still technically a student.

My mother still asks whether I went to class.
Fair question. Student founder life is like that.

None of this was in any plan.
I'd love to tell you I saw it coming.
I absolutely did not.

If you're choosing a stream after class 12 right now

You might be stuck between two streams.
Everyone has an opinion about what you should do.

Here's mine, and it's free.

The subject you pick at seventeen isn't a life sentence.
It's a starting point.

Pick something. Work hard at it.
If it doesn't fit, switch.

Coming from biology into CS? One suggestion.
Don't panic about being behind.
CS students mostly cover basics in classes 11 and 12.
Some Python, some general IT.
You can catch up on that whole syllabus in a month or two.
The CS kids aren't wizards. They just started earlier.

One more thing.
Be careful with "opportunities" that cost money.
I once paid for an internship.
Still annoyed about it.

Nobody checks your class 12 stream when your product works.

FAQ

Is switching from biology to computer science hard?

Harder at the start, honestly.
The first few months feel like learning a new language. Because they are.
After that, it's mostly practice and stubbornness.
Biology students already memorise ridiculous names. Variable names are easier.

Can I do B.Tech AI and Data Science after bio-maths?

Usually, yes, since bio-maths includes physics and maths.
AICTE allows more combinations now, but colleges and states decide.
Check the brochure of your exact college.

Do I need a CS background to learn coding?

No.
CS50 says most of its students start without one.
You need curiosity, a laptop and a high tolerance for being wrong.

Making the switch yourself?

If you want an honest second opinion, book a call with me.
Or see what I'm building at rahuldk.in.

And if you end up in computer science by accident?

Welcome. We have snacks.
Actually, we have Monster cans. Close enough.

I built a pager for my own developers

Thu, 29 Oct 2026 08:30:00 +0000

An earlier post ended with a promise.
Sort of.

In the night I broke production, an expired SSL certificate on our backend domain failed silently.
It took us about four hours to find it.
I stayed in the office all night.

At the end I mentioned, almost in passing, that I later built a "Pager System" for Track My Academy developers.
An internal, real-time error and notification system.
The idea: problems should find developers, not wait to be found.

This post is about that idea.
Why a tiny team needs a pager at all.
And what I think a good one should and shouldn't do.

A very old idea

Pagers were not invented for developers.
They were invented for doctors.

According to Wikipedia's history of the pager, Al Gross patented the first telephone pager system in 1949, intended for physicians.
The physicians, apparently, did not love the idea of being permanently on call.
I relate.

A year later, a paging service for doctors launched around New York City.
Doctors paid US$12 a month for a pager that worked within about 40 km of one transmitter.

And pagers never quite died.
Wikipedia notes that in 2017 the UK's NHS was thought to use over 10% of the world's remaining pagers.
Volunteer firefighters and rural first responders still carry them.

The point of a pager has never changed.
Something important is happening.
The right person needs to know.
Now, not when they next check.

Photo: Winston Chen on Unsplash

Why a small team needs one

Big companies have on-call rotations, incident commanders and very serious dashboards.
Small teams have a group chat and hope.

Hope is not a monitoring strategy.
I found that out the hard way, overnight.

Track My Academy runs on React, FastAPI, MongoDB, Supabase, AWS EC2, Vercel, Razorpay, Firebase and Redis.
That's a lot of moving parts for a small team.
Any one of them can have a bad day.
And real academies run on it, so their bad day becomes our bad day.

The awkward truth is that a small team can't afford to watch everything.
Nobody is sitting in front of a dashboard all day.
We're shipping features, fixing bugs and, in my case, occasionally attending class.

So the system has to do the watching.
And when something breaks, it has to come and find a human.

The rules I'd steal from Google

Google's SRE book has a chapter on monitoring distributed systems.
I keep going back to it.

Three lines from it should be on every developer's wall:

"Every page should be actionable."
"Every page response should require intelligence."
"Pages should be about a novel problem or an event that hasn't been seen before."

If a human gets woken up and the fix is a script, automate the script.
If the alert is something they'll ignore, delete the alert.

The same chapter splits monitoring into two questions: "what's broken, and why?"
What's broken is the symptom.
Why is the cause.

That distinction would have saved us hours.
We had a symptom: everything was down.
We jumped straight to a cause we'd picked ourselves: our new code.
The real cause was a certificate nobody was watching.

It also lists four golden signals: latency, traffic, errors and saturation.
If you can only measure four things, the book says, measure those.

There's a catch with alerting.
Too much of it is almost as bad as none.

The SRE book says that "when pages occur too frequently, employees second-guess, skim, or even ignore incoming alerts".
And one line I really like: "I can only react with a sense of urgency a few times a day before I become fatigued."

Hospitals know this problem well.
The US agency AHRQ has a primer on alert fatigue.
It describes one study where ICU monitors generated "more than 2 million alerts in one month", or "187 warnings per patient per day".
It also says clinicians "override the vast majority" of computerised ordering warnings.

Doctors are not careless.
They're human, and humans tune out noise.
Developers are the same, only with worse posture.

This is opinion, not a spec.
But if you're a small team building your own, here's what I'd aim for.

Page on symptoms users feel. Errors, slow responses, failed payments. Not every log line.
Say what's broken in one sentence. The person reading it may have just woken up.
Go to the right person. Not the whole team. One owner per alert.
Stay quiet when things are fine. Every alert that isn't urgent teaches people to ignore the urgent ones.
Watch the boring stuff. Certificates, domains, disk space, expiring keys.
Get pruned regularly. If an alert fired and nobody acted, change it or remove it.

You don't have to build it from scratch either.
Tools like Sentry let you send notifications or create tickets when issues match rules you set.
Its docs say the goal is alerts that are "valuable and not too noisy".
They suggest using filters so you only hear about issues your team needs to know about.

About those certificates

The boring stuff deserves its own section, because it got us.

Certificates are about to expire a lot more often.
In 2025 the CA/Browser Forum passed a ballot to cut the maximum TLS certificate lifetime from 398 days to 47 days.
The reductions start in March 2026 and finish in March 2029.

Meanwhile, Let's Encrypt stopped sending expiry reminder emails on 4 June 2025.
Its reasons included that more people now have reliable renewal automation.
It pointed people to third-party monitoring instead.

So: shorter lifetimes, fewer reminders.
If your renewal automation ever quietly fails, nobody is going to email you about it.
Your users will tell you instead.

Automate renewals.
Then monitor the automation anyway.

The point

A pager isn't about being available all the time.
Honestly, I'd like to sleep more, not less.

It's about not spending four hours blaming the wrong thing.
The problem should arrive with a name attached.
Then the human can do the part that needs a human.

FAQ

Does a small team really need alerting?

I think so. Small teams have fewer people watching, so the system has to do the watching for them.

What should trigger a page?

Something urgent, actionable and user-facing. If nobody needs to act right now, it's a ticket or a report, not a page.

How do I avoid alert fatigue?

Fewer, better alerts. Review the ones that fired, and delete or fix any that nobody acted on.

Sources

What next

The full outage story is in the night I broke production.
For where the late nights happen, see three monitors, one Monster can.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages.

From hackathon loser to hackathon jury: the loop is complete

Thu, 29 Oct 2026 04:30:00 +0000

Cover photo: Mirea Mazzei on Unsplash

On 8 and 9 October, I was on a hackathon jury.

Me.
The guy who used to be on the other side, sweating.

The hackathon was at VISTAS.
It was run by the Department of Computing Sciences and the Vels Innovation Council.
More than 80 teams took part.
Over the two days, I evaluated somewhere between 20 and 30 of them.

Somewhere in the middle of all that, I realised something.
I've now sat in every seat a hackathon has.

Every seat at the hackathon table

Let me count them.

Participant.
A hackathon is meant to be rapid, collaborative building over a short stretch.
Rapid, yes.
Collaborative, mostly.
Calm, never.
I've been the nervous one pitching at the end of it.

Loser.
I've lost hackathons.
It stings.
Then, annoyingly, it teaches you something.

Winner.
I've also won a couple.
Master of Purple Fabric AI at the Intellect Design Arena hackathon.
First place at HackAtom, the Russian Embassy hackathon.
Both in 2026, both still slightly surprising.
They live on my about page, where I can look at them.

Organiser.
I organised Smart India Hackathon at my college.
It's the biggest hackathon we run.
Smart India Hackathon is a national event built around real-world problems.
Organising one teaches you how much invisible work goes into two days of "fun".

Jury.
And now, this.
So yes, I guess the loop is complete.

Photo: fran innocenti on Unsplash

What being a hackathon jury is actually like

I expected judging to be relaxing.
You sit.
They present.
You nod wisely.

It is not relaxing.
It's exhausting.

You have to stay unbiased.
Team twenty deserves the same judge as team one.

You have to stay focused through every single pitch.
Even the fifth version of the same idea.

And you can't show any stress.
Not a sigh, not a yawn, not a glance at your phone.
The students are nervous enough already.
They read every flicker on your face.
I know, because I used to do the reading.

So you hold a polite, interested face for two whole days.
It's basically acting.
Nobody warned me there'd be acting.

Watching my own mistakes, live

Here's the uncomfortable part.

The mistakes I saw were my mistakes.
The exact ones I made as a participant.

Over-engineering.
Teams built huge systems for a two-day problem.
I did that too.
The demo always pays the price.

Drifting from the problem statement.
Some teams started on the given problem.
Then they wandered somewhere more exciting.
The judge is still holding the original problem statement.

Trying to impress instead of showing.
Lots of big words.
Not enough working product.
I recognised that one instantly.
I used to be fluent in it.

I turned all of this into a practical guide.
It's called how to win a hackathon, according to a tired judge.
Send it to anyone with a hackathon this month.

Photo: Werner Pfennig on Pexels

Why judges lose focus after the fifth team

Most teams in my group had the same or similar problem statements.
That happens when teams are grouped by theme.

It means the fifth explanation of a problem lands differently than the first.
After that, attention slips.
I felt it, even while trying hard not to.

Psychologists have names for things like this.
Decision fatigue describes decisions getting worse after a long run of them.
To be fair, the evidence for it is mixed.

Order effects are better documented.
A Carnegie Mellon study found later performers got higher marks in Eurovision and figure skating.
A 2017 study of song contests found something similar.
Expert judges were swayed by a randomly assigned running number.

Hackathons aren't song contests.
Although some pitches did have a chorus.
The lesson still carries over: judges are human, and humans drift.

A note for hackathon organisers: mix up the topics

This is the one thing I'd change as an organiser.

Don't give one jury a stack of teams with the same topic.
Give each jury a mix of problem statements.

The same topic ten times in a row flattens everything.
The judge loses interest.
Small differences start looking huge, or invisible.
The evaluation stops being as fair as it should be.

A few other things I'd suggest:

Mix themes in every jury group. Variety keeps judges sharp.
Shuffle the running order. Don't let the same kind of team always land last.
Give judges a short rubric. Four or five criteria, scored as they go.
Build in breaks. Ten minutes between batches does more than coffee.
Brief teams on timing. A firm pitch limit helps everyone, judges included.

None of this is expensive.
It just needs someone to think about the judge's day.
Usually nobody does.

Photo: Kishore V on Unsplash

What I'd tell my participant self

If I could go back to the nervous kid with the laptop:

Read the problem statement twice. Build for that.
Pick boring tools you already know.
Make one flow work perfectly.
Say hello to the judge like a human.
Stop talking when the demo's done.

He wouldn't listen.
He'd still over-engineer it.
But it's nice to finally know the answers.

Learning by doing it badly first is basically my whole method.
Bio-maths to computer science explains how that started.
And exams, the office and a 1 a.m. gate shows how it's going.

FAQ

What does a hackathon jury do?

A hackathon jury evaluates team projects, usually against set criteria.
That means watching demos, asking questions and scoring fairly.
It also means staying sharp through a very long day.

Is being a hackathon judge hard?

More than it looks.
You're making careful judgements back to back, for hours.
And you're doing it with a calm face, for students who are very nervous.

What's the biggest mistake hackathon teams make?

From the jury side, building too much and showing too little.
One working flow beats an ambitious system that won't load.

Thanks for having me

Thanks to the Department of Computing Sciences and the Vels Innovation Council for inviting me.
And to every team that pitched.
Especially the ones who reminded me of my own old mistakes.

I build products at TrackMy Tech.
If you're organising a hackathon and want a judge, book a call.
I'll bring my polite, interested face.

Outsourcing vs building it yourself: our app arrived from 2006

Tue, 27 Oct 2026 08:30:00 +0000

Every founder has a moment where they say, "Fine. I'll do it myself."
Mine came with a very specific smell.
The smell of PHP and a design from another decade.

This post is about outsourcing app development vs building it yourself.
I've done the first one badly and the second one stubbornly.
So I have opinions.
Lots of them.

The idea was simple

It started with a coach complaining.
His students' fee payments just wouldn't tally.

Small problem.
Annoying problem.
The kind that sticks in your head.

That problem became Track My Academy.
The full origin story is in how a coach's complaint turned into a company.

At that point, I had basically zero real coding experience.
I'd made small, chota-chota apps.
But I had no idea how an app actually works in production.
Domains, servers, deployment: all a mystery.

What I did have was a business mindset.
How the product should look.
How we'd get customers.
How we'd get paid.
That's it.

So we did what sensible people do.
We looked for freelancers and found an agency.
The plan was to pay them for a white-label solution.

On paper, that's textbook outsourcing.
You pay an external provider to do work you'd otherwise do in-house.
Except we didn't really have an "in-house".
We had enthusiasm.
Enthusiasm is not a department.

Then the build arrived

I opened it.
I looked at it.
It looked back at me from 2006.
It looked like it had jumped straight out of a template from that year.

Photo: Siri louis on Unsplash

PHP.
A design that belonged in a museum.
The kind of interface that makes you check your calendar.

To be fair, PHP isn't the villain here.
Plenty of good software runs on it.
The design was the villain.
And, probably, so was our brief.

Not a single screen looked decent.
The thing technically worked.
But it looked so bad that nobody wanted to touch it.
I was ashamed to show it even to my friends.
That's how bad it was.

So we scrapped the whole thing.

I sat there and thought one clear thought.
"Damn. I'll do this myself."
I'd build it with AI tools, the way people now call vibe coding.

The stupidest ₹50,000 I've ever spent

Let me be honest about the price.
We paid that agency ₹50,000.
It's the stupidest way to spend 50k I can think of.

And it wasn't even my money.
It was my co-founder's.
He didn't take it too hard.
But I was responsible for that decision.
I still feel bad about it, honestly.

Outsourcing app development vs building it yourself

Here's my honest comparison, after one very educational PHP build.
These are opinions, not laws of physics.

Outsourcing makes sense when:

You know exactly what you want, down to the screens.
The app supports your business but isn't the business.
Someone on your side can review the code and the design.
You have budget for a second round. There's always a second round.

Building it yourself makes sense when:

The product is the business.
You'll be changing it every week for years.
You're willing to be bad at it for a while.
You'd rather understand every bug than pay someone to explain it.

Track My Academy was clearly the second list.
It's the company, not a side tool.

There's also a third option people forget.
Build the first version yourself.
Then bring in people who already understand what you're making.
For most student founders, that's where I'd point them.

How to write a product brief that doesn't come back from 2006

Here's the thing nobody tells you.

If you can't describe what good looks like, you won't get good.
You'll get whatever the builder thinks "done" means.

And their "done" might be from 2006.

Bigger companies write a product requirements document.
It says what the product should do, not how to build it.
You don't need forty pages.
You need one honest page.

Photo: Compagnons on Unsplash

My checklist for a one-page product brief:

Who it's for. "A coach with one batch" beats "sports organisations".
The one painful job. For us, that was attendance and payments.
Three apps you like the look of. Screenshots, not adjectives.
What "done" means. Which screens, which actions, which devices.
What you won't build yet. This list saves more money than any discount.
Who checks the work. If nobody can read code, say so upfront.

Point three is the one I'd underline twice.
"Modern and clean" means nothing.
Every design was modern and clean once.
Even in 2006.

The aim is a minimum viable product.
That means just enough features for early users to actually use it.
Then their feedback tells you what to build next.
Not your imagination at 2 a.m.

The first night of building a SaaS MVP myself

My setup was not exactly a startup lab.

A MacBook Air.
A second-hand iPhone my cofounder got me.
ChatGPT.
VS Code.

That was the entire tech stack of my ambition.

Did I start coding immediately?
No.
Mostly, I researched.

How do real products look?
How do people structure an app like this?
Why does everything I write look worse than everything I see?

By the end of it, I'd built a landing page.
A landing page I actually liked.
That was the night I stopped waiting for someone else.

Building it properly took about three months.
The first working version alone took more than a month and a half.
Changes, then more changes, then changes to the changes.

When I look at that first version now, I'm honestly embarrassed.
It might be the worst thing that ever happened to a piece of software.
The version we have today? I'm really proud of it.

I learn by touching the thing until it makes sense.
That means doing it badly first, then slightly less badly.
The AI help came from wherever we could find it.
That story is in dozens of email accounts and zero shame.

The modern stack I ended up with

No PHP this time.
Again, nothing against PHP.
I just needed a fresh start and a clean conscience.

Here's what Track My Academy runs on:

React for the web front end.
FastAPI, a Python framework for building APIs with type hints.
MongoDB, a document database.
Supabase, which bundles Postgres, auth, storage and realtime features.
AWS EC2 and Vercel, where things actually run.
Razorpay, the payments gateway.
Firebase and Redis, quietly doing their jobs in the background.

None of this is exotic.
It's just current.
And I can explain why every piece is there.

That's my real advice for anyone outsourcing.
Ask the builder, "Which stack, and why?"
If the answer is "it's what we always use", that's information.
Treat it like a yellow card.

Knowing the stack also means knowing exactly how to break it.
I proved that when I took production down for hours.
Ownership cuts both ways.

Then I built the Android and iOS apps too

The web app wasn't the end.
Coaches aren't sitting at desks.
They're on a pitch, holding a phone and a whistle.

So I built the Android and iOS apps for Track My Academy.
The Android app is live in production.
The iOS app is coming soon.
Apple reviews things slowly. So do I, to be fair.

Photo: Daniel Romero on Unsplash

This is where building it yourself pays off.
I'd built the backend, so I knew it inside out.
The apps were new screens, not new mysteries.

If I'd outsourced the web app, the mobile apps would've started from zero.
Or from 2006 again.
I'm not sure which is worse.

Today Track My Academy covers attendance, fees, player analytics and parent communication.
Real academies run on it.
It's multi-tenant and role-based, which is a fancy way of saying "complicated".
It works on the web and Android, with iOS coming soon.
It's published by TrackMy Tech, our bootstrapped sports-tech company.

What I learned from the 2006 build

I'm not angry at the agency that built it.
Okay, a little.
Mostly at myself.

Outsourcing works when you know what you want.
It doesn't work when you're hoping someone reads your mind.

Building it myself meant I understood every piece.
When something breaks, I know where to look.
When a coach wants a feature, I know what it costs.

None of that exists if I'd accepted the museum piece.

So, should you build it yourself?
Not always.
But if what comes back makes you wince, listen to the wince.

Your irritation is data.

Mine turned into a company.
Yours might turn into something too.
Or at least into a better landing page.

I'll take either.

FAQ

Is it cheaper to outsource app development or build it yourself?

Outsourcing usually looks cheaper on day one.
Building yourself costs time instead of money.
Outsourcing costs money, then often time anyway, in revisions.
If the product is your business, I'd rather pay with time.

What should a product brief for a developer include?

Who it's for and the one painful job it solves.
Three reference apps, with screenshots.
A clear definition of done, and a list of what's out of scope.
And who will review the work before you pay for it.

Can a non-technical founder build a SaaS MVP?

I was a bio-maths student in class 12.
That story is in how I ended up in computer science.
So yes, eventually.
Expect to be bad at it first.
That's the tuition fee.

Your turn

Run a sports academy and tired of spreadsheets?
Try Track My Academy.

Stuck deciding between outsourcing and building it yourself?
Book a call with me and we can argue about it.

Or see where all this happens now, in my three-monitor desk setup.

A coach complained, so I built sports academy management software

Tue, 27 Oct 2026 04:30:00 +0000

Cover photo: Adrià Crehuet Cano on Unsplash

Most startup stories begin with a vision.
Mine began with a complaint.

Not even my complaint.
Two other people's.

This is the story of how Track My Academy started.
It is sports academy management software now.
Back then, it was one tired coach, one frustrated academy owner and a messy spreadsheet.

I'm writing it down because people keep asking where the idea came from.
The honest answer is less heroic than they hope.

The evening it started

I was coaching football part-time at a sports academy.

Nothing glamorous.
Cones, whistles, and a lot of shouting about passing.

One evening, I noticed a coach struggling with his phone.
He was trying to match his students' fee payments.
On one side, the payments in his Google Pay account.
On the other, the manual entries he'd been writing down.
They didn't tally.

I asked the obvious question.
"Why don't you just use an Excel sheet?"

His answer was very honest.
He runs everything from his phone.
Keeping an Excel sheet updated every time just wasn't happening.

The academy's owner was listening.
He's now my co-founder, which tells you how this story ends.
He asked me something simple.
"Why don't you build a small app for these guys?"

Coaches would enter their payment details.
Everything would land in an Excel sheet automatically.
No more tallying at night.

Photo: Adrià Crehuet Cano on Unsplash

The first prototype: a spreadsheet pretending to be an app

So I built the simplest thing possible.
It didn't even have a database.
The Excel sheet was the database.
Yes, really.

The app was just a small form.
A coach entered how much they'd received.
They pasted the payment ID from Google Pay.
Done.

The entry dropped straight into the sheet.
The sheet was shared automatically.
The owner could open it any time and see everything.

It was ugly. It was tiny. It worked.
That was the very first prototype of Track My Academy.

From one academy to "wait, why not everyone?"

Then a thought hit me.
Hey, wait.
Why can't I sell this to other people?

Plenty of academies had exactly this problem.
Fees tracked on paper, phones and memory.
And player training was just as messy.
Who attended. Who improved. Who needs more work.

So the payments form grew up.
It became sports academy management software.
Later, it also became a sports analytics tool, in the same app.
How the analytics got in there is a story for another post.

Why sports academy management software is a boring problem worth solving

Here's something nobody tells you about startups.
The best problems are usually boring.

Attendance registers. Fee reminders. Who paid. Who didn't.
Nobody makes a film about fee reminders.

But coaches deal with this every single day.
And every hour spent on paperwork is an hour not spent coaching.

That's not boring to them.
That's their whole evening.

Paul Graham has a name for why people skip these problems.
He calls it schlep blindness.
Your brain quietly hides ideas that involve tedious work.

Jared Friedman says something similar in YC's talk on getting startup ideas.
His example is Gusto, which makes payroll software.
Lots of programmers knew payroll software was bad.
Nobody fixed it, because it was boring.

Sports admin is the same flavour of boring.
Which, in my opinion, is exactly why it was worth doing.

Attendance tracking for sports academies

Let's start with the original villain.

Attendance tracking for sports academies sounds trivial.
It is not.

Batches change.
Kids switch timings.
Some coaches cover two branches.
Somebody always forgets the register at home.

Paper works until it doesn't.
Then you're reconstructing last month from memory and a WhatsApp group.

Photo: Billy Albert on Unsplash

In Track My Academy, attendance is the boring core.
Check-in can be by QR code, biometric or the mobile app.
Coaches get alerts when someone is absent.

That last bit matters more than it sounds.
A missed session is a small signal.
Three missed sessions is a conversation with a parent.

Fee collection and reminders without the awkwardness

Then there's money.

Nobody likes chasing fees.
Coaches especially hate it.
They signed up to teach a sport, not run accounts receivable.

So the software handles fee collection and reminders.
Invoices go out.
Reminders go out.
Payments get recorded.

The coach doesn't have to be the bad guy at the gate.
The system can be the bad guy.
Systems don't mind.

The stack includes React, FastAPI, MongoDB, Supabase and Razorpay.
Plus a few friends I won't list here.
I'll spare you the architecture diagram.

Attendance and fees were the complaint.
But once the data was in one place, more became possible.

Player progress tracking was the obvious next step.
Coaches can log performance and see trends over time.
Pace, endurance, accuracy, skill.

Parents can see shareable player reports on their phone.
Which, frankly, saves a lot of "so how is he doing?" chats after training.

Photo: Jamie Street on Unsplash

Parent communication lives there too.
Announcements, session updates and direct messages.
No more screenshotting the timetable into six groups.

It's a software as a service product.
The academy doesn't host anything.
It just logs in.

It's also multi-tenant.
Many academies can share one system, each with separate data.

And it uses role-based access control.
Owners, coaches and parents each see what their role allows.
A parent should not be able to edit the fee ledger.
Tempting as that might be for them.

There's a web app and an Android app.
The iOS app is coming soon.
I built the mobile apps myself.
That sentence is doing a lot of heavy lifting.

And real academies run on it.
That part still feels slightly unreal.

From a 2006-looking app to building it myself

The road there was not straight.

For the full product, we first hired someone to build it.
What came back was PHP, terrible design, and looked like 2006.
I wrote about the app that arrived from 2006 separately.
It is a whole saga.

So I decided to build it myself.

The first night was a MacBook Air.
A second-hand iPhone my cofounder got me.
ChatGPT and VS Code.

Mostly research.
Then a landing page I actually liked.

I learn by touching the thing until it makes sense.
Usually by doing it badly first.

Later came the less glamorous lessons.
Like hunting free AI trials across dozens of email accounts.
And the night I broke production by splitting the backend.

TrackMy Tech, CP Sports, and the titles I didn't expect

Track My Academy started in December 2024.

Since June 2026, it has a proper home.
TrackMy Tech Pvt Ltd is the sports-tech and SaaS company that publishes it.
It's bootstrapped.
I'm its Executive Director.

Which still sounds funny to me.
I'm also a student.
The exams have not been informed of my title.
More on that in exams, the office and a 1 a.m. gate.

Separately, I'm Technical Operations Manager at CP Sports.
I built its first official website and internal academy and event tools.
I also manage the digital team and coordinate coaches across branches.

That job keeps me close to how academies actually run.
Veeran came later, built at TrackMy Tech.

What coaching taught me about building

Coaching and building products are weirdly similar.

You can't redo the first half.
Football has twenty-two players, ninety minutes, and no undo button.
Production software feels exactly the same.

Listen more than you talk.
That coach didn't pitch me a startup idea.
He just couldn't make his payments tally.
The idea was hiding inside the complaint.

Fix what people actually do.
Coaches don't want dashboards for fun.
They want to finish admin and get back to the pitch.

Photo: Connor Coyne on Unsplash

Finding startup ideas in real complaints

Stop looking for big ideas.

Paul Graham puts it neatly in How to Get Startup Ideas.
The verb you want is not "think up".
It's "notice".

Go and sit near people doing their actual jobs.
Wait for them to complain.

Write down the complaint.

Then ask a few annoying questions.
How often does this happen?
What do you do about it now?
Would you pay to never deal with it again?

If the answers are "daily", "a spreadsheet" and "yes", congratulations.
You may have a company.

It won't sound exciting at a party.
It will sound very exciting to the person who has that problem.

And honestly? Parties are overrated anyway.
I'd rather be at the office.

Which is probably a problem of its own.

FAQ

What is sports academy management software?

It's software that runs the admin side of a sports academy.
Attendance, fees, player progress and parent messages, in one place.
Ideally, so the coach can go back to coaching.

Does Track My Academy work on phones?

Yes.
There's a web app and an Android app, and the iOS app is coming soon.
Coaches and parents mostly live on their phones anyway.

How do I find a startup idea?

Notice problems instead of inventing them.
Boring, repeated, slightly embarrassing problems are the best ones.
Then check whether people would actually pay to make them go away.

Try it, or talk to me

If you run an academy, take a look at Track My Academy.
There's a free plan, so the risk is mostly your time.

If you'd rather talk it through, book a call with me.

Or read how the smart football prototype went.
Spoiler: it's in the title.

Production outage lessons: we blamed our code. It was SSL.

Mon, 26 Oct 2026 12:01:40 +0000

Building a product is one job.
Keeping it alive is a completely different job.

Nobody warns you about the second one.
Or they do, and you don't listen.
I didn't listen.

This post is my production outage lessons, learnt the expensive way.
One backend split, one expired SSL certificate, four hours of blaming the wrong thing.
And what I'd do differently: checklists, rollbacks, monitoring and postmortems.

The clever idea: splitting the backend

This happened in 2026, not long after we incorporated TrackMy Tech.
We'd just become a private limited company.
And we had a nagging feeling we weren't doing things professionally enough.
We wanted to fix that.

We also had real problems.
Lots of payment-related issues.
A steady stream of API errors.
And the load wasn't balancing well.

Then an Instagram reel showed up.
I shared it with the team.
"This model is so capable. We can try some serious stuff with it."
That one reel kicked off the whole cycle.

The plan: split the backend into separate pieces.
We used an AI coding agent to do the heavy lifting.
To be fair to the agent, it did its job.
It was us who got things wrong.

On paper, splitting load sounds smart.
Spread the work. Feel like a real engineering team.
Put "distributed" in your head and feel tall.

Then everything went down

Not slowly. Not politely.
Everything went down.
For hours.

If you've never broken production, let me describe the feeling.
Your stomach drops to somewhere near your shoes.
Every message notification sounds like an accusation.

Real academies use Track My Academy.
Real coaches. Real parents. Real attendance.

None of them care about our clever architecture.
They care that the app works.

And it did not work.

Photo: Taylor Vick on Unsplash

The real culprit: an expired SSL certificate

We were sure we'd broken the code.
So we did what any panicking team does.
We checked the split.
We checked the code.
Then we checked it all again.

About four hours later, we found it.
It wasn't the code at all.
The SSL certificate on our backend domain had expired.
Right in the middle of the transition.

It was failing silently.
And we were busy blaming our own clever architecture.

When we finally saw it, we just stared at the screen.
Oh God.
This is why debugging is hard.

Here's why it's so sneaky.
A TLS certificate proves a server is who it claims to be.
Every certificate has a "Not After" date.
After that date, it's simply no longer valid.
Apps and browsers stop trusting the server, and requests fail.

Short certificate lifetimes are normal now.
Let's Encrypt says its default certificates are valid for 90 days.
It recommends renewing them every 60 days.
Miss a renewal and the clock just quietly runs out.

The timing is what fooled us.
Two things changed at once: our backend, and the certificate's validity.
So naturally we blamed the change we'd made ourselves.

Google's SRE book says roughly 70% of outages come from changes to a live system.
We were the change.
We just weren't the cause.

The longest night in the office

I stayed in the office all night.

Not because it looks dedicated on LinkedIn.
Because it was my mess, and I wanted it fixed.

There's a special kind of quiet in an office at 3 a.m.
It's just you, the monitors, and your mistakes.

The Monster cans on the wall were not decoration that night.
They were fuel.
(The full tour of that desk is in three monitors, one Monster can.)

Office nights are not rare for me, sadly.
That's a whole other post: exams, the office and a 1 a.m. gate.

When I'm stuck badly enough, I call Arun

Every founder needs one person who picks up at any hour.
For me, that's Arun. Our CTO.

No questions asked. He just picks up.
At any hour. Which is frankly suspicious.

If you want to know who he is, here's his portfolio.
He's the reason "stuck" never becomes "stuck forever".

The lesson here isn't technical.
Know who you'll call before the crisis, not during it.

A deployment checklist I'd hand my past self

I'm not going to pretend I have a grand theory.
But here's the checklist that night burned into my brain.

Check the boring stuff first. SSL certificates, DNS, environment variables. Then blame the code.
Know when every certificate expires. Write the dates down before you touch anything.
Change one big thing at a time. Two changes, one failure, endless guessing.
Deploy when people are awake. Ideally the people who can fix it.
Know your way back. Before you ship, not after.
Watch it after you ship. "Deployed" is not the same as "working".

Google's SRE book lists three practices for safer changes.
Progressive rollouts.
Quickly and accurately detecting problems.
Rolling back safely when problems arise.

That's basically my checklist, written by people with far more sleep.

Photo: Jakub Żerdzicki on Unsplash

Rollbacks: have a way back

If you can't undo a change quickly, you're not deploying.
You're gambling.

One classic pattern is blue-green deployment, as Martin Fowler describes it.
You keep two nearly identical production environments.
One is live. The other gets the new version.
You test the idle one, then switch the router over.

If it breaks, you switch the router back.
Fowler calls it "a rapid way to rollback".

You don't need a fancy setup to steal the idea.
Keep the old config. Keep the old build.
Know the exact command that puts things back.
Practise it once on a calm day.

Monitoring and alerting: find out before your users do

The worst way to discover an outage is from a user.
The second worst is from a friend asking "is your app down?"

The Google SRE chapter on monitoring distributed systems is a good start.
It names four golden signals: latency, traffic, errors and saturation.
Measure those and page a human when they look wrong.
I'd add one more for small teams: certificate expiry dates.
That gets you decently covered, according to the book.

It also says something I love: "Every page should be actionable."
An alert you ignore is just a very expensive ringtone.

Later, I built a "Pager System" for Track My Academy developers.
It's an internal real-time error and notification system.
The idea is simple: problems should find developers, not wait to be found.

Photo: Luke Chesser on Unsplash

Write the postmortem, and keep it blameless

After the fix, the temptation is to sleep and never speak of it again.
Don't.

Write an incident postmortem.
Google's chapter on postmortem culture puts it nicely.
"Writing a postmortem is not punishment."
It's a learning opportunity for the whole company.

Their triggers include user-visible downtime and an engineer having to roll back.
A multi-hour outage ticks both boxes with enthusiasm.

Atlassian's guide to incident postmortems is very practical.
It covers a timeline, root cause, impact, metrics and action items.
It suggests a review meeting within 24 to 48 hours of resolution.
Then draft the write-up straight after.
Wait longer and the details evaporate.

Blameless doesn't mean nobody made a mistake.
It means you fix the system so the next person can't make it.
Even if the next person is, once again, me.

Was it worth it?

Honestly? Yes.
Not the outage. The outage was terrible.
But I learned more in that one night than in a month of tutorials.

Mistakes are expensive teachers.
They're also very, very memorable.

I'd still prefer the tutorials, though.

FAQ

What are the most important production outage lessons for a small team?

Change one thing at a time.
Always have a tested way back.
Monitor the basics so you hear about problems before users do.

Can an expired SSL certificate take down a backend?

Yes, and quietly.
Once a certificate passes its expiry date, clients stop trusting the server.
Requests fail, and it can look exactly like a code bug.

What should go in an incident postmortem?

A timeline, the impact, the root cause and clear action items.
Keep it blameless.
Fix the system, not the person.

Sources

What next

Curious how the product got built in the first place? Read the app that arrived from 2006.
Or how I learned the tools: dozens of email accounts and zero shame.

Running an academy? Track My Academy handles attendance, fees, player analytics and parent communication.
It's built by TrackMy Tech.

Want to talk shipping, breaking and fixing things? Book a call.

How a QA Problem Turned Into the SaaS I’m Building

Sat, 29 Aug 2026 14:19:38 +0000

I didn’t start building Dulvarn because I wanted to become a SaaS founder.

At least, not at first.

I started with a problem I kept seeing again and again in software delivery.

A team could have:

green CI
passing tests
successful builds
approved pull requests
deployment steps ready

And still, one question remained difficult to answer clearly:

Are we actually ready to release?

That question stayed with me.

Because in theory, software teams already have many signals.

CI tells us something.

Automated tests tell us something.

QA tells us something.

Security tools tell us something.

Pull requests tell us something.

Monitoring tells us something.

But those signals are often scattered across different tools, dashboards, tickets, reports, and conversations.

And when it is time to make the final release decision, the answer is not always as clear as the pipeline color suggests.

That gap is where Dulvarn started.

Green does not always mean confident

One of the ideas I kept coming back to was simple:

A green pipeline tells you that the checks you defined passed.

That is valuable.

But it does not automatically tell you that the release risk is low.

For example:

Build                     PASS
Automated tests           PASS
Security scan             PASS

Database migration        YES
Authentication change     YES
Rollback confidence       MEDIUM
Observability coverage    PARTIAL
QA coverage               LIMITED

Nothing here is necessarily red.

But it also does not feel like a release decision that should be made blindly.

The build passed.

The tests passed.

The scan passed.

But the release still deserves thought.

What changed?

How risky is the change?

Can we roll it back?

Do we have enough visibility after deployment?

Do we understand the weakest part of the release?

That difference between technical validation and release confidence became more interesting to me over time.

And once I noticed it, I started seeing it everywhere.

QA taught me to ask uncomfortable questions

Working in QA changes the way you look at software.

You naturally start asking:

What could fail?
What was not covered?
What assumption are we making?
What happens if the user does something unexpected?
What changed between environments?
What evidence do we actually have?

At first, those questions were mostly about features.

Does login work?

Can the user complete checkout?

Does validation behave correctly?

Does the API return the expected response?

But as I moved deeper into automation, CI/CD, DevOps, observability, and release engineering, the questions became broader.

I started asking:

What happens if the deployment succeeds, but the system becomes unhealthy?

What if the tests pass, but rollback is unclear?

What if the release includes a risky migration?

What if different teams each have part of the evidence, but nobody has the whole picture?

At that point, the problem was no longer only testing.

It was release decision-making.

Release readiness is often spread across too many places

In many teams, release evidence is not missing.

It is fragmented.

One signal lives in CI.

Another lives in test reports.

Security findings live somewhere else.

Deployment status is in another system.

Approvals may be in a ticket.

Important context may be in Slack.

Risk may be understood by one engineer, but not written down anywhere.

And then someone has to decide whether the release should go out.

That decision can become strangely informal compared to everything that came before it.

Code review is structured.

CI is structured.

Testing is structured.

Deployment is often structured.

But the release decision itself can still depend on scattered context and human memory.

That bothered me.

Not because people were careless.

But because the tools around them were usually optimized for execution.

Build.

Test.

Deploy.

They were less focused on the decision between those steps.

Dulvarn started as a release control idea

The idea behind Dulvarn came from that gap.

I wanted to explore a simple question:

What if release decisions were based on collected evidence instead of scattered signals and assumptions?

Not to replace CI.

Not to replace QA.

Not to replace DevOps.

And definitely not to replace people.

The point is not to make software delivery fully automatic and hope for the best.

The point is to make release risk more visible.

Something like:

CI
QA
Security
Change Context
Deployment Readiness
Operational Signals
Approvals
        ↓
Release Evidence
        ↓
Risk Context
        ↓
GO / CONDITIONAL GO / NO-GO

The label matters less than the explanation behind it.

A good release decision should not only say:

GO

It should also explain why.

And if the answer is:

CONDITIONAL GO

Then the team should understand the condition.

And if the answer is:

NO-GO

Then the reason should be clear enough to act on.

That is the direction I started building toward.

I am not trying to build another giant platform

One thing I care about is keeping the core idea clear.

Software teams already have enough tools.

They do not need another huge platform that tries to replace everything they use.

The interesting part is the layer between existing systems.

Collect the signals.

Understand the context.

Evaluate the risk.

Make the decision visible.

Keep the evidence.

That is the part I keep coming back to.

Dulvarn is not meant to be a magical AI system that takes control away from teams.

It is meant to support human-controlled release decisions.

The software can help organize evidence.

It can highlight risk.

It can make patterns easier to see.

It can preserve decision history.

But the responsibility still belongs with people.

That matters to me.

Especially because release decisions are not only technical.

They involve judgment.

Building the idea was easier than defining the product

This was one of the first lessons I learned.

Writing code is only one part of building a SaaS.

You also need to answer questions like:

Who exactly is this for?
Which problem is painful enough to solve?
What belongs in the MVP?
What should not be built yet?
How should onboarding work?
What should users see first?
What should remain manual?
What should be automated?
What is useful now, and what is just interesting?

Those questions are often harder than building another endpoint or UI component.

And they do not have clean pass/fail answers.

As a QA engineer, I was used to looking for defects.

As a product builder, I had to start looking for unnecessary complexity too.

That is a different skill.

And I am still learning it.

The temptation to build too much is real

When you build your own product, every idea feels useful.

Add another integration.

Add another dashboard.

Add another AI feature.

Add another report.

Add another workflow.

Add more settings.

Add more intelligence.

The product can become impressive very quickly.

It can also become impossible to understand.

I had to learn that a technically strong feature is not automatically a product priority.

Sometimes the better decision is:

Not yet.

That is surprisingly difficult when you are the person imagining the system and building it at the same time.

Because you can see the future version in your head.

But users do not start with the future version.

They start with the first useful version.

And that version has to be clear.

Building while working full-time changes everything

There is another reality behind Dulvarn.

I am building it while working a full-time job.

That means time matters.

Energy matters.

Focus matters.

You cannot treat every idea like an emergency.

You cannot spend weeks polishing something nobody has asked for.

You cannot rebuild the architecture every time a more elegant solution appears.

At least, not if you want to ship something.

This has forced me to think much more seriously about priorities.

What moves the product forward?

What creates evidence that the idea is useful?

What helps me get closer to real users?

What is just interesting engineering?

Those are different things.

And as a technical founder, it is very easy to confuse them.

Building Dulvarn changed the way I think about QA

Interestingly, building a SaaS has also made me think differently about QA.

When you own the whole product, quality becomes much bigger than testing.

A confusing onboarding step matters.

A broken deployment matters.

A slow page matters.

A missing error message matters.

Security matters.

Observability matters.

Documentation matters.

Support experience matters.

Pricing clarity matters.

The product is not only the code.

The product is the whole experience around the code.

That perspective feeds back into how I think about software quality in general.

Quality does not start when testing begins.

And it does not end when QA says passed.

It exists across the full lifecycle of the product.

This is still early

Dulvarn is not a finished story.

It is still early.

There are things I will probably change.

Features I will remove.

Assumptions I will test.

Positioning I will sharpen.

Workflows I will simplify.

Technical decisions I will rethink.

That is part of the process.

I do not want to write this series as if I already have everything figured out.

I do not.

I am building, learning, cutting scope, testing ideas, and trying to turn a real QA and release engineering problem into something useful.

That is exactly why I want to document it.

Not as a perfect founder story.

More as a record of what I am learning while building.

In this series, I want to write about the real process behind building Dulvarn.

Things like:

how I decide what belongs in the MVP
how I think about release risk
what I learn from user feedback
how I approach onboarding
how I avoid building too much
how I think about pricing
how I balance AI with human control
how I work on infrastructure
how I manage product decisions while working full-time
what I build and later remove

Not as a tutorial for building the perfect SaaS.

I definitely do not have that.

More as a practical founder log from someone trying to build a product from a problem he understands deeply.

Dulvarn did not start because I wanted to become a SaaS founder.

It started because QA kept leading me toward bigger questions.

Testing led to automation.

Automation led to CI/CD.

CI/CD led to DevOps.

DevOps led to release engineering.

And release engineering led to one question I could not stop thinking about:

If all our systems produce signals, who actually turns those signals into a release decision?

I am still working on the answer.

And I am building a product around it.

This is the first article in my How I’m Building a SaaS series.

In the next article, I want to write about one of the hardest lessons so far:

how to decide what not to build.

Is Your Business Invisible on AI Search?

Mon, 10 Aug 2026 11:26:03 +0000

A business can have a good website, good reviews, and even strong Google rankings and still be almost invisible when someone asks ChatGPT or Gemini:

“What’s the best [service] in [city]?”

I recently looked into this problem and found that some businesses simply weren't being mentioned when AI tools were asked to recommend companies in their area.

The interesting part? Being visible on Google doesn't automatically mean you'll be visible in AI search.

I worked on improving the signals and information that AI search systems use to understand and recommend a business.

After making the changes, the business became much more visible in relevant AI searches.

AI search is changing how people discover businesses. If you're not checking how your company appears on ChatGPT, Gemini, and other AI search tools, you may not even know what you're missing.

Curious about how your business appears? Feel free to reach out.

Coder Legion - Recent posts tagged founder

The 3 a.m. call: why every founder needs an Arun

The one person who picks up

Why going it alone is harder than it looks

The catch: the people can also sink you

Trust is what makes the call possible

What I'd tell another founder

One last thing

FAQ

Do you need a co-founder to start a startup?

What is psychological safety in a team?

How do you make late-night emergencies rarer?

Sources

What next

Shipping Android and iOS solo (iOS: coming soon)

Building it is the part you expect

The two doors: Play Console and App Store Connect

Google's 12 testers and 14 days

Apple's reviewers read the guidelines so you have to

Why Android first, for us

What I'd tell another solo dev

FAQ

Is the Track My Academy iOS app out?

Do new Google Play developers need testers before going live?

How much does it cost to publish on both stores?

Sources

What next

Switching from biology to computer science, with zero plan

Choosing a stream after class 12 (badly, in my case)

What biology and maths quietly taught me about code

Can a bio-maths student do B.Tech in computer science?

What B.Tech AI and Data Science actually is

Learning to code from a non-CS background

Biology found me again anyway

Nothing went the way I expected

If you're choosing a stream after class 12 right now

FAQ

Is switching from biology to computer science hard?

Can I do B.Tech AI and Data Science after bio-maths?

Do I need a CS background to learn coding?

Making the switch yourself?

I built a pager for my own developers

A very old idea

Why a small team needs one

The rules I'd steal from Google

The danger: a pager that cries wolf

What I think a good internal pager should do

About those certificates

The point

FAQ

Does a small team really need alerting?

What should trigger a page?

How do I avoid alert fatigue?

Sources

What next

From hackathon loser to hackathon jury: the loop is complete

Every seat at the hackathon table

What being a hackathon jury is actually like

Watching my own mistakes, live

Why judges lose focus after the fifth team

A note for hackathon organisers: mix up the topics

What I'd tell my participant self

FAQ

What does a hackathon jury do?

Is being a hackathon judge hard?

What's the biggest mistake hackathon teams make?

Thanks for having me

Outsourcing vs building it yourself: our app arrived from 2006

The idea was simple

Then the build arrived

The stupidest ₹50,000 I've ever spent

Outsourcing app development vs building it yourself

How to write a product brief that doesn't come back from 2006

The first night of building a SaaS MVP myself

The modern stack I ended up with

Then I built the Android and iOS apps too

What I learned from the 2006 build

FAQ

Is it cheaper to outsource app development or build it yourself?

What should a product brief for a developer include?