My 2025

Source: Dev.to

2024 – Proving I Can Build, Learn Fast, and Ship

2024 was about proving to myself that I could build, learn quickly, and keep shipping projects.

• I shipped code to production.
• I dealt with real failures.
• I made architectural decisions that had consequences.
• I learned lessons that no tutorial could have taught me.

These weren’t lessons I learned by reading; they were lessons I learned by doing.

2025 – Understanding What It Actually Means to Build Software

2025 wasn’t flashy. It didn’t revolve around frameworks or buzzwords. It was messy, practical, and occasionally uncomfortable.

Personal Milestones

• Finished high school.
• Gained free time to explore the “real” tech world beyond my screen.

First Tech Fest – DevFest by GDG Ranchi

“It might sound small on paper, but for me, it was a turning point.”

Seeing developers, speakers, and students in the same physical space made something click that online learning never quite did.

• Before DevFest: Tech felt like a solo pursuit – me, my PC, and an internet connection.
• After DevFest: I saw the human side of software: people sharing failures, debating decisions, and talking about systems they’d actually broken and fixed in production.

The biggest surprise wasn’t the scale of the event, but the realization that I belonged there. I wasn’t “too early” or “under‑prepared.” I understood the problems being discussed, asked better questions, and left with a stronger sense of direction.

“Learning doesn’t only happen through code; it also happens through exposure.”

Being in the same room as people building real things pushed me to raise my own standards, ship better software, think more responsibly, and stop treating projects as disposable experiments.

Freelancing & the Reality of Production

Thanks to the habit of writing blogs, I secured my first clients as a freelance web developer and took my skills to the real world.

From “Shipping = Finish Line” to Production Discipline

• Old mindset: If the app worked locally, deployed successfully, and didn’t crash immediately, it was done.
• New reality: Real users, real bugs, and edge cases that manual testing missed forced me to confront production‑grade quality.

Key Takeaways

1. Every decision carries weight.
2. Logs, rollbacks, and downtime matter.
3. Small changes feel heavier when real users depend on them.

In casual projects, mistakes are learning opportunities. In production, mistakes are responsibilities. A broken feature isn’t just “oops”; it interrupts workflows, jeopardizes deliveries, can affect data, and erodes trust.

Mindset Shift

• You think twice before deploying.
• You test flows you previously ignored.
• You plan for failure instead of assuming success.

The biggest change wasn’t technical—it was psychological. I stopped asking “Will this work?” and started asking “What happens when this breaks?” and “What other ways can a user break this?” These questions alone made me a better engineer.

Security – From After‑thought to Baseline

One of the most uncomfortable lessons of 2025 was realizing how exposed even a small application can be.

• I used to believe security only mattered after you had users.
• Major vulnerabilities surfaced, including a CVE that took my own app down, even though the user base was tiny.

Hard Rules I Won’t Forget

• Never run applications as root in production — ever.
• Assume every service will be scanned, probed, and tested.
• Security is not an “enterprise problem”; it’s a baseline responsibility.

Security stopped being an abstract concept for me in 2025. It became personal, and once that happens, you never build the same way again.

Projects That Forced Me to Confront Complexity

2025 wasn’t about the number of projects I built; it was about how each project forced me to confront a different kind of complexity.

1. Grocery Delivery App (Inspired by Blinkit)

• Surface: Users, products, carts, orders.
• Reality: Time‑sensitive workflows, state transitions, operational pressure.
• Lesson: Orders aren’t just data—they’re promises. Late updates, inconsistent states, or missing edge cases immediately translate into broken trust.

Read more about this project here

2. Live‑Streaming & Video Processing

• Focus: Transcoding pipelines, encoding formats, latency, resource usage.
• Lesson: Video systems are infrastructure problems, not just frontend problems. This reshaped how I think about performance and scalability.

Read more about this here

3. Finflow – My Expense Tracker

Started as a simple web app and evolved into a system with major … content truncated in the original.

Closing Thoughts

2025 taught me that production software demands a mindset shift:

• Think twice before deploying.
• Test the flows you previously ignored.
• Plan for failure instead of assuming success.

The biggest change was psychological: moving from “Will this work?” to “What happens when it breaks?”

If you’re reading this and feel the same mix of excitement and discomfort, know that you’re on the right path. The messy, uncomfortable moments are where the real growth happens. 🚀

# 2025 – Lessons Learned

Updates and a Flutter mobile app that synced data with the web taught me that shared state is one of the hardest problems in software.  
The UI is forgiving — data corruption is not.

When GitHub Actions were blocked for me, I didn’t wait. I built a simple CI/CD pipeline myself. It wasn’t fancy, but it worked — and, more importantly, it forced me to understand deployments at a lower level. When the tooling disappeared, the learning multiplied.

Payments were another major theme. I integrated multiple payment gateways, explored different verification patterns, callback flows, retries, and failure handling. Payments taught me that **correctness matters more than elegance**. You don’t optimize for beauty when money is involved — you optimize for certainty.

I briefly explored Flutter more deeply, but eventually realized my long‑term focus was better aligned with Expo and JavaScript‑based ecosystems. That detour wasn’t wasted — it clarified my direction.

By the end of the year I was building something bigger: a platform‑style app inspired by Hago and WePlay. Not just a game, but a system — users, sessions, state, and real‑time interaction.

Every project added a new layer to how I think. Not “how do I build this?” but **“what breaks first, and why?”**

Vibe‑Coding Mini‑Project

I coded a simple app to try out vibe‑coding while spreading a positive message around the world. It was a small, almost sarcastic project aimed at calling out fake participation during Hacktoberfest — for developers who show up only for the T‑shirt, not the contribution.

The app wasn’t complex. It didn’t introduce new architectural challenges, but it served a purpose: I could build something opinionated, fast, and honest without worrying about polish or metrics. That mattered more than I expected.

ReadmeHub

ReadmeHub reminded me that building can still be playful, and that not every project needs to become a product. Some projects exist just to say something, explore an idea, or scratch an itch.

In a year full of responsibility, production pressure, and real consequences, this small project helped me reconnect with why I started building in the first place. You can check it out at:

Core Takeaways

• Software is an act of responsibility. A mistake in production isn’t just a mistake; it’s a real thing you’re accountable for.
• Once something is in production, it stops being “your code” and becomes something other people rely on. That shift changes how you think, test, deploy, and respond when things go wrong.
• Speed without intention leads to fragile systems. Maturity in engineering often looks like choosing the simpler, safer option — even when you could build something more impressive.
• Growth isn’t about how much you ship; it’s about how deeply you understand the consequences of what you ship.

That mindset changed everything.

2026 – Goals & Priorities

If 2025 was about learning through experience, 2026 will be about sharing those experiences openly and building tougher software.

What I Want to Do

• Create more content — not tutorials chasing trends, but honest write‑ups about what worked, what broke, and what I’d do differently.
• Document the decisions behind the code, not just the code itself.

My 2026 Priorities

1. Build fewer things, but build them better
2. Treat production as sacred
3. Keep learning, but stay grounded
4. Share the journey, not just the outcomes

2025 taught me how fragile software can be. 2026 is about building it with more care and helping others do the same.

I hope your 2025 was as amazing and fantastic as mine. Looking forward, I wish you all a Happy 2026! 🎉