I'm a B.Tech student in a small Indian city, and I'm going to write honestly for 30 days

Most developer blogs I read sound like their authors have it all figured out. I don't, so I'm not going to write like that.

This is Day 1 of a 30-day series. One post a day, every day, for the next month. Before the first technical post lands tomorrow, I owe you an introduction, a list of the rules I'm holding myself to, and a map of where this is going.

Who I am

I'm Suraj. I live in Kishanganj, India, and I'm studying B.Tech in Computer Science at SRM (2023–2027). I build full-stack and AI projects, mostly on my own, sometimes in a team. Here's what's actually in my portfolio right now, with no rounding up:

• CardBridge, a card-discount marketplace where the escrow rules live inside Postgres instead of the frontend. Built solo over about two months.
• Whiteboard.ai, a real-time collaborative system-design whiteboard where an AI reviews your architecture diagram. It runs locally against a dev database. It is not deployed, and I'll say that every time it comes up.
• Knot.ai, a spoken interview-practice app with five AI interviewer personas, built for a hackathon.
• Hospitality.ai, an insurance-aware care navigator, built for a healthcare challenge.
• Job Scheduler, a distributed background-job platform built on Postgres alone.
• GigShield, parametric income insurance for delivery riders. This one was a team of three, so the credit is shared, and I'll name my teammates when I write about it.
• This portfolio, which looks like a newspaper (The Nandan Review) and has its own design system.

That list looks impressive written down. Reading it back, I notice it doesn't say how many times each project broke, how many decisions I'd reverse, or which ones have no tests. That's the part I want to write about.

Why 30 days of this

Three honest reasons.

1. Writing exposes what I only half-understand. I can build a Postgres state machine, but explaining why it beats checks in the frontend, in plain words, forces a clarity that building alone doesn't.

2. A public record of how I think is a better résumé than a list of buzzwords. Anyone can write "Postgres, React, Node" on a page. Fewer people can show a decision, the alternatives they rejected, and the thing that went wrong.

3. I'd like to meet other people who write in public. Wherever you are, if you're learning in the open too, I'd like to read your work.

The rules I'm setting for myself

I'm writing these down on Day 1 so you can hold me to them on Day 30.

1. Only write what I actually did or actually believe. No invented metrics. No "I 10x'd my productivity" claims. If a number appears in a post, it comes from something I can point to in a repo.
2. Say what didn't work. My case studies each end with a "limits" section. Whiteboard.ai's AI review eval is written but has never been run against a real API key, so its catch rate is unmeasured. I'd rather you read that sentence from me than discover it yourself.
3. Keep every post readable in one sitting. Most will take somewhere between 4 and 9 minutes.
4. Credit teammates. Team projects will say so, with names.
5. Opinions are labelled as opinions. When I'm giving advice rather than reporting what I did, I'll say so.

What's coming

Here's the rough shape of the month, so you know what you're signing up for.

Weeks 1–2: the building side. Putting business rules in the database. The deploy that silently failed for two weeks. How I decide between a rewrite and a refactor. What a design system actually is.

Weeks 2–3: AI and systems. How a RAG helpdesk answers only from documents. How I use AI coding tools without outsourcing my thinking. What went wrong building Whiteboard.ai and Knot.ai. Six data structures I implemented by hand for a job scheduler.

Weeks 3–4: the human side. Money, motivation, impostor syndrome, writing, reading other people's code, and what I'm honestly not good at yet.

Not every post will be a tutorial. Some will be about decisions, some about doubt. If you only want code, you'll find plenty. If you want to know what a student actually thinks halfway through a CS degree, there's some of that too.

A small ask

If you're a student or early developer working from somewhere that isn't a tech hub, say hi in the comments. Tell me one thing you're stuck on this week. It can be technical ("my RLS policy returns nothing") or not ("I don't know what to build next"). I'll read every comment, and the best questions will turn into posts later in the series.

A small glossary for the series

Some terms will come up repeatedly. If any are new, here's the plain-English version.

• State machine: a model where something can be in exactly one state at a time (say, FUNDED), with a fixed list of allowed moves between states.
• Row Level Security (RLS): a database feature where the database itself decides which rows a given user can read or change.
• RAG (Retrieval-Augmented Generation): give an AI model the relevant pieces of your own documents at question time, so it answers from them instead of from memory.
• Embedding: a list of numbers that represents the meaning of a piece of text, so similar meanings sit close together.
• Parametric insurance: cover that pays automatically when a measurable event (like heavy rain) crosses a threshold, with no claim to argue over.
• Idempotent: safe to run twice. Doing it again has the same effect as doing it once.
• Write-ahead log (WAL): write the change to durable storage first, then treat it as done.
• Serverless function: a small piece of code the host runs on demand, so you don't manage a server.

How to follow along

You don't have to read in order. Each post stands alone, and later posts link back to earlier ones where it helps. A few ways to use the series:

• Binge it in a weekend using the reading map on Day 29.
• Pick by interest: database and security (Days 2, 17, 20), AI (Days 5, 11, 12), career and mindset (Days 4, 9, 14, 26).
• Skim the takeaways card at the end of each post first, then decide whether to read the whole thing.

What I'd love your help with

I'm learning in public, which means I'll get things wrong. The most useful comments are:

1. Corrections. If a claim is off, tell me and I'll fix the post and note what changed.
2. Counter-examples. "That didn't work for me because…" is gold.
3. Questions. If something wasn't clear, it's my writing's fault, not yours.

Also, a quick disclosure about how these were made: the posts are written from my own project notes and case studies, and I use AI tools in my workflow (more on that on Day 5). Every technical claim is something I can point to in a repository.

Tomorrow: why I put my escrow rules in the database instead of in React, and what it cost me.

See you then.