2024 was about proving things to myself that I could build, learn fast, and keep shipping projects. 2025, on the other hand, was about understanding what it actually means to build software.
This year wasn’t flashy. It didn’t revolve around frameworks or buzzwords. It was messy, practical, and occasionally uncomfortable. I shipped code to production, dealt with real failures, made architectural decisions that had consequences, and learned lessons that no tutorial could’ve taught me.
These are not lessons I learned by reading, they’re lessons I learned by doing.
Stepping Outside the Screen: Real-World Opportunities
This year I finished high school and also got into actual real world things, for the longest time, my entire relationship with tech existed behind a screen but after my boards I had very much free time to go and explore the real tech world.
This year, I attended my first ever 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.
Until then, tech had felt like a solo pursuit me, my pc and an internet connection. DevFest showed me the human side of software: people sharing failures, debating decisions, and talking about systems they’ve actually broken and fixed in production.
What surprised me most wasn’t the scale of the event, but the realization that I belonged there. I wasn’t “too early” or “underprepared.” I understood the problems being discussed, asked better questions, and left with a stronger sense of direction.
This experience taught me that learning doesn’t only happen through code it also happens through exposure. Being in the same room as people building real things pushes you to raise your own standards. It made me want to ship better software, think more responsibly, and stop treating projects as disposable experiments.
Production Is a Different Game Entirely
Thanks to this habbit of writing blogs I got quite lucky I secured my first clients to work as a freelance web developer and take my skills to the real world. For a long time, I treated “shipping” as the finish line. If the app worked locally, deployed successfully, and didn’t crash immediately, I considered it done (I knew few edge cases but left it there because it was just a casual project). 2025 completely destroyed that illusion. This year I dealt with apps made for real users, real people using them, bugs that weren't just there all along but left unspotted due to manual testing and treating the app with care.
Shipping code to production is not an extension of side projects, it’s a different discipline altogether. Suddenly, every decision carries weight you can't just break things and push to prod or like get a quick change. Logs matter a lot I mean a lot things can go wrong in the frontend as well as backend. Rollbacks matter. Downtime matters. Even small changes feel heavier when real users depend on them. One wrong mistake and your whole app is down for minutes cosing you a lot.
In casual projects, mistakes are learning opportunities. In production, mistakes are responsibilities. A broken feature isn’t just “oops” it’s someone else’s workflow interrupted, someone's dilevery failed, data potentially affected, or trust slightly eroded.
This year taught me that production software demands a 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?” "What more ways a user can perform this action to break things" these questions alone made me a better engineer.
Vulnerabilities Don’t Care About Your User Count
One of the most uncomfortable lessons of 2025 was realizing how exposed even a small application can be. I used to believe that security becomes important after you have users. That belief didn’t survive this year.
Major vulnerabilities surfaced that directly affected production apps including one that took my own app down. It didn’t matter that my user base wasn’t massive. It didn’t matter that the app wasn’t popular. Once something is publicly accessible, it becomes a target.
The most painful realization came at the end of the year when a critical CVE hit the ecosystem I was using. My production app was suddenly vulnerable, and the damage wasn’t theoretical it was immediate and real.
That experience taught me 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 Shaped How I Think About Software
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. Every serious project this year changed the way I reason about systems, trade-offs, and responsibility.
One of the earliest was a grocery delivery app, inspired by products like Blinkit. On the surface, it looked straightforward: users, products, carts, orders. In reality, it introduced me to time-sensitive workflows, state transitions, and operational pressure. Orders aren’t just data — they’re promises. Late updates, inconsistent states, or missing edge cases immediately translate into broken trust. You can read more about this project here
Later, I went deep into live streaming, transcoding, and video processing. This was a completely different mental model. I learned that video systems are not frontend problems —they’re infrastructure problems. Encoding formats, transcoding pipelines, latency, and resource usage all matter more than UI polish. This exploration reshaped how I think about performance and scalability. more about this here
Finflow, my expense tracker, evolved significantly this year. What started as a web app grew into a system with major updates and a Flutter mobile app that synced data with the web. Handling consistency across platforms taught me that shared state is one of the hardest problems in software. 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?”
ReadmeHub and Remembering Why I Build
I vibe coded a simple app to try out vibe coding but also spread a positive message around the world a small, almost sarcastic project aimed at calling out fake participation during Hacktoberfest. It was for the 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 it let me build something opinionated, fast, and honest without worrying about polish or metrics.
That mattered more than I expected.
ReadmeHub reminded me that building can still be playful. 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 checkit out at: https://readmehub.divyanshulohani.xyz/
The Biggest Lesson Wasn’t Technical
Looking back, the most important things 2025 taught me had very little to do with frameworks, languages, or tools. I didn't build too much projects I explored every aspect in my existing apps I could yeah some distractions were there that did contribute to the factor of not building new projects
But I learned that building software is an act of responsibility. Your mistake can cost a lot in production a mistake is not just a mistake its a real thing you are accountable for.
Once something is in production, it stops being “your code” and starts being something other people rely on. That shift changes how you think, how you test, how you deploy, and how you respond when things go wrong.
I also learned that speed without intention leads to fragile systems, and that maturity in engineering often looks like choosing the simpler, safer option — even when you could build something more impressive.
Most importantly, I learned that 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.
Looking Ahead to 2026
If 2025 was about learning through experience, 2026 will be about sharing those experiences openly and building more software tougher ones.
Next year, I want to create more content not tutorials chasing trends, but honest write-ups about what worked, what broke, and what I’d do differently. I want to document the decisions behind the code, not just the code itself.
I’m entering 2026 with clearer priorities:
- Build fewer things, but build them better
- Treat production as sacred
- Keep learning, but stay grounded
- 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 you spent your 2025 just as amazing and fantastic as I did and looking forward I Wish you all a Happy 2026
Top comments (0)