Coder Legion - Recent posts tagged dev-tools

Multi-tenant SaaS, explained with a football academy

Sat, 31 Oct 2026 12:30:00 +0000

"Multi-tenant" is one of those words that sounds harder than it is.
I put it on my CV.
Track My Academy is multi-tenant and role-based.
Real academies run on it.

So here's what that actually means, for beginners.
No cloud diagrams.
Just a football academy, a building, and some locked doors.

One note before we start.
This is about the general idea and the textbook patterns.
It is not a tour of how Track My Academy is wired inside.

Photo: Leo_Visions on Unsplash

The building: what a tenant is

Picture one big sports building.
Lots of academies rent space in it.
Each one has its own players, coaches, fees and attendance.

Every academy is a tenant.
The building is your software.

Microsoft's guide to tenancy models says that if your customers are other organisations, you usually map each tenant to one customer.
It also says a single tenant typically has many users.
One academy, many people.

That's the whole trick of SaaS.
You build the building once.
Everyone rents.

The rooms: roles

Inside one academy, not everyone gets the same keys.

The owner sees everything: fees, invoices, every batch.
A coach sees their batches and marks attendance.
A parent sees their own child, their invoices, their messages.
A player sees their own reports.

That is role-based access control, or RBAC.
NIST, who formalised the model back in 1992, says it has become the predominant model for advanced access control because it reduces the cost of managing access.
Users get roles. Roles get permissions.
You don't hand out keys one person at a time.
You hand out "coach keys".

The model was later adopted as a standard, ANSI/INCITS 359, first in 2004.
Not a new idea. Just a very useful one.

Here's the bit people mix up.
Roles decide which rooms you can enter inside your academy.
Tenancy decides which academy's rooms you can see at all.
A coach at Academy A should never see Academy B's attendance, even with full coach keys.
Microsoft's guide puts it as needing to consider both tenant and user identity when you authorise anything.

AWS's SaaS Lens names three patterns: silo, pool and bridge.

Silo. Every academy gets its own building.
In software terms, dedicated resources per tenant: its own stack, or at least its own database.
AWS notes that even a silo still shares one identity, onboarding and operations setup.
Otherwise you're running a managed service, not SaaS.

Pool. Everyone shares one building.
Same servers, same database, same tables.
AWS calls it "the more classic notion of multi-tenancy".

Bridge. A mix.
Some parts siloed, some pooled.
AWS says this acknowledges that "SaaS businesses aren't always exclusively silo or pool."

Microsoft describes the same spectrum, from fully isolated to fully shared, and says to treat isolation as a spectrum, not a switch.

Photo: Steve Pancrate on Unsplash

Same surface, separate lanes. That's roughly the picture.
In the database, it usually looks like one of these:

Model	Academy analogy	Trade-off
Database per tenant	Each academy has its own building	Strong isolation, costs grow with every new tenant
Schema or collection per tenant	Own floor, shared building	In between, and more things to manage
Shared tables with a `tenant_id`	Shared rooms, every item labelled with the academy's name	Cheapest, but every query must filter correctly

MongoDB's own multi-tenant guidance is blunt about the middle option.
It says to "avoid putting all tenants with their own collections into a single database."
It suggests a database per tenant for a small, stable number of tenants with strict access needs.
And shared collections when tenant numbers keep growing.

With shared collections, MongoDB says: "Every document must have a tenantId field, and every database query must filter by that field."
That sentence is the whole risk of the pool model.

The noisy neighbour

Shared buildings have one classic problem.
One academy throws a party and the whole building shakes.

Microsoft calls it the noisy neighbour antipattern.
It happens "when one tenant's performance is degraded because of the activities of another tenant."
Say one academy runs a giant report while another is marking attendance at the gate.
The second one waits.

The fixes on that page are sensible.
Monitor usage per tenant, not just overall.
Apply quotas, throttling or rate limits.
Run heavy, non-urgent jobs at off-peak times.
Cap expensive queries.

The silo model mostly avoids this.
Microsoft's tenancy guide says dedicated deployments make tenants unlikely to affect each other's performance.
But if one tenant costs X, it says, 100 tenants probably cost 100 times that.

The scary one: data leaks

Noisy neighbours are annoying.
Leaks are a different category.

AWS's whitepaper on tenant isolation strategies says crossing that boundary "would represent a significant and potentially un-recoverable event for a SaaS business."
Imagine a parent opening the app and seeing another academy's fee list.
That's not a bug report. That's a trust problem.

In a shared database, one forgotten filter is enough.
So I think the safest habit is to not rely on remembering.
Make the database refuse.

PostgreSQL has row-level security for exactly this.
Once it's on and no policy exists, it uses default-deny: no rows are visible or can be modified.
Supabase's RLS guide builds on the same feature and points out it still protects data when it's reached through third-party tools.

Here's a small illustrative example.
It is not Track My Academy's code, just the pattern:

-- Example only: a shared attendance table, labelled by academy.
ALTER TABLE attendance ENABLE ROW LEVEL SECURITY;

CREATE POLICY academy_isolation ON attendance
  USING (academy_id = current_setting('app.current_academy')::uuid);

The app sets app.current_academy for each request.
Postgres then filters every query on that table to that academy, even one where someone forgot the WHERE.

Two catches from the Postgres docs.
Superusers and roles with BYPASSRLS always skip these policies.
Table owners do too, unless you use FORCE ROW LEVEL SECURITY.
So the app shouldn't connect as the owner.

How I'd think about it

My opinion, for a small team:

Decide what a tenant is on day one. For academy software it's obvious. For other products it often isn't.
Put the tenant ID on everything. Retrofitting it later is miserable.
Let the database enforce isolation where it can. Code reviews miss things. Default-deny doesn't get tired.
Keep roles and tenancy separate in your head. Different questions, different checks.
Watch per-tenant usage. You can't fix a noisy neighbour you can't see.
Test for leaks on purpose. Microsoft's guide says to verify one tenant's data isn't leaked to another, whatever model you pick.

For context, the very first Track My Academy prototype had no database at all.
The Excel sheet was the database.
A long way from tenancy models.

FAQ

What is a tenant in SaaS?

A customer, usually an organisation, whose data and users are kept separate from every other customer's, even though they all use the same software.

Is a shared database with a tenant ID safe?

It can be, if every query is filtered by tenant and you add a database-level guard like row-level security. The risk is a single missed filter.

What's the difference between multi-tenancy and RBAC?

Tenancy keeps organisations apart. RBAC decides what each person can do inside their own organisation.

Sources

What next

How it started, Excel sheet and all: a coach complained, so I started a company.
And what happens when the shared building goes dark: the night I broke production.

Running an academy? Track My Academy handles attendance, fees, player reports and parent messages, and there's a free plan.

Shipping Android and iOS solo (iOS: coming soon)

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

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

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

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

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

Photo: Denny Müller on Unsplash

Building it is the part you expect

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

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

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

The two doors: Play Console and App Store Connect

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

The price of entry is the first difference.

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

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

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

Google's 12 testers and 14 days

Android is not a free pass either.

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

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

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

Apple's reviewers read the guidelines so you have to

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

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

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

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

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

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

Why Android first, for us

Here's where I'll be opinionated.

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

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

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

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

What I'd tell another solo dev

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

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

FAQ

Is the Track My Academy iOS app out?

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

Do new Google Play developers need testers before going live?

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

How much does it cost to publish on both stores?

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

Sources

What next

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

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

I tried to build my own offline Claude Code

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

Cover photo: Mohammad Rahmani on Unsplash

Claude Code and Bolt made coding agents look easy.
You type a sentence, and a model reads your files, edits them and runs things.

So naturally I wanted my own.
Offline. On my machine. No account, no trial, no meter running.

I built a personal coding-agent experiment to explore one specific thing: contextual memory limits.
How much can a local model actually keep in its head while it works on your code?

This isn't a results post.
It's about the stack, and about the wall the experiment was built to poke at.
Because anyone who tries this will hit the same wall.

The stack

Four pieces, all of them free.

Electron for the desktop app. In its own words: "By embedding Chromium and Node.js into its binary, Electron allows you to maintain one JavaScript codebase."
React for the interface.
Monaco for the editor. Its README calls it "the fully featured code editor from VS Code". You get a real editor without building one.
Ollama to run the model locally. Its FAQ is plain about it: "Ollama runs locally. We don't see your prompts or data when you run locally."

Why offline?
Partly the obvious reasons: your code stays on your machine, and it works without internet.

Partly me.
Early on, we chased every free AI trial going, with dozens of email accounts, because we didn't yet know how to use Claude or Codex.
A model that runs on your own laptop never asks for a new email address.
If you can get it for free, why spend money on it?

The real constraint: the context window

A model doesn't remember your project.
It only sees what's in its context window: the prompt, the files you paste in, the chat so far.
Everything outside that window doesn't exist for it.

A coding agent eats context fast.
File contents, tool output, error logs, its own previous answers.
It all piles up.

Local models start with a small window.
The Ollama FAQ says "By default, Ollama uses a context window size of 4096 tokens."
Its context length page says the default now depends on your VRAM: 4k under 24 GiB, 32k between 24 and 48 GiB, and 256k at 48 GiB or more.
The Modelfile reference still lists num_ctx with "Default: 2048".

So even the docs don't agree with each other.
Which is a lesson in itself: check what you're actually running.
The context length page suggests running ollama ps and looking at the CONTEXT column.

The same page recommends at least 64,000 tokens for "web search, agents, and coding tools".
You raise it with the OLLAMA_CONTEXT_LENGTH environment variable, or per request with num_ctx inside options, per the FAQ.

Why you can't just turn the number up

Because memory isn't free.
Ollama's context length page says it directly: a larger context uses more memory.

The reason is the KV cache.
While a model generates, it stores keys and values for every token it has seen, so it doesn't recompute them.
NVIDIA's guide to LLM inference optimisation gives the formula:
batch size × sequence length × 2 × layers × hidden size × bytes per value.

Their worked example is Llama 2 7B in 16-bit precision.
At 4,096 tokens, the KV cache alone comes to about 2 GB.
That's on top of the model weights.

And it grows linearly.
Double the context, roughly double the cache.
On a laptop, that's the whole game.
Every extra token of memory competes with the model itself for the same RAM.

Bigger isn't the same as better

Say you find the memory.
You still have a problem.

The 2023 paper Lost in the Middle, by Nelson F. Liu and colleagues, tested models on finding information in long inputs.
Performance was usually best when the relevant bit was at the start or the end.
It dropped when the information sat in the middle, even for models built for long contexts.

Their conclusion: "current language models do not robustly make use of information in long input contexts."

For a coding agent, that's uncomfortable.
The file you read twenty minutes ago is now somewhere in the middle.
It's technically in context. It may as well not be.

How Claude Code deals with it

The tool that inspired the experiment doesn't pretend the problem away.
It manages it.

Anthropic's memory docs start with: "Each Claude Code session begins with a fresh context window."
Knowledge carries across sessions in two ways: CLAUDE.md files you write, and auto memory that Claude writes itself.
Both are loaded at the start of every conversation.

The docs also say to keep each CLAUDE.md under 200 lines.
"Longer files consume more context and reduce adherence."
Even the memory has a memory budget.

Then there's compaction.
The context window docs say Claude Code "compacts automatically as you approach the limit".
Running /compact "replaces the conversation with a structured summary".
Afterwards it re-reads up to five of the files it read or edited most recently.
The project-root CLAUDE.md is re-read from disk and survives.

So the trick isn't a bigger window.
It's deciding what deserves to be in the window at all.

What anyone trying this will hit

My opinion, from the research above, for anyone building their own local agent:

The default window is smaller than you think. If the agent seems to forget your file instantly, check the context length before blaming the model.
Memory is the budget. Context costs RAM through the KV cache. On a laptop, you're trading model size against how much it can see.
Order matters. Put instructions and the most important code at the start or the end, not buried in the middle.
Write memory to disk. A short notes file that loads every session beats hoping the model remembers turn three.
Summarise on purpose. Long chats need compacting. Doing it deliberately beats letting the window quietly overflow.

None of this makes a local agent as good as the hosted ones.
It does make it clear why they're built the way they are.

FAQ

What is the default context length in Ollama?

It depends on which page you read and how much VRAM you have.
The FAQ says 4096 tokens. The context length page says 4k, 32k or 256k depending on VRAM.
Run ollama ps to see what you actually got.

Why does a bigger context window need more memory?

The model keeps a KV cache entry for every token in context.
That cache grows linearly with context length, so doubling the window roughly doubles its memory.

How does Claude Code remember things between sessions?

Through CLAUDE.md files you write and auto memory notes it writes itself.
Both load at the start of each session. Long sessions get compacted into a summary.

Sources

What next

How I learned these tools in the first place: dozens of email accounts and zero shame.
And what happens when an AI coding agent does its job and the humans don't: the night I broke production.

I built a pager for my own developers

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

An earlier post ended with a promise.
Sort of.

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

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

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

A very old idea

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

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

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

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

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

Photo: Winston Chen on Unsplash

Why a small team needs one

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

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

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

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

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

The rules I'd steal from Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

About those certificates

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

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

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

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

Automate renewals.
Then monitor the automation anyway.

The point

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

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

FAQ

Does a small team really need alerting?

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

What should trigger a page?

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

How do I avoid alert fatigue?

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

Sources

What next

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

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

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

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.

Outsourcing vs building it yourself: our app arrived from 2006

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

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

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

The idea was simple

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

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

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

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

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

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

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

Then the build arrived

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

Photo: Siri louis on Unsplash

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

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

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

So we scrapped the whole thing.

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

The stupidest ₹50,000 I've ever spent

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

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

Outsourcing app development vs building it yourself

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

Outsourcing makes sense when:

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

Building it yourself makes sense when:

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

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

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

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

Here's the thing nobody tells you.

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

And their "done" might be from 2006.

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

Photo: Compagnons on Unsplash

My checklist for a one-page product brief:

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

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

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

The first night of building a SaaS MVP myself

My setup was not exactly a startup lab.

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

That was the entire tech stack of my ambition.

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

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

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

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

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

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

The modern stack I ended up with

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

Here's what Track My Academy runs on:

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

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

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

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

Then I built the Android and iOS apps too

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

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

Photo: Daniel Romero on Unsplash

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

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

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

What I learned from the 2006 build

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

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

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

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

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

Your irritation is data.

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

I'll take either.

FAQ

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

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

What should a product brief for a developer include?

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

Can a non-technical founder build a SaaS MVP?

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

Your turn

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

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

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

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

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

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

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

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

The clever idea: splitting the backend

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

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

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

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

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

Then everything went down

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

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

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

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

And it did not work.

Photo: Taylor Vick on Unsplash

The real culprit: an expired SSL certificate

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

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

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

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

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

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

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

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

The longest night in the office

I stayed in the office all night.

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

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

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

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

When I'm stuck badly enough, I call Arun

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

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

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

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

A deployment checklist I'd hand my past self

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

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

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

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

Photo: Jakub Żerdzicki on Unsplash

Rollbacks: have a way back

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

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

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

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

Monitoring and alerting: find out before your users do

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

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

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

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

Photo: Luke Chesser on Unsplash

Write the postmortem, and keep it blameless

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

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

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

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

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

Was it worth it?

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

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

I'd still prefer the tutorials, though.

FAQ

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

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

Can an expired SSL certificate take down a backend?

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

What should go in an incident postmortem?

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

Sources

What next

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

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

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

I Built a Set of Free Web Tools While Working on Client Projects — Here They Are

Tue, 15 Sep 2026 07:20:18 +0000

As a designer/developer working across branding, TYPO3 builds, and client campaigns, I kept running into the same small, annoying tasks — checking contrast ratios, generating favicons in five formats, minifying a stylesheet before deploy. So over time I built myself a little toolbox to handle them. Sharing it here in case it saves someone else the same repeated Googling.

Most of these came out of solving a problem once for a client and thinking "I'll need this again." If you build Websites or juggle design + dev like I do, they're free to use: stefan-andres.at/tools.

Design & Marketing

Palette & Contrast Checker — Upload a logo, extract the brand colors, check WCAG contrast, and export ready-to-use CSS variables.
Icon & Favicon Generator — One upload, every format you need: favicon, iOS & Android app icons, social profile pictures.
Web Image Optimizer — Compress images, convert to WebP/AVIF, and resize for web performance in one pass.
SEO Check — Drop in a page URL and get an instant on-page SEO check: title, meta description, headings, and alt texts.

For Developers

CSS Minifier — Paste or upload a stylesheet, strip whitespace and redundancy, download the compressed file.
JS Minifier — Paste or upload a script, compress and mangle it safely, download the smaller file.
SVG Optimizer — Paste or upload an SVG, strip unnecessary code, download the smaller file.
CSS Clamp() Calculator — Enter a min and max size, get a ready-to-use clamp() formula for fluid typography.
JSON Formatter & Validator — Paste or upload JSON, catch syntax errors down to the exact line and column, copy it cleanly formatted.
TYPO3 Fluid ViewHelper Generator — Generate custom ViewHelpers, TCA fields & FlexForms, and test Fluid templates live.

For Clients / Agency Work

Client Briefing & Scope Generator — Capture background, target audience and scope, then auto-generate a brief, sign-off email and quote block, exportable as PDF.

Curious what small tools others here have built for their own workflow — always looking to add more to the pile.

Thinking Differently

Thu, 04 Jun 2026 21:03:12 +0000

Hey everyone! I'm Krrish Savlani founder of High Vision Labs.

I’ve always been obsessed with high-standard processes and creating the best possible developer experience, which led me to my current focus.

For the last few months, under High Vision Labs, I've been quietly building our core product: Thinking Differently.

I’m going to be completely honest: I don’t have infinite scale, flawless metrics, or a bulletproof system to promise you today.

The platform is early, and it’s a beta in the truest sense of the word.

But I have a specific obsession.

Most developer platforms optimize for the developer's initial setup.

I want to build something that optimizes for what happens after the code is written.

Because your customers will never see your databases, your APIs, or your backend architecture. But they will judge your product by them every single day.

To a developer, a slow query is just a latency metric. To a customer, it’s a frustrating experience.

To a developer, a dropped connection is a server error. To a customer, it’s a broken promise.

Every backend decision we make eventually becomes a judgment from the customer.

That’s why I’m building Thinking Differently.

The goal isn't just to give you another tool; it’s to help you build products that users can actually trust, by aligning backend decisions with real-world user outcomes.

We are nowhere near perfect yet.

But the North Star is clear:

Technology is never the destination. The success of your product is.

The first beta will be opening soon.

I'm looking for a small handful of developers who want early access, aren't afraid of a few bugs, and want to help me shape this vision from the ground up.

https://docs.google.com/forms/d/e/1FAIpQLSenXYnC9scSGY4_8YAoH6wB3KhzmgrqW8EHrextuPqPL8Fhrw/viewform

Coder Legion - Recent posts tagged dev-tools

Multi-tenant SaaS, explained with a football academy

The building: what a tenant is

The rooms: roles

Three ways to share a building

The noisy neighbour

The scary one: data leaks

How I'd think about it

FAQ

What is a tenant in SaaS?

Is a shared database with a tenant ID safe?

What's the difference between multi-tenancy and RBAC?

Sources

What next

Shipping Android and iOS solo (iOS: coming soon)

Building it is the part you expect

The two doors: Play Console and App Store Connect

Google's 12 testers and 14 days

Apple's reviewers read the guidelines so you have to

Why Android first, for us

What I'd tell another solo dev

FAQ

Is the Track My Academy iOS app out?

Do new Google Play developers need testers before going live?

How much does it cost to publish on both stores?

Sources

What next

I tried to build my own offline Claude Code

The stack

The real constraint: the context window

Why you can't just turn the number up

Bigger isn't the same as better

How Claude Code deals with it

What anyone trying this will hit

FAQ

What is the default context length in Ollama?

Why does a bigger context window need more memory?

How does Claude Code remember things between sessions?

Sources

What next

I built a pager for my own developers

A very old idea

Why a small team needs one

The rules I'd steal from Google

The danger: a pager that cries wolf

What I think a good internal pager should do

About those certificates

The point

FAQ

Does a small team really need alerting?

What should trigger a page?

How do I avoid alert fatigue?

Sources

What next

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

The great free trial hunt

Why we did it

I learn by touching things

How to evaluate AI coding assistants without fifty inboxes

Prompting is just clear thinking

What all those trials taught me

Free and student plans for AI tools: the legit route

Learning by building beats learning by watching

The real reason: jugaad over spending

FAQ

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

Are there free AI coding tools for students?

Should I make multiple email accounts for free trials?

Sources

What next

Outsourcing vs building it yourself: our app arrived from 2006

The idea was simple

Then the build arrived

The stupidest ₹50,000 I've ever spent

Outsourcing app development vs building it yourself

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

The first night of building a SaaS MVP myself

The modern stack I ended up with

Then I built the Android and iOS apps too

What I learned from the 2006 build