Six months.
100,000 lines of code.
And a whole lot of context switching.
This post is a reflection on one of the most intense and rewarding contracts I've ever taken on. I led the development of a full-fledged SNS (social networking service) app from scratch for a client that had a clear goal… but little technical knowledge. Our deadline? Six months.
🧠 What I Was Responsible For
Basically… everything.
- Project planning and roadmap creation
- Tech stack selection
- Leading development (including writing a huge chunk of the code myself)
- Mentoring juniors and interns
- Acting as sales engineer — navigating client meetings, translating technical requirements, and proposing solutions
- Consulting the client on how tech could meet their business goals
🧱 Tech Stack
I chose a modern, scalable stack that balanced developer productivity with performance:
- Frontend: React + Chakra UI
- Backend: NestJS (with modular architecture and clean code principles)
- Infrastructure: Google Cloud Platform (Cloud Run, Firestore, Firebase Auth, etc.)
It let us move fast, deploy flexibly, and keep everything manageable as the project grew.
📊 The Numbers
- 100,000+ lines of code (frontend + backend)
- 6 months
- Team size: 2 juniors + myself
- 1 senior engineer = me
💥 The Biggest Challenges
1. Context switching
I went from fixing bugs to answering junior questions to preparing slide decks for client meetings — sometimes all within the same hour. Staying sharp while switching between business, dev, and mentoring was brutal.
2. Communicating with a non-technical client
Our client had passion, vision, and drive — but not much technical understanding. That meant I had to constantly reframe problems in non-technical terms, manage expectations, and explain why certain things take time or need to be done "the right way."
3. Balancing speed with quality
With only six months, we had to move fast — but I didn’t want to build something that would collapse under real users. I focused on clean architecture, modular components, and testing — while still shipping fast.
4. Mentoring while building
Teaching interns and junior devs while also being the primary coder meant I had to document decisions well, review code thoroughly, and make sure they weren’t blocked — all without slowing down the project.
💡 What I Learned
- You can’t build something great alone, but sometimes you have to lead alone.
- Good documentation and reusable components saved my sanity.
- Clients don’t need to understand code — they need to trust your decisions. That trust is built through clear, frequent, honest communication.
- Teaching others made me a better engineer — I had to deeply understand what I was doing in order to explain it.
🏁 Final Thoughts
Would I do it again?
Honestly… yes.
It pushed me past what I thought I could do and gave me battle-tested confidence in leading full-cycle product development — from first client call to production deployment.
If you’re in the trenches right now leading a project like this: stay sharp, stay humble, and remember that even when you’re deep in the code, you’re building something that matters.
Top comments (0)