People ask me what I actually build a lot more than what tech I know, which I think is the right question to ask. So instead of a list, here's the honest version — what these projects are, why I built them, and what actually went wrong along the way, because the wrong parts are usually the more interesting story.
Where most of this started
I didn't set out with a grand plan to "build a portfolio." It happened backwards — I kept having small itches ("I wish this existed" or "I bet I could make this look better than what's out there") and just... built the thing. Some of them turned into real, deployed products people actually use. Others were purely an excuse to learn something new — GSAP, Three.js, whatever felt intimidating that month. Both kinds taught me something, just different things.
There's also a boring but true reason I have so many of these: I get bored fast once a project stops teaching me anything new. The moment a build becomes "just typing out the rest of what I already know how to do," I lose interest and start the next thing. That's probably why my GitHub has fifteen-plus repos instead of one very polished flagship app. I've made peace with that being how I actually learn.
The frontend-heavy stuff
A good chunk of my early projects are landing pages and cinematic web experiences — Demon Slayer, Zestik, Astrozyne, Deadpoolverse, Orbitalux, Athlenix Zone, Globeora, Versecore, Truffiq, Vaultory, that whole family. On paper these look like "just landing pages," and I used to feel a little self-conscious listing them next to the fullstack apps, like they didn't count as "real" engineering.
I don't feel that way anymore. Building something like Orbitalux — a 3D solar system you scroll through — taught me more about performance optimization than most CRUD apps ever did, because Three.js does not forgive you for being sloppy. I learned the hard way that dumping too many draw calls into a scene will absolutely tank frame rate on anything that isn't a high-end laptop, and "it works on my machine" means nothing when your machine has a dedicated GPU and half your users are on integrated graphics. I ended up instancing geometry for anything repeated instead of creating a new mesh per object, which sounds obvious now and took me an embarrassingly long evening to figure out at the time.
Zestik and Truffiq both pushed me deep into ScrollTrigger and GSAP timelines, and I remember spending an entire evening just fighting jank on scroll-linked animations before realizing the issue wasn't my code at all — it was will-change not being set on the animated elements, so the browser was recalculating layout on every scroll tick instead of promoting them to their own compositing layer. One line fixed what felt like a fundamentally broken animation. I still feel a little dumb about how long that took me.
Kivo AI and NeuroSpark were where I got comfortable with SplitType and character-level text animations, which sounds like a small thing until you're debugging why your split text reflows differently on mobile Safari than everywhere else. It does. It always does. Safari always finds a way to be the one browser where your carefully tuned animation just looks slightly wrong, for reasons that take way too long to track down.
Astrozyne and Versecore both lean into a sci-fi, futuristic visual language, and doing two projects in a similar aesthetic back to back actually taught me something I didn't expect — how much of "premium feel" comes down to easing curves and timing, not the actual visual assets. I could swap in nearly identical imagery between the two and one would feel expensive and the other would feel cheap, purely based on whether the motion had the right amount of overshoot and delay stagger. That's a lesson that doesn't show up in any tutorial — you only get it by shipping enough of these and comparing them side by side.
Call of Duty: Black Ops VII and Deadpoolverse were both built around license-style, high-energy branding, and both taught me that this kind of cinematic landing page lives or dies on load performance — because the whole point is heavy visuals, and heavy visuals plus a slow first paint just reads as broken, not premium. That's where I actually started caring about lazy-loading offscreen sections and deferring animation libraries until they're needed instead of blocking the initial render with everything at once.
Globeora and Athlenix Zone are the two I'd point to if someone wanted proof I can do "normal" responsive layout work without leaning on a flashy gimmick to carry the page — travel and fitness brands both live or die on whether the imagery breathes, and getting that spacing right without GSAP doing the heavy lifting was a good exercise in just... typography and whitespace discipline.
The fullstack projects — where things actually break in interesting ways
This is the part I care about more, honestly, because this is where you start hitting problems that don't have a clean StackOverflow answer.
StudyMint was the first project where I actually had to think about cost, not just correctness. It's an AI notes generator built on Gemini, and my first version called the model with basically no guardrails — no caching, no rate limiting, nothing. I found out how expensive that mistake was the hard way when I checked usage after a weekend of testing and voluntary friend-testing. That's what pushed me to actually learn request throttling, response caching for repeated topics, and just generally treating an LLM API call like the expensive resource it is instead of a free function call. I also added Razorpay for payments on this one, and integrating a payment gateway properly — handling webhook verification, failed payment states, retry logic — turned out to be its own small project inside the project.
SupportMint is the one I'm proudest of architecturally — it lets businesses spin up a custom support chatbot from their own business info and drop it into their site. The tricky part wasn't the AI, it was multi-tenancy. Each business needed its own isolated context, its own embed script, its own auth boundary, without me spinning up a separate deployment per customer. I went back and forth between a few data isolation strategies before landing on a shared-database-with-tenant-scoping approach, which felt almost too simple after all the over-engineered alternatives I'd sketched out on paper first. I also had to think hard about the embed script itself — it needed to load fast on someone else's website without conflicting with their existing CSS or JS, which is a different kind of engineering discipline than building your own app where you control the whole environment.
SpeakUp is a crime reporting platform with anonymous submissions and case tracking, and this is the project that made me actually respect RBAC instead of treating it as a checkbox feature. Getting the permission boundaries right — what an anonymous reporter can see versus what an admin handling the case can see versus what gets logged for audit purposes — took way longer than the rest of the app combined. I rewrote the role-checking middleware three separate times before I was confident it wasn't leaking anything it shouldn't. The "anonymous" part specifically forced me to think carefully about what metadata I was accidentally storing — timestamps, IP-adjacent info, anything that could de-anonymize someone even if the form itself didn't ask for a name.
Quizly, my AI quiz generation platform, taught me the annoying reality of structured LLM output. Getting a model to reliably return well-formed quiz JSON — right number of options, one correct answer, no malformed edge cases — is way harder than it sounds until you've actually tried it. I ended up validating and retrying generations against a strict schema instead of trusting the raw output, because "trust the model" is a great way to ship a quiz with three correct answers and no wrong ones. I also had to build a fallback path for when the model returned something that failed validation twice in a row, since silently failing on a student mid-quiz is about the worst possible failure mode for this kind of app.
Calmry, an AI mental wellness coach, is the project where I thought hardest about tone before writing a single line of backend code. This isn't a support ticket bot — it's talking to someone who might be having a genuinely hard day, and the prompt engineering mattered as much as the actual system design. Getting the model to be warm without being saccharine, and honest about its limits without sounding like a legal disclaimer, took a lot of iteration that had nothing to do with code at all. I also had to build in clear boundaries around what the app should never try to do — this was the project that made me actually sit down and think seriously about where an AI feature's responsibility ends and a real professional's begins.
Karero, my AI career coaching app, forced me to actually think about context windows properly for the first time — feeding in someone's resume, goals, and conversation history without blowing past token limits or losing earlier context halfway through a long coaching session. I ended up building a simple summarization step for older messages instead of just truncating them, which felt obvious in hindsight but took a failed version to get there. I also learned that resume parsing is deceptively messy — PDFs exported from Word, Canva, and Google Docs all structure their text layer differently, and "just extract the text" turned into its own small rabbit hole of edge cases.
Brainbin, my second-brain style note app, is the project closest to something I use myself daily, which changes how you build something. When you're your own primary user, you notice friction immediately instead of theorizing about it. I rebuilt the note-linking system twice because the first version technically worked but I personally hated using it within a week. The backlinking feature specifically — showing which notes reference the one you're currently viewing — took a surprising amount of thought to get performant once the note count grew past a few hundred, since naive backlink lookups turn into a lot of unnecessary querying if you're not careful about indexing.
Drawnova, the collaborative whiteboard, was my first real dive into real-time sync and conflict resolution. Two people drawing on the same canvas at once sounds simple until you actually try it — I hit the classic problem where two users' strokes would arrive out of order and briefly desync the canvas before self-correcting, which is a fun bug to watch and a much less fun bug to actually fix properly. I ended up spending real time reading about operational transforms just to understand the shape of the problem I was dealing with, even though what I eventually shipped was a simpler approximation of that, not a full CRDT implementation.
The real-time chat app and the ultra-fast sports commentary app both live in the same general problem space — low-latency delivery at scale — but they taught me completely different lessons. Chat taught me about presence and delivery guarantees: does a message need to be delivered exactly once, what happens if a socket drops mid-send, how do you handle someone coming back online and needing to catch up on messages they missed without replaying the entire history. The sports commentary app taught me about fan-out at scale — broadcasting the same event to potentially thousands of connected clients simultaneously without your server falling over, which is a very different problem than one-to-one chat delivery. I learned the hard way that a naive "loop over every connected socket and send" approach falls apart fast once you're past a few hundred concurrent viewers, and that's what pushed me toward a proper pub/sub layer instead of managing connections manually.
Why I keep reaching for the same handful of tools
If you look across all of these, the stack repeats a lot — React, Tailwind, GSAP on the frontend side, Node/Express, Mongo or Postgres, Docker and AWS on the backend side. That's not because I'm not curious about other tools, it's because I got tired of relearning basic plumbing every time I started something new. Once Docker and a repeatable deploy pipeline became second nature, I could spend a weekend project's actual time budget on the interesting problem instead of on re-figuring-out infrastructure I'd already solved four projects ago. Consistency in the boring parts is what buys you room to be adventurous in the parts that actually matter.
Things I'd do differently if I started some of these today
Being honest about this feels more useful than pretending every project was executed perfectly the first time.
On StudyMint, I'd add usage limits and cost guardrails from day one instead of after a scary usage bill. On SpeakUp, I'd design the permission model on paper before writing any middleware, instead of discovering the edge cases by rewriting it three times. On Drawnova, I'd spend a day actually reading about CRDTs properly before writing a single line of sync logic, instead of learning the hard way why naive ordering assumptions break under real network conditions. And on more than one of the flashy frontend projects, I'd profile performance earlier instead of treating it as a "polish pass" at the end — a few of them needed real rework late in the process that would've been a five-minute fix if I'd caught it on day two instead of day twelve.
What ties all of this together
If there's a pattern across all of it, it's that I keep gravitating toward projects with a real-time or AI-generation component, because those are the ones where the interesting bugs live. Anyone can build a form that saves to a database. Not everyone has debugged why a websocket connection silently drops under load, or why an LLM confidently returns malformed JSON one time out of fifty in a way that only shows up after your users have already hit it.
I don't think of the frontend showcase projects and the fullstack products as two different categories anymore, honestly. One is where I learned to make things feel good. The other is where I learned to make things actually hold up. Both skills show up in literally everything I build now, and I'd trust either half of this list a lot less without the other.