Eight years ago, I was absolutely convinced of one thing:
I was ahead of the curve.
Not just good.
Not just competent.
Elite.
The kind of deve...
For further actions, you may consider blocking this person and/or reporting abuse
I'm struck by the humbling quality of this story, the way your ego got in the way of producing something truly useful. It's like when I was learning to play an instrument, and I'd spend hours trying to recreate some fancy solo, only to realize I'd forgotten the simple melody that made the whole song beautiful in the first place. The conversation with "Smart Man" must have been a turning point, it's amazing how a single conversation can shift our perspective like that, isn't it?
Thank you for this — your analogy about focusing on the fancy solo instead of the core melody really captures the technical mistake I made, because I was over-engineering patterns instead of delivering something actually usable and maintainable. That conversation was definitely a turning point, and now I try to prioritize simplicity, clear architecture, and real user value over clever abstractions
This was a powerful and honest reminder that building real value matters more than chasing complexity or ego. The ‘architect of an empty building’ line really stood out—it perfectly captures the trap many developers face. Sharing lessons publicly and helping others truly accelerates growth.”
The article emphasizes how the author spent months building over-engineered projects with zero users or income, and only began progressing after sharing real experiences and focusing on solving actual problems for people.
Thank you for this thoughtful insight — the “architect of an empty building” idea really highlights the technical trap of over-engineering systems without validating real user needs, which is something many of us learn the hard way. I truly believe sustainable growth comes from solving concrete problems, shipping iteratively, and getting real feedback early, and I’m excited to keep building with that mindset moving forward.
Thanks for sharing this life lesson, Art! It feels like you’re becoming a bit of a boomer yourself now 😉
What really struck me was when you mentioned Ronald’s line: “If nobody uses it, you are the architect of an empty building.” And especially when you talked about the hit your ego took.
I think, at some point, most of us go through that phase — the oversized ego, the certainty that we know better, and the temporary deafness to anything that challenges our vision. What makes the difference is what comes next.
Your real strength wasn’t avoiding that phase — it was being able to listen, reflect, and turn the experience into growth. Not everyone develops that kind of self-awareness. That’s what transforms a tough lesson into long-term wisdom.
Thanks again for the honest reflection — it’s the kind of perspective that helps the rest of us grow a little faster.
Haha, maybe I am slowly earning that boomer badge 😄 — but honestly, you’re right, the real technical mistake wasn’t the architecture itself, it was optimizing and over-engineering before validating real user demand. That experience changed how I approach system design now: I focus first on usage signals, feedback loops, and measurable adoption metrics — because clean architecture means nothing if it solves the wrong problem, and I’m genuinely interested in refining that balance even more in future builds.
That shift in perspective really shows. Focusing on usage signals and feedback before polishing the architecture is such a powerful mindset — and honestly, not an easy one to internalize until you’ve lived through the opposite.
What I find interesting is that many of us are trained to think “build it right” means “build it perfectly,” when in reality it often means “build it relevant.” Clean architecture becomes meaningful only when it serves something alive and evolving.
It’s great to see how that experience reshaped the way you design systems. That kind of balance between technical excellence and real-world validation is probably one of the hardest skills to master — and one that keeps evolving with every new project.
Thank you for this — I really appreciate how clearly you captured that tension between “perfect” and “relevant,” because that’s exactly the technical trap many of us fall into early on. I’m still learning to balance clean architecture with real usage signals
When I first started posting on here I was afraid to be judged.... like on social media. Then I realized, people on here are writing quality content. Real stories. Real struggles. Those are my favorite. I found it to be a safe place to share my coding dramas freely. People actually respond, and say meaningful things!
What I have learned the past couple years is that people believe a relatable story over some shiny new perfection. I resonate with that. Relatable stories build trust and connections. Alot of people are scared to share. It takes a little bit of bravery to get to the other side of that. Excellent story. ✨️
Thank you so much for sharing this — I completely relate, especially the part about feeling nervous to post at first, because putting real technical struggles out there can feel vulnerable but it’s also where the most meaningful conversations start. I truly believe honest stories about debugging failures, architectural mistakes, and growth teach us far more than polished perfection, and I’m excited to keep sharing and learning alongside people like you who value that authenticity.
✨️🦾
😎
It's great and really impressive.
Great post — I really relate to this.
I don’t actually build side projects after hours (at most, simple demos for articles or conference talks), but the core message applies far beyond coding. It’s true for pretty much every area of life.
From time to time, it’s worth doing an honest audit: are we moving in the right direction, are we making real progress, or are we just staying busy? Sometimes that reflection is exactly what shows us that something needs to change.
Thank you.
Especially the idea of doing an honest audit instead of just staying busy, because that’s where real technical growth usually starts. In engineering, I’ve noticed that without stepping back to evaluate architecture decisions and long-term impact, we can mistake activity for progress, so I’m very interested in building a habit of more intentional reflection around the systems we design.👍👍👍
This is the story no one tells junior devs.
Being "elite" at coding ≠ being elite at business.
I spent 3 years at 500 YouTube subscribers making $0 because I was teaching "React Native basics" like everyone else.
The $0 phase ended when I realized: developers don't need another todo app tutorial. They need to see how to handle REAL money without getting hacked.
Thanks for sharing your experience! What is the name of your YouTube channel?
I am glad you found it helpful
👍
Thanks.😎
If you are interested in that, feel free to contact me via telegram light4661
Love this perspective — you’re absolutely right, being technically sharp doesn’t automatically translate into business impact, and that shift in mindset is something most junior devs only learn the hard way. I’m especially interested in the security angle you mentioned, because building apps that actually handle real money securely (proper auth flows, encryption, secure key management, backend validation, etc.) is the kind of real-world technical depth we need more of in this space.
Nice approach
Good
Everything are perfect!
Thanks for the story. In this so-called 'social media' era, no one opens up about their failure. Everyone wants to show their success story even if they're not. Seeing this kind of story feels like the real world. Real world doesn't have only joy and success. Failure and struggles are also real. And, seeing success stories only doesn't help. It worsens the mind and confidence.
Thank you so much for this — you’re absolutely right, and that’s exactly why I wanted to share the uncomfortable parts, not just the highlight reel. From a technical and career perspective, I believe we grow more from debugging our failures, bad architectural decisions, and missed expectations than from celebrating wins.
Professional!
Thank you for sharing this.
lots of lessons, one can learn from this.
Thanks for your reply.
I hope you are doing well.👌
Dude congrats ! I was recently at the same point, if you want to connect what so ever, checkout my frist article on dev.to. To be honest I fell in love with this platform as it's from devs for devs and not like LinkedIn.
Thanks so much, that really means a lot — and congrats to you too! I’ll definitely check out your first article, and I totally agree, Dev.to feels way more authentic and technical compared to LinkedIn, especially when it comes to real engineering discussions and practical problem-solving.
Also on Dev.to, there are less scammers messaging you with jobs to only run some malware on your PC once you run
npm install. If you don't use docker, your crypto portfolio can vanish.👍👍👍
I felt this in my soul.
3 years ago I was stuck at 500 YouTube subscribers teaching React Native, making exactly $0 from my side projects too.
The twist? I stopped trying to go viral and started solving ONE specific problem: WhatsApp fintech bots for African businesses.
Now I help developers stop leaking API keys and actually ship secure payment apps.
Sometimes the $0 phase is just the market telling you to niche down.
If you're a React Native dev struggling to monetize, I just posted the exact Firebase security tutorial I wish I had 3 years ago.
Love this — that shift from chasing virality to solving one real, technical problem is such a powerful move, especially when it comes to things like securing API keys and building production-ready payment flows.
This hit hard — the “architect of empty building” line perfectly captures the technical trap of overengineering without product validation, and I think many of us have hidden behind abstractions, microservices, and “future scalability” instead of solving one painful user problem well. I’m really interested in exploring how we can balance solid architecture with fast validation
This really hit — the “architect of empty buildings” line perfectly captures the technical trap of overengineering without real product validation, and I think many of us have hidden behind abstractions, microservices, and “future scalability” instead of just solving one painful user problem well.
Starting from scratch isn’t exactly easy.
That is a fascinating journey. I never looked at development this way when I started, maybe because all my friends (and I) struggled to be good employees. I never thought about building something and selling it myself until I became a freelancer, but then the struggle became sell or be done. But I did egotistical things in the past, like trying to build an online coding school by myself, and several other misfortunes, so I can relate to that feeling.
That's a wonderful title, by the way.
Thank you so much for sharing that — I really relate to the shift from trying to be a “good employee” to thinking like a builder, and technically that mindset change forces us to care more about product validation, real user problems, and sustainable architecture instead of just clean tickets and deadlines.
Thanks for saving my six years you are the smart man of my life , I wish i could see that smile of yours
Haha, that made my day — if I somehow saved you six years, that’s the biggest compliment I could ask for. 😄
And trust me, the real smile is seeing thoughtful devs like you leveling up and thinking deeply about the technical side of things.
Thanku bro, i am just pursuing diploma of IT, the proffessors didn''t care how much we get in our head they just want to finsh syllabus and they only taught us about hello world in c java and it's haunting me everyday how i would be able to get job it's really fucked up situation can you guide me it will be kind of you if you do so , thanks again don't mind
Respect for being honest about that — a lot of people are in the same situation but don’t talk about it. The good news is: jobs don’t care about what your professors covered, they care about what you can build, so if you focus on mastering fundamentals (C/Java basics, data structures, Git, one backend stack) and start building small real projects consistently, you’ll be way ahead of most diploma grads
i appreciate that you re guiding me but is thier any roadmap bcz internet is full un verfied infomation
I really appreciate you guiding me here — it honestly helps a lot. Do you have a structured roadmap you’d recommend, since the internet is full of unverified information and it’s hard to know what’s actually reliable?
This was refreshingly honest. The shift from building to impress to building to solve real problems is something many developers learn the hard way. The reminder that value not architecture diagrams or clever abstractions is what actually moves the needle really stands out.
Sharing openly, seeking feedback, and focusing on usefulness over ego is such a powerful progression. Thanks for articulating a phase so many of us go through but rarely admit.
Thank you so much for this — I really appreciate how you captured the core shift from chasing clever abstractions to actually solving real user problems, because technically that’s where architecture starts serving value instead of ego. I’m especially interested in pushing this mindset further by focusing more on measurable impact and feedback loops in future builds.
wonderful!!!!
Thanks😀
What a great timing and an inspiration..
I am also planning to start a blog and thinking on content for it...
I initially thought to write something useful like the bug and fix, but my mind said it's small and write something advanced and fancy stuff...
But your post gave me good suggestion
Thank you
Really appreciate this — and honestly, don’t underestimate those “small” bug-and-fix stories, because most real engineering growth comes from solving practical problems, not just writing about fancy architecture patterns. I’d actually love to read your take on those real debugging experiences — they often expose deeper technical insights about root cause analysis, edge cases, and system behavior that advanced topics sometimes skip.
This post may have saved my future self 6 months. I am 3rd year student of AI trying to build project following the industry standards from code to deployment all by myself. Now I realized it is time to open source it to get some help from others as I cannot do everything from myself and get it to real users as soon as possible. Thank you so much @art_light for such reality check story.
This honestly means a lot — respect to you for trying to follow real industry standards from code to deployment as a 3rd year AI student, that mindset alone already puts you ahead. Open-sourcing it is a smart technical move too, because real feedback on architecture, testing, CI/CD, and scalability will push the project further than trying to perfect everything solo.
Hope to learn more from you and more people like you. It was really nice to hear from you.
Please feel free to contact me anytime.
This hit way too close to home.
I think many developers go through a "$0 phase" not because they lack skills, but because we optimize for technical elegance instead of user value. Building systems feels productive — talking to users feels uncomfortable, so we avoid it.
The part about overengineering for zero users is especially real. It’s easy to justify complexity as “future-proofing,” when in reality it’s just a form of procrastination from validation.
Communities like dev.to help because they normalize imperfection. Seeing real projects — messy, practical, useful — is often more motivating than polished success stories.
Thanks for writing this. More people need to hear it earlier.
Thank you so much for this — your point about optimizing for technical elegance over user value is painfully accurate, and I truly believe that overengineering often becomes a safe technical shield that protects us from the harder problem of validation and real feedback. I’m trying to focus more on building smaller, testable solutions that solve one clear user problem first, and your perspective reinforces that direction
The 'architect of an empty building' line is one of those phrases that sticks because it's true in more contexts than software. I spent a while in that phase too — building things nobody asked for, optimizing for elegance instead of utility. What pulled me out wasn't Dev.to specifically but shipping something small that a real person actually used. The feedback loop from even one real user is worth more than a thousand stars on a repo nobody depends on. The AI era makes this worse, by the way. It's now trivially easy to architect elaborate empty buildings. You can scaffold an entire app in an afternoon. The constraint that used to force you toward simplicity — limited time and skill — is gone. So the $0 developer trap is bigger than ever.
That “architect of an empty building” phase is painfully real, especially now in the AI era where scaffolding a full stack app takes hours instead of weeks — the technical barrier dropped, but the product validation barrier didn’t. I completely agree that shipping something small to even one real user creates the only feedback loop that truly matters.
Man, the Docker + CI/CD pipeline for zero users part made me laugh because I've literally done this. Set up a whole Kubernetes cluster for a side project that peaked at 3 concurrent users (one was me, one was my girlfriend checking if it worked).
The thing nobody tells you is that the overengineering isn't just wasted time — it's actively harmful because it makes the project feel "serious" and "almost ready" when it's actually just complex. Every layer of abstraction you add is another excuse not to show it to someone and ask "would you actually use this?"
I think the turning point for a lot of devs is when they ship something embarrassingly simple and it gets more traction than their "masterpiece." My most-used project is literally a 200-line bash script I wrote in an afternoon. Meanwhile my "proper" TypeScript monorepo with perfect test coverage sits at 0 stars.
Thanks, your Kubernetes-for-three-users story is painfully relatable 😂 — and you’re absolutely right, the real danger isn’t just the time spent, it’s how architectural complexity (Docker layers, CI/CD stages, orchestration) creates psychological safety while silently increasing cognitive load and friction for real user feedback.
I love your point about embarrassingly simple projects winning.
Very brilliant post, wonderful
Thanks
Fantastic read thanks! I can see myself saying some of the same things not too long ago. Hoping to get out of $0 developer phase soon.
Thanks a lot, that really means a lot 🙌 — honestly, most of us have been in that $0 developer phase, and it’s usually less about talent and more about learning how to solve real technical problems in a way that creates measurable value.
Would you be willing to letting me know if the pain point I'm trying to solve is valuable and see if my solution makes sense?
This is very good article i want to learn from you.
Thanks for your reply.
Please feel free to contact me anytime.
wonderful, this is a powerful and humbling reminder that real success in development comes not from ego or complexity, but from consistently creating genuine value for real people.
Really appreciate this — it’s a powerful and grounding reminder that real success in development isn’t about ego or over-engineering, but about building solutions that actually solve real technical problems for real users.
Bro, that 'elite developer with $0 in the bank' phase hits way too close to home. 😅 Glad Dev.to helped you turn it around—proof that consistency and community > temporary results. 🔥
Haha, exactly! 😅 That phase really teaches you the hard way about priorities. I’m curious though—how did you tackle the technical challenges back then, especially when resources were tight?
This resonated more than I expected. The “0 developer phase” is real that space where you’re building, learning, but not yet visible or validated. What I appreciated most is how Dev.to became a forcing function for clarity. Writing makes you confront your own thinking.
Also loved the shift from building in isolation to engaging with community feedback. That transition alone can change a career trajectory. Thanks for putting words to something many of us experience but rarely articulate.
Thank you so much for this — I’m really glad the “0 developer phase” resonated with you, because technically that phase is where we’re debugging our own thinking, refining our mental models, and strengthening fundamentals before anything becomes visible. I truly believe engaging with community feedback works like iterative refactoring for our ideas — it exposes blind spots, improves architecture of thought, and I’m excited to keep learning and building in that open loop.
Amazing post! Really like the way you have explained this so nicely and most of the developers goes through hard phase in their life and posts like this keep them motivated to move ahead despite of all hardship. Really appreciate the time you have taken to post this nice article motivating and uplifting fellow developers 😊
Thank you so much! I totally agree — sharing these experiences not only motivates but also gives practical insight into overcoming real technical and career challenges, which is something every developer can relate to. I’d love to hear your thoughts on specific strategies or tools that helped you push through those tough phases.
good idea
Great
Perfect!!!
ok.. this is very practical article and u are really talent dev for me. I am really proud of u as your client
Excellent. I recommend.
Thank you very much
very good
Thanks😀
You changed nothing
I have changed it all.
😎
Nice insight🙌
Good
Wooonderful!!
I totally agree with you!!!!!!!!!
Thanks🤣
Thanks for your story.
✌✌
Wow, that's really great career story.
I love all your articles🎏
I’d like to help you.
I’m creating side projects and I really identify with this situation, but reading this makes me feel better. Thank you very much for sharing your story.
If my experience helped even a little, that means a lot, and I’d love to hear what kind of technical problems you’re currently tackling in your projects.
This is a valuable life lesson. Accepting that outcomes, whether successes or failures, are part of the journey is a liberating feeling. Thanks for sharing.
Thank you so much — I really appreciate that perspective, and I agree that accepting both success and failure as part of the process helps us focus more on improving our systems and technical decisions rather than just chasing outcomes.