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.

Player progress tracking and parent communication

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.

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.

Let me confess something. Early on, we had dozens of email accounts. Not for spam. Not for anything shady. For free AI trials.

This post is about learning AI coding tools as a student. No budget. No clue. Lots of inboxes. It's also about what that chaos actually taught me. Spoiler: the lesson is not "make fifty email accounts".

The great free trial hunt

Here's what our learning strategy looked like.

Find an AI tool. Sign up for the free trial. Use it until the trial ends. Make a new email. Repeat.

When we ran out of our own accounts, a few friends lent us theirs.

My friends were very generous. Possibly too generous.

It was less elegant than it sounds. It worked.

Photo: Chirayu Trivedi on Unsplash

Why we did it

The honest reason is simple.

We didn't know how to use Claude or Codex yet. We didn't know which tool was good at what. We definitely didn't have money for every subscription. And even if we had, I wouldn't have spent it. More on that later.

So we tested everything.

Some tools were brilliant. Some were brilliant at sounding brilliant. A few were just autocomplete with a marketing budget.

You only learn the difference by using them.

We were hardly the only curious ones. The Stack Overflow 2025 Developer Survey asked developers about AI. 84% said they use or plan to use AI tools. Only 33% said they trust the accuracy of those tools. 46% said they actively distrust it.

So nearly everyone uses them, and plenty don't trust them. That gap is the whole story of learning these tools.

I learn by touching things

This is how my brain works.

I don't read the manual first. I touch the thing until it makes sense. I do it badly first, on purpose or otherwise.

Sometimes the thing breaks. Sometimes I break. Usually, by the end, I understand it.

Nothing about my path was planned, by the way. I was a bio-maths student in class 12, then ended up in computer science.

Free trials suited a brain like mine. Low cost. High chaos. Fast learning.

The first night of building Track My Academy had the same energy. A MacBook Air, a second-hand iPhone, ChatGPT and VS Code. Mostly research, then a landing page I actually liked.

Why I was building it myself at all is its own saga. That's in the app that arrived from 2006.

How to evaluate AI coding assistants without fifty inboxes

Here's the version I'd hand to a student today.

Give every tool the same small, real task. Not "build me Instagram". Something like a form, a bug fix, or one API route.

Then check these things:

• Does it read your code? Some tools guess. Guessing is expensive.
• Does it explain itself? If you can't follow the change, you can't own it.
• Does it admit doubt? Confident nonsense is the worst kind of nonsense.
• What happens when it's wrong? Paste the error back and watch how it recovers.
• What does it cost after the trial? The free tier is the trailer, not the film.

The same survey has a lovely detail here. The top frustration, for 66%, was answers "almost right, but not quite".

Almost right is the danger zone. It's where a student copies, pastes, ships and cries. Fully wrong is easy to spot. Almost right walks straight into production wearing a fake moustache.

Photo: Vitaly Gariev on Unsplash

Prompting is just clear thinking

After enough trials, patterns start to show.

The biggest one: good prompts are just clear thinking. If I can't explain what I want, the AI can't either. Turns out, that's also true for humans.

Anthropic's own prompting best practices say roughly the same. They suggest treating Claude like a brilliant but new employee. Brilliant, yes. But missing all your context. Their golden rule: show your prompt to a colleague with minimal context. If the colleague would be confused, the model will be too.

That's not some secret AI trick. That's just writing a decent ticket.

Here's a simple prompt shape I'd suggest to any student:

1. What you're building, in one sentence.
2. What already exists: files, stack, the exact error.
3. What "done" looks like.
4. What it must not touch.

The last one saves more pain than the other three combined. AI tools love "helpfully" rewriting files you never mentioned.

What all those trials taught me

AI is a tool, not a teammate. It doesn't know your product. It doesn't care about your deadline. You still have to think.

Every tool has a personality. Some write great code and terrible explanations. Some explain beautifully and then write broken code. Knowing which is which saves hours.

The tool matters less than the person using it. A good developer with a basic tool beats a confused one with every tool.

Curiosity compounds. Later, I built a personal offline coding-agent experiment. Electron, React, Ollama and the Monaco editor. It was inspired by Claude Code and Bolt. The point was to explore the limits of contextual memory. You don't build that unless you've poked a lot of tools first.

If you're curious what the battle station looks like, see three monitors, one Monster can.

Photo: Jakub Żerdzicki on Unsplash

Free and student plans for AI tools: the legit route

Please don't take the email thing as a tutorial.

Read the terms of service of whatever you sign up for. If the terms say one trial per person, that means one. Respect them. Breaking the rules is not a growth hack.

The good news: students have proper options now.

GitHub's Student Developer Pack bundles tools and offers for students. Some offers are free while you're a student. Others are credits, discounts or time-limited trials.

GitHub's docs also say verified students get free access to Copilot's features. GitHub rechecks that eligibility every month. The Copilot plans page lists what each plan includes.

Offers change, though. Read the official page, not a random thread from two years ago.

My free advice, which is worth exactly what you paid:

• Start with official student programmes.
• Use free tiers honestly: one account per human.
• Ask your college whether it already has licences.
• Pay for one tool once it saves you real hours.

And please, don't pay for "training" dressed up as an internship. I've already made that mistake for you.

Learning by building beats learning by watching

Don't wait until you can afford the perfect setup. Start with whatever you can get your hands on. Learn by doing it badly first.

Pick one tiny project. Ship it to one real person. Let the AI help, but read every line it writes.

When it breaks, and it will, you'll learn more than any course. I wrote about the most expensive version of that in the night I broke production.

I did it badly for a long time. Now I do it slightly less badly. That's called progress.

The real reason: jugaad over spending

Here's the deeper truth. It wasn't only about money we didn't have. It's how I'm wired.

I value money a lot. I hate mindless spending. I save wherever I can.

If a service is available for free, I won't pay for it. Coupons, discounts, free trials, student offers. I look for all of them.

My rule is simple. If you can get it for free, why spend money on it?

In Hindi, we call this jugaad. Making scarce resources go further with creative improvisation. Jugaad takes time. But you always learn something while doing it.

For me, spending money felt more wrong than spending time. Time spent figuring things out turned into skills. Money spent on shortcuts would just have turned into receipts.

That's the real story behind dozens of email accounts. Not desperation. A habit of refusing to pay for what I could figure out myself.

FAQ

What's the best way of learning AI coding tools as a student?

Build one small, real project with one tool. Read every line it produces. Then give a second tool the same task and compare.

Are there free AI coding tools for students?

Some, yes. GitHub's docs say verified students get free access to Copilot's features. Check the official pages, because student offers change.

Should I make multiple email accounts for free trials?

No. Read the terms of service and respect them. Our trial hunt is a confession, not a strategy.

Sources

• Stack Overflow 2025 Developer Survey: AI
• Claude prompting best practices
• GitHub Student Developer Pack
• GitHub Docs: Copilot for students
• GitHub Docs: Copilot plans

What next

Want the origin story? Read how a coach's complaint became a company.

Run a sports academy? Have a look at Track My Academy. It's published by TrackMy Tech, where I'm Executive Director.

Student founder who wants to talk tools? Book a call.

People ask me how I balance college and a company. The honest answer? I don't. Nobody does. We just pretend better.

I'm a student founder. I'm doing a B.Tech in AI and Data Science. I'm also Executive Director of TrackMy Tech. And founder of Track My Academy.

That's a lot of hats for one head. This post is about how the hats stay on. Mostly, they don't.

Exam day, student founder edition

Here's how I write exams.

I write as fast as I can. Then I leave.

Not because I'm a genius. Because sitting in that exam hall feels like time stolen.

Every extra minute there is a minute not spent on everything else. The product. The team. The bug from last night.

So I finish, I hand it in, and I go back to the office.

The invigilator probably thinks I'm very confident. I'm not. I'm just in a hurry.

Photo: Nguyen Dang Hoang Nhu on Unsplash

I'm not recommending this method. Your examiner may prefer slower handwriting. I'm just telling you what happens.

The 1 a.m. gate

Some nights, I come home very late. How late? Late enough that my dad has to open the gate for me. At one in the morning.

Let that sink in. My dad. The gate. One in the morning.

I don't have a business metric for that. But it's the most important support system I have.

Photo: King Buwa on Unsplash

The question I get at home

My mother still asks one question. "Did you go to class?"

I'll leave my answer out of this. My mother might read this.

Balancing college and a startup: what it actually costs

Let's be real for a second.

Doing both isn't some cool hustle aesthetic. It's a trade-off. Every single day.

Sleep goes first. Always. Then free time. Then a lot of things your friends do that you don't.

I'm not complaining. I chose this. I'd choose it again.

But I won't pretend it's free. Anyone who says it's easy is selling a course.

The startup doesn't care about your timetable. Production breaks whenever it likes. Once, it broke for hours and I stayed in the office all night. That one gets its own post: the night I broke production.

College doesn't care about your startup either. The syllabus has not heard of product launches.

Photo: Tony Tran on Unsplash

Sleep, the first casualty

My desk tagline is "Three monitors. One Monster can. Zero hours of sleep." It's a joke. Mostly.

Here's the boring, grown-up bit. The CDC says adults need seven or more hours of sleep a night. It links enough sleep to mood, stress and fighting off illness.

I am not a doctor. I am barely a student. So I'm not giving you sleep advice.

I'm just admitting the tagline and the CDC disagree. The CDC is probably right. Annoyingly.

Photo: Mykyta Kravčenko on Unsplash

If you want the full monster-can tour, read three monitors, one monster can.

Time management for student entrepreneurs

I don't have a perfect system. But a few ideas keep me functional.

Accept that something will be messy. You can't be perfect at college and a company. Pick what matters most this week.

Sort by urgent and important. The Eisenhower method splits tasks into four boxes. Do the urgent, important things now. Schedule the important ones that can wait. Delegate or drop the rest. Most inboxes belong in "drop".

Give tasks a fixed box of time. That's called timeboxing. You decide the time first, then fit the work inside it.

It works because of Parkinson's law. Work expands to fill the time available. Give a bug the whole evening and it will take the whole evening.

Write it down where you can see it. A list you can see beats a list you remember. Sticky notes count. My desk has plenty of them. Whether I read them is another matter.

Protect one quiet block a day. Even an hour without notifications is gold. That's where the hard work happens. Everything else is admin.

Use small windows. A gap between classes is a small office. A quiet evening is a sprint.

Remember why you started. On bad nights, that's the only thing that works.

Support systems for a student founder

Nobody does this alone. Anyone who claims they did has forgotten somebody.

At home, it's a dad who opens the gate. And a mother who keeps asking about class. I count both as support.

At work, it's the team. When I'm stuck badly enough, it's Arun, our CTO. He's the one person I trust to pick up at any hour. That's a lot of trust to put in one phone.

If you're a student founder, find your Arun. Then respect his sleep. More than you respect your own, ideally.

Talking about it on stage

The funny part is that people now invite me to talk about this.

In March 2026, I was a guest speaker at VISTAS. The talk was called "Student Founder". It was about building a product from scratch and the realities of the SaaS market.

In September 2026, I ran a "Basic Python for Financial Analysis" workshop. That was for B.Com (Hons.) students at Ethiraj College for Women. The same month, I was chief guest at their AURORA '26 valedictory ceremony.

Chief guest. Me. The person whose mother still asks whether he went to class.

Should you start a startup while still in college?

I'm not going to tell you to drop out. That's not my call, and I haven't.

Paul Graham wrote A Student's Guide to Startups on exactly this. He also argues school is the best place to meet cofounders. And if you're not sure, he says you should wait.

My take is simpler. Start small. Solve a real problem. Mine started with a coach complaining about attendance.

And be careful who you pay to "teach" you. I learned that one the expensive way: I paid for an internship.

FAQ

How do student founders balance college and a startup?

Badly, and on purpose. Pick what matters this week, timebox the rest, and accept some mess. A support system helps more than any app.

What is the best time management method for student entrepreneurs?

There isn't one best method. Timeboxing and the Eisenhower method are a good start. The real trick is saying no to things.

Is it worth being a student founder?

For me, yes. It costs sleep, free time and some sanity. I'd still choose it again.

Technically still a student

I'm still technically a student. Emphasis on "technically".

One day I'll graduate. I'm even planning graduate study from Fall 2027.

And maybe, just maybe, the gate will close before 1 a.m. No promises.

Curious what all those late nights built? Have a look at Track My Academy. If you're a student founder and want to talk, book a call with me. Or read how I ended up here, starting with switching from bio-maths to computer science.

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.

Cover photo: Evan Marvell on Unsplash

On 8 and 9 October, I sat on the other side of the table.

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

I've been a hackathon participant. I've lost hackathons. I've won a couple too, which my about page mentions with suspicious frequency.

Now I've judged one. The personal story of that loop is in from hackathon loser to hackathon jury.

This post is the practical bit. How to win a hackathon, from someone who just spent two days scoring them.

What hackathon judges actually see

Here's the part nobody tells participants.

Your judge isn't seeing your project in isolation. They're seeing it as team number seven. Or team number fourteen.

Most teams in a judge's group share the same or similar problem statements. So the judge has already heard your problem explained. Several times. Usually in the same words.

Around the fifth team, focus starts slipping. Not because judges don't care. Because judges are human.

There's research on this, sort of. Decision fatigue describes decisions getting worse after a long run of them. The evidence for it is honestly mixed, so don't build a religion on it. But anyone who has judged fifteen pitches in a row will nod politely.

Running order matters too. A Carnegie Mellon study found later performers got higher marks. That was Eurovision and figure skating, not hackathons. You can't choose your slot anyway. So the only thing you control is how fast you earn the judge's attention.

Photo: Herlambang Tinasih Gusti on Unsplash

The first 30 seconds of your hackathon pitch

Start like a person, not a slide deck.

Give the judge a firm handshake. Ask them how their day is going. They'll appreciate it. It's probably been a long one.

Then introduce yourself and your team. Clearly. Confidently. Names, and who built what.

Then say three things, fast:

1. The problem statement you picked, in one line.
2. The scope you chose to tackle within it.
3. Your solution, in one sentence a tired person can repeat.

That's it. You now have the judge's attention, and you've spent maybe thirty seconds.

An elevator pitch usually runs thirty seconds to two minutes. Your opening should sit at the short end.

Show the prototype early

The demo is the hackathon. Everything else is decoration.

Plenty of hackathon rulebooks say this out loud. The UH CodeRED rules, for example, strongly encourage a demo. They say pitches and presentations are discouraged. They even say teams aren't judged on the quality of their pitch.

Not every hackathon works that way. But almost every judge prefers seeing a thing work to hearing about it.

So get to the prototype quickly. Show the main flow, end to end. One happy path that works beats five half-loaded features.

If something breaks, say so and move on. Judges have seen broken demos before. I've broken production, so I'm in no position to judge that part.

Photo: Shibraj Deb on Pexels

How to win a hackathon: stay on the problem statement

This one hurt to watch, because I used to do it.

Teams drift. They start on the given problem statement. Then they bolt on a chatbot, a dashboard and a dream. By the end, the judge can't find the original problem.

Your score is usually tied to the problem you were given. Solving a different, cooler problem rarely earns bonus points. It mostly earns confused faces.

Before you build anything, write the problem statement on a sticky note. Every feature must point back to it. If it doesn't, it waits for version two. I run my own life off sticky notes, as my desk setup post proves.

Don't over-engineer your hackathon project

The second classic mistake: building a cathedral in two days.

Microservices. Three databases. A custom login system nobody asked for. And a demo that loads forever.

Judges don't score your architecture diagram. They score what they can see working.

Pick the boring stack you already know. Build the smallest thing that proves your idea. Spend the saved hours polishing the one flow you'll demo.

When I started building Track My Academy, the first night ended with a landing page. Not an architecture. A landing page I actually liked. Small, finished things build momentum.

What the jury doesn't want to hear

Some things quietly drain your score.

• Facts the judge already knows. They've read the problem statement. Probably several times today.
• Statistics read off a slide. Especially ones an AI tool produced five minutes earlier.
• A tour of everything you made with AI. Use AI tools, absolutely. Just don't make them the pitch.
• Trying to impress instead of explain. Big words, no working product. Judges spot it instantly.

On AI: I'm a fan. I once chased free AI trials across dozens of email accounts. But the judge is scoring your thinking, not your prompt history.

Photo: Phil Hearing on Unsplash

A simple hackathon pitch structure

If you want a template, steal this one.

1. Hello (10 seconds). Handshake, how's your day, team intro.
2. Problem and scope (20 seconds). One line each. No essays.
3. Solution (15 seconds). One sentence, plain words.
4. Demo (most of your time). One flow, start to finish, working.
5. How you built it (30 seconds). Your stack, and one hard thing you solved.
6. What's next (10 seconds). One honest line. Then stop talking.

Then let the judge ask questions. Answer them directly. "I don't know yet" is a perfectly good answer. Making something up is not.

Hackathon tips for the questions round

Questions are where good teams pull ahead.

Listen to the whole question. Answer the question that was asked, not the one you rehearsed. Let the person who built that part answer it. Keep answers to a few sentences.

If a judge points out a flaw, agree if it's true. Then say how you'd fix it. That shows judgement, which is exactly what they're measuring.

FAQ

How do hackathon judges score projects?

It depends on the event, so read the rules first. Common criteria are technical difficulty, design, completion and impact. Most judges weigh what they see working more than what they hear.

How long should a hackathon pitch be?

As short as the rules allow. Aim for under a minute before the demo starts. Then let the working prototype do the talking.

Do you need a perfect product to win a hackathon?

No. You need one flow that clearly works and clearly fits the problem statement. Polish that, and be honest about the rest.

Go build something

If you're heading into a hackathon, good luck. Keep it short, keep it focused, and show the thing.

I build products at TrackMy Tech, and I'm always happy to talk shop. Book a call if you want a second opinion on your idea. Or read about the app that arrived from 2006, my favourite cautionary tale.

Cover photo: Vitaly Gariev on Unsplash

In my first year of college, I got an internship. At least, that's what I called it. I paid for it. Read that again. I paid for an internship.

This post is about paid internships for students. Specifically, which direction the money is supposed to flow. Spoiler: towards you.

It's also a list of internship red flags. I ignored all of them, so you don't have to.

What an internship is supposed to be

Let's start with the boring definition.

Wikipedia calls an internship a period of work experience with an organisation. It's for a limited time. It can be paid, unpaid, or partly paid through a stipend.

Notice what's missing from that list. "Intern pays the company" is not an option.

Real paid internships for students mean the company pays you. Sometimes it's a proper salary. Sometimes a modest stipend. Unpaid internships exist too, and they're a separate debate.

But a fee? That's a course.

The first-year brain

Let me explain my thinking at the time.

I was a first-year student. Everyone was talking about internships. Internships meant experience. Experience meant jobs.

Then someone reached out to me on WhatsApp. Then came a normal phone call. An internship, they said.

There was a fee, about ₹4,000. I assumed that's just how it worked.

It is not how it works.

The slow realisation

The title said Web Developer Intern. What actually happened looked a lot like a training programme.

Day to day, it was module-based learning. They gave you a module. You completed it and submitted it. Then you got the next one.

It was meant to last three months. I finished it in one. Even the organisers were pretty shocked. In hindsight, that was a clue. Real work doesn't arrive in tidy modules.

It took me months to see it clearly. Not because I'm slow. Okay, maybe a little slow.

Mostly because I wanted it to be real.

When you want something badly, you ignore the red flags. Even when they're waving at you.

Photo: Emil Kalibradov on Unsplash

Paid internships for students vs paid training courses

Here's the difference in a table, because I'm a product person now. This is the general pattern, not a review of any one company.

Training is not evil. Paying for learning is fine.

The problem is the label. A course sold as an internship sets the wrong expectations. It also looks a bit odd on your CV once you know better.

A useful test, borrowed from US labour law

The US Department of Labor has a neat way to think about this. Its Fact Sheet #71 describes a "primary beneficiary test". Courts use it to decide whether an unpaid intern is really an employee.

It's American law, so it decides nothing in India. But the questions are brilliant for any student, anywhere.

• Is everyone clear about whether there's pay?
• Is the training like what you'd get in education?
• Is it tied to your coursework or academic credit?
• Does it fit around your academic calendar?
• Does your work complement paid staff, rather than replace them?

My own add-on is simpler. If the company's only gain from you is your fee, you're a customer.

Not an intern. A customer.

Internship red flags for first-year students in India

First-year internships in India are a strange market. Everyone wants experience. Very few places want first-years. That gap is where the fee-charging stuff lives.

Some of it is honest training with a confusing name. Some of it is outright fraud.

In March 2026, IIT Roorkee warned students about unauthorised paid internship offers. Those offers claimed a link to the institute that didn't exist. IIT Bhubaneswar flagged a fake scheme misusing its summer internship name. Its advice: don't pay any fees, and don't share personal details.

So here are the red flags I'd watch for:

• A registration, training or "certificate" fee. The biggest one, by far.
• No named mentor. Just a "batch" and a group chat.
• Hundreds of "interns" at once. No real team can supervise that.
• Vague work. No project, no team, just "modules".
• Urgency. "Only three seats left" is a sales tactic, not hiring.
• The certificate is the main selling point. Real internships sell the work.

Now the good news. There's a free option run by the government.

The AICTE Internship Portal is an initiative of AICTE and the Ministry of Education. Its homepage says registration, applications and the completion certificate cost students ₹0. It also says anyone charging you to apply through it is running a scam.

That's the government telling you not to pay. Listen to it. First-year me could have used that memo.

Photo: Walls.io on Unsplash

My real internship checklist

Here's the checklist I wish someone had handed me in first year.

• Who pays whom? If money flows from you to them, it's training.
• What will you actually build? "Exposure" is not a deliverable.
• Who will you work with? Real teams, or a batch of fifty students?
• Will your work be used? Real internships ship real things.
• Can you talk to a past intern? Not a testimonial. An actual human.
• What's on the offer letter? Dates, role, stipend and a real company address.

If the answers are vague, walk away.

Learning is great. Paying for learning is fine. Just call it what it is.

If you really need to learn, pick a programme that openly says it's training. And don't tell people you got an internship. Be honest on your CV. Recruiters can usually tell anyway.

I'm still annoyed (at myself)

Not at them. At myself. I paid for a lesson I could've learned for free. The lesson is simple.

If you pay them, it's a course. If they pay you, it's a job.

That's it. That's the whole lesson. You're welcome. No fee required.

Was it a complete waste? No, and I won't pretend it was.

I learned some web basics. I learned how these programmes are sold. Most of all, I learned to ask better questions.

Expensive lessons stick. That's usually their only advantage.

Back then, I gave my first-year self one instruction. Fine, you've lost this money. Now find a way to get it back.

The plot twist: a 10x return

Here's the part I didn't see coming.

The best thing from that programme wasn't the modules. It was the person teaching me during it.

About a year later, they called me. They were freelancing by then. They had projects, and they needed someone to build them.

So we teamed up. They bring me projects. I get them done. They get paid a commission.

We've built a good bond since. From those projects, I've earned more than ₹40,000. On a ₹4,000 "internship", that's roughly a 10x return. First-year me would have been very confused, and slightly smug.

But please don't read this as advice. For most people, it doesn't end like this. My return came from a person, not from the programme. And I'd still steer clear of these "internships".

Building real projects taught me more

Funny thing. The real experience didn't come from that "internship". It came from building things myself.

An outsourced build of our app came back looking like 2006. So I built Track My Academy myself. The web app and the Android app are live. The iOS app is coming soon. It's now published by TrackMy Tech, where I'm Executive Director.

At CP Sports, I built the organisation's first official website. Then came Veeran, a tournament engine for organisers. Registrations, public and admin workflows, media management and AI photo features. It also ruined how I watch football.

I volunteered as a full stack developer for Paradox at IIT Madras. Hackathons counted too. Two ended with awards, which still surprises me.

None of that cost a registration fee.

It cost sleep instead. Some nights my dad opens the gate at 1 a.m. Once it cost a whole night, when I broke production.

Honestly, I'm still not sure which is more expensive.

Photo: Bernd Dittrich on Unsplash

If you're in first year, here's my honest advice. Skip the fee. Build one real thing that people use. Then apply for real paid internships with that project in hand. It's a far better CV line than a certificate.

FAQ

Are paid internships for students legit?

If the company pays you, usually yes. If you pay the company, it's a training course with a nicer name. Check which way the money flows before anything else.

How do first-year students in India find real internships?

Start with your college placement cell and the AICTE Internship Portal. Both are free. Build one solid project first, so you have something to show.

Is it ever okay to pay for training?

Absolutely. Good courses are useful. Just know you're buying a course, not an internship. List it under courses on your CV, not experience.

What to do next

Switching streams too? Read how I went from bio-maths to computer science. Want to see what building looks like? Have a look at Track My Academy.

Or book a call and ask me anything about internships. No registration fee. Obviously.

Cover photo: Terry Vlisidis on Unsplash

Some projects start with a pitch deck. This one started with a sentence. "Sure, I'll help."

That sentence is how I ended up working on molecular docking software. Yes, really. The guy who builds a sports academy app now has opinions about proteins.

This post is about BioPipeline, plant molecular docking as a SaaS. It's also about what molecular docking actually is, in words a human can read. And about the most dangerous phrase in my vocabulary.

The favour that became a job title

It starts with Bharat. He was my senior, studying biotechnology. We met at a college cultural event back in 2024. He turned into a good friend, and we started working together.

At some point, he was running a startup. I had no idea what it actually did. I was busy, he was busy, life happened.

Then he finished his bachelor's and went abroad for his master's. He'd sold that earlier startup to someone else. The plan, he said, was to focus on his studies.

That plan lasted until one random night. My phone rang. It was Bharat.

"I'm going to start this again. You're going to help me out." Then he explained the idea. Then he said, "Just start."

That was the whole negotiation. No equity talk. No five-year plan. If you know me, you know "I'll help" is dangerous. I never help a little.

There was one small problem. I had absolutely no idea how biomolecular anything worked. None. Zero.

So I did what I always do. I learned it by touching it until it made sense. Then I started building.

Then it worked better than we expected

No big meeting. No breakthrough montage with inspiring music. I just stayed involved.

At some point, the software started working much better than we'd expected. And people wanted it far more than we'd planned for. That's a good problem, but it's still a problem.

Today my title is AI and Product Development Lead at BioPipeline. That started in March 2026. And we still don't have a formal agreement. No contracts, no fancy paperwork, just two friends building a thing.

Not bad for a favour. The rest, as they say, is history.

What is molecular docking, in plain words?

Here's the version I wish someone had given me on day one.

Your body runs on proteins. Lots of medicines work by sticking to a specific protein and changing what it does. So a big question in drug discovery is simple. Will this small molecule stick to that protein? And if it does, how exactly does it sit there?

Molecular docking answers that question on a computer. It predicts how one molecule fits onto another, and how well.

The classic picture is a lock and a key. Wikipedia points out that's a bit too rigid, since both molecules can flex. It says a "hand-in-glove" picture fits better. I like that, because gloves are less stressful than locks.

Photo: niranjan borah on Unsplash

How molecular docking software actually works

Every docking tool has two jobs. First, it searches. It tries lots of positions and shapes for the molecule inside the protein. A 2011 review by Meng and colleagues calls this step sampling.

Second, it scores. A scoring function ranks each pose by how likely it is to bind. Lower energy usually means a more stable fit.

That's the whole trick. Search, then score, then hand a scientist a ranked list. Simple to say. Very much not simple to build.

The same review is honest about the weak spot. Scoring functions estimate binding affinity rather than calculate it exactly. Pinzi and Rastelli make a similar point. Their review says approximate scores often don't match lab measurements.

So why does anyone bother? Because it's quick and cheap compared to the lab. A 2024 review in the Annual Review of Biochemistry puts it nicely. Docking is "far from perfect", yet it "has led to important discoveries". It is less accurate than experiments, but "far faster and cheaper."

That's a trade-off I respect. It's basically how I approach code too.

Plant molecular docking and where BioPipeline fits

Plants are full of interesting compounds. Plant molecular docking asks which of them might bind to a target protein. That's the space BioPipeline works in. We built it from scratch with the founding team. The stack is Next.js, TypeScript and Supabase.

The product covers the core docking workflow end to end. You upload or select compounds. You run docking. You get molecular interaction outputs. Then you look at the results.

Written like that, it sounds like four buttons. It is four buttons. Getting those four buttons to feel obvious is the actual job.

Photo: Julia Koblitz on Unsplash

Turning a scientific tool into a product

Good docking engines already exist. AutoDock Vina, for example, is open source under a permissive Apache licence. Protein structures are shared too. The RCSB Protein Data Bank gives out 3D structure data at no charge.

So the science isn't locked away. The gap, in my opinion, is everything around the science. Files. Formats. Waiting. Remembering which run was which. That's product work, not chemistry. And product work is the bit I actually know.

Here's what I think matters when a scientific tool becomes a bioinformatics SaaS.

The workflow is the product. Researchers don't buy an algorithm. They want a path from "I have compounds" to "I have answers".

Results need to be readable. A ranked list is useful. A ranked list you can understand at a glance is better.

Don't hide the science. Scientists want to know what ran and why. A black box is a fast way to lose their trust.

Build boring things properly. Uploads, storage and logins aren't exciting. They're also where most users quit.

None of this is unique to biology. It's the same lesson from building Track My Academy for coaches. Find the annoying part. Make it less annoying. Repeat.

The bio-maths student comes back

Remember how I was a bio-maths student in class 12? Then I switched to computer science. Best decision I've ever taken, I guess.

That looked like the end of biology and me. Turns out biology wasn't done with me. It just waited for me to learn to code first.

Bioinformatics is literally that overlap. Wikipedia calls it a field that develops computational methods and software tools for biology.

So the subject I left came back as a product I build. I find that very funny. My twelfth-grade self would find it suspicious.

Saying yes to side projects without losing your mind

My plate was already full. TrackMy Tech work like Veeran, Track My Academy, CP Sports, and somehow college. You can read about exams, the office and the 1 a.m. gate separately.

So adding BioPipeline wasn't exactly sensible. But I think saying yes was right.

Here's my honest advice, for whatever it's worth.

Say yes to people, not just ideas. I said yes because I trusted the person. The idea came along for the ride.

Small yeses grow up. "I'll help" can turn into a role. Be ready for that.

Learn the domain, not just the code. I had to understand the science, at least a bit. Code without context is just typing.

Stay longer than feels reasonable. Starting is exciting. Staying is showing up when nobody's watching. Most good things grow in the boring part.

I didn't do anything heroic on BioPipeline. I just didn't leave. That turns out to be a surprisingly rare skill.

Photo: Bernd Dittrich on Unsplash

Even that terminal is asking for a yes. It's a pattern now.

FAQ

What is molecular docking software used for?

It predicts how a small molecule binds to a protein. Researchers use it to shortlist compounds before expensive lab work. Think of it as a very nerdy filter.

Is molecular docking accurate?

Not perfectly, and the researchers say so themselves. Scoring is an estimate, not a measurement. It's fast and cheap, so it's used to narrow down options, not replace experiments.

What does BioPipeline do?

BioPipeline is a SaaS for plant molecular docking. You upload or select compounds and run docking. Then you review molecular interaction outputs and results.

The moral of the story

Be careful who you offer to help. You might end up with a new job title. And a lot more browser tabs about molecules. If you work in plant research, go and try BioPipeline.

If you'd rather talk products, startups or docking, book a call with me. Or read how the first Track My Academy build arrived from 2006.

We are gathered here today to remember smart ball v1.

It was a football. It had smart football sensors inside. It never shipped.

Rest in peace, little guy. This is the eulogy, and also a beginner's guide to why hardware is hard. If you have ever wanted to stuff electronics into a football, read this first.

It will save you some wires. Possibly some eyebrows.

The idea: a football that knows it was kicked

I love football. I love building things. I was also fascinated by how adidas built its smart ball. It was extremely expensive. And as far as I could find, you couldn't just buy one.

Then the chance actually showed up. While I was working with CP Sports, we had a tie-up with an agency. That agency worked with a well-known sporting goods manufacturer in north India. They had a good contact with a senior executive there.

In one discussion, they asked us a question. "Can you build something that tracks player data like the adidas smart ball?" "But cheaper?" We didn't even flinch. "Yes, of course."

They asked for a structural design within a week. They'd help us pitch it to the company. There was talk of hefty funding. I genuinely thought my life was settled.

A low-cost football with sensors inside. Something that could tell you about every touch. How hard could it be?

Very. The answer is very.

This was not a weekend hack, either. Smart Football R&D ran from December 2024 to December 2025. A full year of my life, inside a ball.

It ran alongside Track My Academy, which I was building at the same time. That one started because a coach complained about attendance. So yes, two big projects at once. One of them was round.

Prototype zero: maida, boba straws and a pickleball

We had one week to show a structure. We were second-year students. We had no 3D printer. We didn't even really know how 3D printing worked.

So I improvised. The model just had to show the structure, in any shape or size. I made a clay-like dough out of maida, plain flour. I pushed it into boba straws to build the structure. I used a pickleball as the core and stuck cones on it.

Yes, our very first smart ball prototype was partly made of flour. We presented it anyway. Everything went perfectly. Hold that thought.

What was inside smart ball v1

Look at the photo above.

That's an open football shell. Inside, there are piezo sensors around the edges. In the middle, a breadboard covered in wires.

Lots of wires. More wires than any football should legally contain.

Piezo sensors turn pressure into a small electrical signal. Kick the ball, the sensor reacts. At least, that's the theory.

Theory and breadboards are not always on speaking terms.

Photo: Vishnu Mohanan on Unsplash

A breadboard is brilliant for prototyping. You push wires in, no soldering needed, and you can reuse it.

Wikipedia also politely notes its connections are "subject to jostle".

Jostle. In a football. The object whose entire job is being kicked.

You can see where this is going.

The year in one list

People imagine hardware R&D as one big "eureka". It's more like a long list of small "oh no".

Here is what that year actually covered:

• Sensor selection. Which sensor, how many, and what it should even measure.
• Component placement. Where everything sits inside a sphere that gets booted.
• Ball balance. Add weight on one side and the ball stops rolling straight.
• Bladder and pressure research. The air inside changes how everything behaves.
• Prototype testing. Kick it, check it, fix it, repeat.
• App dashboard concepts. What a player or coach would actually see afterwards.

Every item on that list could be its own engineering degree. I had a breadboard and optimism.

Ball balance was the sneaky one. In software, a heavy function makes things slow. In a football, a heavy component makes it wobble. Nobody wants a ball that curves because of your circuit.

Our first PCB, made in Coimbatore

The breadboard could only take us so far. So we designed our own custom PCB, a printed circuit board. We went to a professional PCB printing place in Coimbatore. We spent two full days there.

We came back with our first PCB. We connected it to our own sensors. And it worked.

I can't fully explain that feeling. The sensors responding, with everything connected inside the ball. You could see the joy in our eyes. That moment taught us more about IoT devices than any course.

IMU vs piezo sensors: two ways to make a ball feel things

There are two common ways to give a ball a sense of touch.

Piezo sensors react to pressure and impact. They are cheap, simple and good at noticing a sudden hit. The catch: they cannot do truly static measurements. They notice the kick, not the gentle story after it.

An IMU is an inertial measurement unit. It combines accelerometers, gyroscopes and sometimes magnetometers. It measures how the object moves and rotates.

The catch there is drift. Tiny measurement errors pile up over time. The device slowly loses track of where it really is.

So, roughly:

My opinion: piezo is the friendly place to start. An IMU is where the serious connected ball technology lives.

Meanwhile, the professionals

While I was fighting wires, real sports tech was doing real things.

At the 2022 World Cup, the match ball had an IMU sensor in its centre. According to FIFA, it sent data 500 times per second. That helped detect the exact moment a ball was kicked, for offside calls.

adidas says a suspension system held that sensor steady at the centre. It ran on a rechargeable battery, charged by induction.

Read that again. They suspended a sensor in the middle of a ball. That is the ball balance problem, solved properly.

500 times per second. My prototype struggled to report once without a wire falling off.

Humbling? Yes.

Inspiring? Also yes.

Photo: Jason Mayer on Unsplash

The real engineer: Jitendra

Let me give credit where it's due. A huge shout-out to Jitendra.

He was my junior, and I met him in my second year. Geeky, nerdy, and with an immense knowledge of IoT and gadgets. He built about 70% of the IoT systems that made the ball work. He also wrote the code for it.

My part was product design. I told him how I wanted it to work. He made it work. That's a very good deal for me.

I learned to solder (soldering safety first)

Soldering was the painful part for me. Before this project, I had never soldered anything.

Complete beginner. Absolute zero.

The smart ball got me soldering. I look like a scientist. I solder like a nervous chef.

But I learned. Slowly.

If you're a beginner too, here's the bit to take seriously.

A soldering iron runs roughly between 200 and 480 °C. That is not a "quick touch to check" temperature. Hold it by the handle and put it back in its stand.

The fumes matter too. The UK's Health and Safety Executive is blunt about it. Rosin solder flux fume can cause asthma and dermatitis. Their advice is simple: keep your face out of the fume and use extraction.

So my beginner soldering safety list:

• Safety glasses on, every time.
• Ventilation or a fume extractor.
• Iron goes back in the stand.
• Wash your hands after handling solder.
• Never assume the tip has cooled down.

Photo: Blaz Erzetic on Unsplash

Why hardware is hard (and why v1 never shipped)

Hardware is hard. Everyone says it. Now I get it.

With software, a mistake costs you a deploy. With hardware, a mistake costs you a ball.

Software also forgives you faster. When I broke production for hours, at least nothing physical died. You can't hotfix a solder joint over Wi-Fi.

Hardware also costs money at every single step. Parts, more parts, replacement parts for the parts you fried.

Now, the plot twist I promised. That hefty funding? It never came. It was promised. It just never arrived.

We spent more than a year on R&D with basically no outside money. We still put more than ₹1 lakh of our own into the ball. Eventually, we had to stop. We put the project aside, as a memory.

No dramatic explosion. Just a deal that never landed, and a very sensible spreadsheet.

Smart ball v1 was never finished. But it was never meant to be the final version.

That's what v1 is for.

Hardware prototyping for beginners: what I'd tell you

Building teaches you what reading can't. I understood sensors only after I wired one wrong. I learn by doing things badly first. Same energy as rebuilding the app that looked like 2006.

Start on a breadboard, finish on solder. Breadboards are for finding out. Solder is for when you've found out.

Think about where the thing lives. A circuit on a desk is easy. A circuit inside a ball gets kicked, squashed and rained on.

Prototypes are allowed to die. Their job is to teach you, not to survive.

Respect hardware people. Anyone who ships a physical product is a wizard. I'm still at the "please don't short-circuit" stage.

FAQ

What sensors are used in smart footballs?

Mostly IMUs, which track motion and spin. The 2022 World Cup ball used one sampling 500 times per second. Piezo sensors are a cheaper way to detect impacts, which is where I started.

Is a smart football hard to build as a beginner?

A basic "did it get kicked" prototype is doable. A balanced, durable ball that survives real matches is properly hard. Budget for broken parts and broken pride.

Is soldering safe for beginners?

It can be, with basic care. Wear eye protection, keep your face out of the fume and use ventilation. Treat the iron like it's always hot, because it usually is.

The funeral is over

Smart ball v1 lives on in my heart. We still have the prototype. We still have the design files.

I still think about the idea. I still watch football and think about sensors. Building Veeran made that worse, as I explain in this post.

If we get funding, we'll restart from exactly where we left off. V2 might happen someday. Sports tech is the whole point of TrackMy Tech, so never say never.

Until then, I'll keep the safety glasses close.

Building something in sports tech, hardware or software? Book a call with me and we can compare scars.

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:

1. Who it's for. "A coach with one batch" beats "sports organisations".
2. The one painful job. For us, that was attendance and payments.
3. Three apps you like the look of. Screenshots, not adjectives.
4. What "done" means. Which screens, which actions, which devices.
5. What you won't build yet. This list saves more money than any discount.
6. 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.

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.

1. Check the boring stuff first. SSL certificates, DNS, environment variables. Then blame the code.
2. Know when every certificate expires. Write the dates down before you touch anything.
3. Change one big thing at a time. Two changes, one failure, endless guessing.
4. Deploy when people are awake. Ideally the people who can fix it.
5. Know your way back. Before you ship, not after.
6. 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

• Google SRE book: Introduction
• Google SRE book: Monitoring distributed systems
• Google SRE book: Postmortem culture
• Atlassian: Incident postmortems
• Martin Fowler: Blue-green deployment
• Wikipedia: Public key certificate
• Let's Encrypt FAQ

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.

My website says it right at the top. Three monitors. One Monster can. Zero hours of sleep. People think it's a joke.

It's not a joke. It's a description.

So here's a proper tour of my developer desk setup. What's on it, what actually helps, and what's just a bad habit with good lighting. I've also looked up what the research says. Because "trust me" is not a source.

My developer desk setup, in one sentence

Three monitors, sticky notes, AI coding tools and an alarming number of cans.

That's it. No standing desk. No mechanical keyboard review. No mood lighting sponsored by anyone.

It's the same desk you'll find on my home page. Tidier in the photo than in real life, probably.

Three monitors, and what the research says

Yes, three. Do I need three monitors? Need is a strong word.

One for code. One for the app I'm breaking. One for everything else that's on fire.

Once you get used to three, two feels like a punishment. One feels like a crime.

Photo: Abu Saeid on Unsplash

Is multi-monitor productivity real, or just a nice excuse? There's some actual research.

A University of Utah study reported by Computerworld timed people doing editing tasks. Two 20-inch screens beat a single 18-inch screen by 44% on text editing. On spreadsheet work, the gain was 29%.

Two honest caveats. The study was paid for by NEC, a company that sells monitors. Surprise, the monitor company liked monitors.

The other caveat is more interesting. Gains levelled off as screens got bigger. On the largest screen, spreadsheet performance actually dropped. The researcher blamed time spent managing windows.

That matches my theory completely. More screen helps until you start losing things on it. I'm at three. I'm not going to four. Probably.

Sticky notes: the cheapest task system that works

My most important productivity tool costs almost nothing. Sticky notes.

Ideas. Bugs. Things I promised someone. Things I'll definitely forget by tomorrow.

Photo: Paymo on Unsplash

If you want the grown-up version, it's called a kanban board. Work moves through columns as it progresses. The simplest version has three: to-do, doing, done.

Here's how I'd set up a simple task system with sticky notes:

1. One task per note. If it needs two notes, it's two tasks.
2. Write the verb first. "Fix login bug", not "login stuff".
3. Three columns, max. To-do, doing, done. Nothing fancier.
4. Limit "doing". Three notes, tops. Same rule as the monitors.
5. Bin the done notes. Throwing them away is the best part.

Sticky notes have one flaw. Past you writes them. Past you has terrible handwriting and zero context.

AI coding tools on the screens

It started small. A MacBook Air, VS Code and ChatGPT.

That was the first night of building Track My Academy. I wrote about it in the app that arrived from 2006.

Then we went a bit feral. We chased every free AI trial we could find, across dozens of email accounts. The full confession is in dozens of email accounts and zero shame.

Back then we didn't know how to use Claude or Codex properly. That took a while. Here's the short version of what these tools are:

• VS Code calls itself "the open source AI code editor". It was there on night one.
• Claude Code is an agentic coding tool that reads your codebase and edits files.
• It runs in the terminal, IDEs, a desktop app and the browser.
• Codex CLI is OpenAI's coding agent that runs locally on your computer.

They write code quickly. I still decide what's right.

That's the deal. AI is very fast help, not a replacement for knowing what you want. Bugs still have my name on them, AI or not. I learned ownership the hard way in the night I broke production.

The offline coding agent experiment

Using these tools made me curious about building one.

So I built a personal offline coding agent, as an experiment. It was inspired by Claude Code and Bolt. The stack was Electron, React, Ollama and the Monaco editor.

Ollama lets you run open models on your own machine. The Monaco Editor is the code editor from VS Code, packaged for the browser.

The goal was to explore contextual memory limits. In plain English: how much can a local model remember before it gets confused? A fair question for a model. An unfair one for me at 3 a.m.

The Monster cans

Let's address the can in the room.

There are a lot of Monster cans. Enough to make a wall. You can see it in the photo above.

At the office, they went one step further. There's a chandelier made of Monster cans. I'm not proud of it. Okay, I'm a little proud of it.

That's it above my head. Yes, it looks like a rifle. No, I can't explain the design process.

Is this healthy? No. Am I going to pretend I drink green tea? Also no.

Photo: Amr Taha on Unsplash

I'm not a doctor, so I'll just point at people who know. The US FDA says about 400 mg a day is generally fine for healthy adults. It also says energy drinks vary a lot in caffeine. Read the label before you trust the can.

The Sleep Foundation on caffeine and sleep is blunter. Its usual advice is no caffeine for at least eight hours before bed. Caffeine's half-life can be anywhere from two to twelve hours. So that evening can is still at your desk at midnight. Even after you've thrown it away.

Kids, please drink water.

Zero hours of sleep

This one is a slight exaggeration. Slight.

Between college, the company and everything else, sleep loses. It always loses. It never wins a single argument. The exam-season version of this is in exams, the office and a 1 a.m. gate.

For the record, the Sleep Foundation says adults need at least seven hours. I'm telling you how it is for me, not how it should be. Please copy the Sleep Foundation, not me.

What actually matters in a developer desk setup

Here's my unpopular opinion.

Your setup doesn't make you productive. Your problem does.

I built my first landing page on a MacBook Air. No second monitor. No fancy chair.

The monitors came later. The Monster cans came, unfortunately, immediately.

If you're building a desk from scratch, here's my order:

1. A decent editor and an AI coding tool. Both have free starting points.
2. A second screen. The research backs this one, with a vendor-shaped asterisk.
3. A sticky-note system. Cheap, physical, impossible to close by accident.
4. A third screen. Only if two genuinely slows you down.
5. Sleep. I've put it last because that's where I put it. Don't.

Start with what you have. Upgrade when the setup is actually slowing you down.

FAQ

Are three monitors better than two for programming?

Two screens clearly help, according to the University of Utah study. Beyond that, gains flatten and window juggling creeps in. Three works for me because each screen has one job. If you can't name the third screen's job, skip it.

What AI coding tools do developers use in 2026?

The big names are Claude Code, Codex and the AI features in VS Code. They all read code, write code and run commands to different degrees. Try a couple on a real project, not a demo. Then keep the one you actually reach for.

How much caffeine is too much for late-night coding?

I'm the wrong person to ask, as the cans prove. The FDA's general figure for healthy adults is about 400 mg a day. The Sleep Foundation suggests stopping eight hours before bed. If you have any health questions, ask a doctor, not a blog.

Come and see it in use

I build for TrackMy Tech, the sports-tech company I help run. Its main product is Track My Academy, a sports academy management app.

Want to talk tools, setups or startups? Book a call with me. I'll be at the desk. Obviously.

That's me up there, in the number 8 jersey. Eight is my lucky number. Obviously.

I used to watch football like a normal person.

Ball goes in. I celebrate.

Ball doesn't go in. I complain.

Simple. Healthy. Normal.

Then I worked on Veeran, a piece of football tournament management software. Now I'm not normal anymore.

This post is about two things. What it takes to organise football tournaments without losing your mind. And how building software for them broke the way I watch the game.

What is football tournament management software?

Think about everything a tournament needs before a ball is kicked.

Teams have to register. Someone has to check those registrations. Players, parents and fans want to see what's happening. Organisers need a back office that isn't a notebook.

Then the match day happens. Hundreds of photos appear from nowhere. Everyone wants theirs.

Football tournament management software pulls all of that into one place. The alternative is five WhatsApp groups. And one very stressed organiser.

Sounds like admin software, right?

It is. But it did something weird to my brain.

What Veeran actually does

Veeran is a tournament engine for organisers. I built it at TrackMy Tech.

Here's what it covers:

• Registrations. Teams sign up properly, not via a blurry screenshot.
• Public workflows. What players, families and fans see.
• Admin workflows. What organisers use behind the scenes.
• Media management. Somewhere for all those match photos to live.
• AI photo features. Because nobody wants to scroll through hundreds of pictures.

Under the hood, it's Next.js, React, Supabase, AWS S3 and MongoDB.

Notice what's not on that list. This version is about the organiser's workload, not flashy extras. I'd rather do five things properly than fifteen things badly.

Photo: Maryam Tello on Unsplash

Organising football tournaments: the maths nobody warns you about

Tournament formats look simple on a poster. Then you do the maths.

In a round-robin tournament, every team plays every other team. The number of games is n(n − 1) ÷ 2.

Eight teams? That's 28 matches.

Sixteen teams? That's 120 matches. Good luck finding the pitches.

A single-elimination tournament is kinder to your calendar. Lose once and you're out. Brutal for teams, lovely for scheduling.

Most local tournaments mix the two. Groups first, knockouts after.

The format is only half of it. Every match needs teams who registered correctly in the first place. That's why I think registrations are the real foundation.

Tournament registrations: where the chaos starts

Bad registration data haunts you all tournament.

Wrong team names. Missing players. Two teams claiming the same kit colour.

My advice for anyone organising football tournaments:

• Collect everything once. Team name, contact, squad list, age group.
• Set a hard deadline. Then actually stick to it.
• Separate public and admin views. Fans don't need the organiser's notes.
• Plan for media early. Photos arrive faster than you think.

None of this is glamorous. All of it decides whether match day is calm or a disaster.

How I watch football now: like a data person

When you build software around matches, you start seeing matches as data. I don't just watch the ball anymore.

I watch its trajectory. How it changes after each touch. How the players react to it.

A simple pass becomes a story. Where did it start? What changed it? Who reacted first?

Most people want to enjoy the game. I want to pause it and draw arrows.

If you've ever watched a match with me, I apologise.

Photo: Jannes Glas on Unsplash

Football analytics and ball tracking: the grown-up version

The professionals have taken this obsession much further.

For the 2022 World Cup, FIFA's semi-automated offside technology used 12 tracking cameras. They tracked up to 29 data points on each player. That happened 50 times per second.

The ball had its own sensor too. It sent data 500 times per second.

I tried something similar on a much smaller budget. It's in the eulogy for smart ball v1. Spoiler: it's a eulogy.

Then there's expected goals, or xG. It gives every shot a probability of becoming a goal. It looks at things like distance, angle and body part.

So when a striker misses a sitter, there's now a number for your disappointment.

Even the curve of a shot has a name. The Magnus effect is why a spinning ball bends. Roberto Carlos's famous "banana kick" is the poster child.

Knowing all this does not make me better at football. It just makes me slower to celebrate.

Eleven variables, ninety minutes, no undo

I've played football my whole life. I still play. I'm still physically incapable of accepting a draw.

But building for football showed me something new.

The game is a beautiful mess of decisions. Eleven people per side. Ninety minutes. Zero undo buttons.

Every touch changes everything after it.

That's exactly how software feels on a bad day. Ask me about the night I broke production.

What building sports software taught me

Organisers need reliable, not fancy. On match day, nobody cares about animations. They care that the information is right.

Admin work is the real product. Fans see the public pages. Organisers live in the admin side. If that part is painful, the whole thing is painful.

Football people are honest users. If something annoys them, you'll hear about it. Loudly. Usually with hand gestures.

This isn't new to me. Track My Academy exists because a coach complained. Football people complaining is basically my product roadmap.

Photo: My Profit Tutor on Unsplash

How to choose football tournament management software

If you're an organiser shopping around, here's my checklist.

• Registrations that don't need chasing. This is where most of your time goes.
• Clear public pages. Players and families should find answers without calling you.
• A proper admin side. You should never need a spreadsheet on the side.
• Media handling. Photos are half the fun of a local tournament.
• Honest feature lists. If it says it does something, check it really does.

That last one matters. Pick the tool that does what you need properly. Ignore the one with the longest brochure.

FAQ

What does football tournament management software do?

It handles the admin around a tournament. Think registrations, public information for fans and an organiser back office. Some tools, like Veeran, also handle match media and photos.

How many matches are in a round-robin football tournament?

Multiply the number of teams by one less than that number. Then halve it. Eight teams play 28 matches, which is why most tournaments use groups.

Does football analytics make watching football less fun?

For me, it made it different, not worse. I still feel the rush when the ball goes in. I just also want to know how it got there.

So, is football ruined?

Not ruined. Upgraded.

I still feel the same rush when the ball goes in. I just also want to know its exact path. And whether the tournament software did its job.

If you organise tournaments, have a look at Veeran. If you run an academy, Track My Academy is the one for you. That one is published by TrackMy Tech, my sports-tech company.

Want to talk football, software or both? Book a call. I promise not to draw arrows on your screen.