DEV Community: Rahul Dhileep Kumar

My developer desk setup: three monitors, one Monster can

Rahul Dhileep Kumar — Wed, 04 Nov 2026 04:30:00 +0000

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:

One task per note. If it needs two notes, it's two tasks.
Write the verb first. "Fix login bug", not "login stuff".
Three columns, max. To-do, doing, done. Nothing fancier.
Limit "doing". Three notes, tops. Same rule as the monitors.
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:

A decent editor and an AI coding tool. Both have free starting points.
A second screen. The research backs this one, with a vendor-shaped asterisk.
A sticky-note system. Cheap, physical, impossible to close by accident.
A third screen. Only if two genuinely slows you down.
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.

Dozens of email accounts: learning AI coding tools as a student

Rahul Dhileep Kumar — Wed, 28 Oct 2026 04:30:00 +0000

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:

What you're building, in one sentence.
What already exists: files, stack, the exact error.
What "done" looks like.
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

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.

How I built a DSC PDF signer in Rust and Tauri

Rahul Dhileep Kumar — Sat, 24 Oct 2026 16:54:22 +0000

I'm a company director, and in India that means signing board resolutions and financial statements with a Digital Signature Certificate (DSC). The DSC is a Class 3 certificate on a USB token, the same one used for MCA and GST filings.

For a while, signing a PDF with that token meant paying for and installing a large commercial PDF suite. A lot of software for one click and a PIN. I wanted something small, free and offline that would never break a signature already on the PDF.

So I built TrackMy Sign, a free, open-source (MIT) desktop app for Windows, macOS and Linux. This post is about how it works underneath. The code is at github.com/rahuldk1105/trackmysign.

The stack

Rust for everything that matters: talking to the token, parsing PDFs, building signatures.
Tauri 2 for the desktop shell, so the app ships as a native binary with a webview rather than a bundled browser.
React for the interface.

The interesting parts are all on the Rust side, so that's where the rest of this goes.

Part 1: talking to the token with PKCS#11

An Indian DSC token is a smart card in a USB stick. The private key is generated on it and can't be exported. You never get the key; you ask the token to sign something with it.

The standard way to ask is PKCS#11, a C API that token vendors implement in a driver library: a .dll on Windows, a .dylib on macOS, a .so on Linux. Every vendor ships its own. The flow is the same for all of them:

Load the vendor's library and call C_Initialize.
Find a slot with a token in it and open a session.
C_Login with the user's PIN.
Find the certificate object and the private key that matches it.
Call C_Sign with that key over the data to be signed.

Steps 3 and 5 are the ones that matter for security. The PIN goes to the token's driver, and the signing happens on the token. The private key never leaves it. TrackMy Sign doesn't store the PIN.

The awkward part is step 1. There's no standard place for the driver. Each vendor installs its library somewhere different, under a different name, on each platform. So the app keeps a list of known driver locations for common Indian tokens (HyperPKI, ePass2003, ProxKey, mToken, SafeNet and others), loads every one it finds, and lists the certificates from all of them together. A driver that fails to load is skipped rather than taking the app down with it. You can also point it at a driver in an odd location.

Part 2: what a PDF signature actually is

A PDF signature is a CMS (PKCS#7) SignedData structure stored inside the PDF. TrackMy Sign uses the standard adbe.pkcs7.detached sub-filter with SHA-256. "Detached" means the CMS blob doesn't contain the content it signs; it contains a hash of it, the signer's certificate chain, and the signature over those signed attributes.

The question is: which content? The answer is the ByteRange.

When you add a signature, you add a signature dictionary to the PDF. It has a /Contents entry, which is a hex string reserved for the CMS blob, and a /ByteRange entry, which is four numbers:

/ByteRange [0 840 960 240]
/Contents <000000...000000>

That reads as: "this signature covers bytes 0 to 840, and bytes 960 to 1200". The gap in the middle is exactly the /Contents hex string. The signature covers the whole file except the hole where the signature itself goes.

So signing is roughly:

Write the new PDF content with a /Contents placeholder big enough for the signature, filled with zeros.
Work out the byte offsets and write the real /ByteRange numbers.
Hash the bytes in the two ranges with SHA-256.
Build the signed attributes, and send them to the token via C_Sign.
Assemble the CMS SignedData with the certificate chain, hex-encode it, and write it into the placeholder.

Nothing outside the placeholder changes after step 3. If it did, the hash would no longer match.

Part 3: incremental updates, and why the auditor's signature survives

This was the requirement I cared most about. Financial statements can arrive already signed by an auditor. If they signed before you, your signature has to go on without breaking theirs.

Look at what the auditor's ByteRange covers: specific bytes of the file as it was when they signed. If any of those bytes move or change, their signature is invalid. A tool that loads a PDF into an object model, adds a signature and serialises the whole thing again will shift offsets, renumber or recompress objects, and break the auditor's signature.

PDF has a mechanism for this, called an incremental update. You don't rewrite anything. You append to the end of the file:

the new and changed objects (the signature dictionary, the signature field, its visible appearance, the updated page and form objects);
a new cross-reference section listing where those objects are;
a new trailer whose /Prev points back to the previous cross-reference section.

A reader follows the chain from the newest trailer backwards and sees the latest version of each object. The original bytes are still there, byte for byte. The auditor's ByteRange still covers exactly what it covered before, and those bytes are untouched. Their signature stays valid. Yours covers the whole file including their signature, which is what you want.

TrackMy Sign has its own PDF parser and incremental writer, written in Rust. The writer only ever appends. It never rewrites the original bytes.

The same mechanism handles the other features that touch a signed file: signing into an existing empty signature field in a bank or government form, putting one signature's visible box on every page, and certifying (locking) a document.

Part 4: testing without a physical token

You can't run CI against my USB token, so the tests use SoftHSM, a software implementation of a PKCS#11 token. To the app it looks like any other token driver: load the library, log in, find the key, sign.

The end-to-end tests generate PDFs, sign them through SoftHSM, and then check the output with two independent validators:

pyHanko, a Python PDF signing library, validates the signatures.
qpdf checks that the file structure is sound.

Using validators I didn't write matters. My parser agreeing with my writer proves very little. Two unrelated tools agreeing with both proves rather more.

Then the real-world checks, done by hand with my own Hypersecu HyperPKI HYP2003 token: Adobe Acrobat Reader shows "Signature is VALID" on the output.

Part 5: the GST portal's local signer

The GST portal doesn't sign in the browser. Its JavaScript connects to a signer service running locally on your computer, over a secure WebSocket to 127.0.0.1, and asks it to sign. Normally that service is a separate utility you install.

TrackMy Sign can act as that local signer. At a high level:

It listens only on 127.0.0.1, only while the app is running, and only answers requests from the GST portal's domain.
Because the browser needs a trusted TLS certificate even for localhost, the app sets up a certificate for 127.0.0.1 on that computer.
Every request is shown to you. You approve it and enter your PIN; the token signs.

It's an independent implementation of the local protocol the portal's JavaScript uses. A GST portal DSC registration signed this way was accepted by the portal.

What it can't do: MCA21 V3 and the Income Tax portal use eMudhra's emBridge with licensed encryption, so TrackMy Sign can't sign on those. Keep using emBridge there.

Part 6: releases on three platforms

Every release is built by GitHub Actions from the public source, for Windows, macOS and Linux. Nobody builds a release on my laptop, and you can see what each release was built from.

macOS. The Mac app is signed and notarised by Apple. Notarisation means Apple scans the signed app and issues a ticket, so Gatekeeper opens it without the "unidentified developer" dance.

Windows. The installer isn't code-signed yet, so Windows SmartScreen shows a warning the first time you run it. I'd rather tell you that here than have you find out. A Microsoft Store version is in review, and a winget package is waiting for approval.

Linux. AppImage and .deb.

What's in v0.6.0

Beyond signing: a signature designer (company seal or logo, "For Company — Director" lines), batch signing with one PIN, a watch folder, optional trusted timestamps and LTV, signature verification with PDF reports and whole-folder checks, password-protected PDFs, page tools (merge, rotate, reorder), signing any file as .p7s or .p7m, a private signing history, a DSC expiry reminder, in-app updates, and English, Hindi and Tamil. It works offline, with no account and no telemetry. The features page has the full list.

It isn't affiliated with Adobe, eMudhra, GSTN, MCA or the CCA.

Try it, break it

I've only tested with my own token. If you have a different one, I'd like to hear whether it works, and especially if it doesn't. Issues and pull requests welcome.

Outsourcing vs building it yourself: our app arrived from 2006

Rahul Dhileep Kumar — Fri, 23 Oct 2026 04:30:00 +0000

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

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

The idea was simple

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

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

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

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

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

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

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

Then the build arrived

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

Photo: Siri louis on Unsplash

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

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

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

So we scrapped the whole thing.

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

The stupidest ₹50,000 I've ever spent

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

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

Outsourcing app development vs building it yourself

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

Outsourcing makes sense when:

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

Building it yourself makes sense when:

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

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

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

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

Here's the thing nobody tells you.

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

And their "done" might be from 2006.

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

Photo: Compagnons on Unsplash

My checklist for a one-page product brief:

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

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

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

The first night of building a SaaS MVP myself

My setup was not exactly a startup lab.

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

That was the entire tech stack of my ambition.

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

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

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

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

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

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

The modern stack I ended up with

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

Here's what Track My Academy runs on:

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

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

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

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

Then I built the Android and iOS apps too

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

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

Photo: Daniel Romero on Unsplash

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

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

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

What I learned from the 2006 build

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

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

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

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

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

Your irritation is data.

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

I'll take either.

FAQ

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

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

What should a product brief for a developer include?

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

Can a non-technical founder build a SaaS MVP?

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

Your turn

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

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

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

R.I.P. smart ball v1: what smart football sensors taught me

Rahul Dhileep Kumar — Wed, 21 Oct 2026 04:30:00 +0000

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:

	Piezo sensor	IMU
Good at	Detecting impacts and pressure	Motion, spin and orientation
Weak at	Static or slow measurements	Drift over time
Beginner-friendly	Very	Less so

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.

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

Rahul Dhileep Kumar — Fri, 16 Oct 2026 04:30:00 +0000

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

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

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

The clever idea: splitting the backend

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

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

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

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

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

Then everything went down

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

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

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

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

And it did not work.

Photo: Taylor Vick on Unsplash

The real culprit: an expired SSL certificate

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

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

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

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

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

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

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

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

The longest night in the office

I stayed in the office all night.

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

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

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

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

When I'm stuck badly enough, I call Arun

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

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

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

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

A deployment checklist I'd hand my past self

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

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

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

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

Photo: Jakub Żerdzicki on Unsplash

Rollbacks: have a way back

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

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

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

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

Monitoring and alerting: find out before your users do

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

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

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

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

Photo: Luke Chesser on Unsplash

Write the postmortem, and keep it blameless

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

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

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

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

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

Was it worth it?

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

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

I'd still prefer the tutorials, though.

FAQ

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

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

Can an expired SSL certificate take down a backend?

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

What should go in an incident postmortem?

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

Sources

What next

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

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

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

How to win a hackathon, according to a tired judge

Rahul Dhileep Kumar — Mon, 12 Oct 2026 04:30:00 +0000

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:

The problem statement you picked, in one line.
The scope you chose to tackle within it.
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.

Hello (10 seconds). Handshake, how's your day, team intro.
Problem and scope (20 seconds). One line each. No essays.
Solution (15 seconds). One sentence, plain words.
Demo (most of your time). One flow, start to finish, working.
How you built it (30 seconds). Your stack, and one hard thing you solved.
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.