Not perfectly. Not everything works. Not everything got finished. But 100 days of showing up, writing code, debugging it, shipping some of it, and learning from all of it, that part is done. And that was the point.
Check out how I started:
Why I Did This
Before day 1, I was stuck. Not stuck in the way where you don't know what to learn, stuck in the way where you know exactly what you want to learn, but you can never make yourself actually sit down and do it. I was on React. Had been on React for a long time. Not because React was hard, but because I was moving by mood and vibe. When I felt like coding, I'd code. When I didn't, I wouldn't. Weeks would pass. The learning stopped while the intention stayed exactly the same.
100 days of code was a system I imposed on myself to fix that. The rule was simple: write code every day, write a blog post about it every day. The blog post part mattered as much as the code part. When someone might read about what you did today, "nothing" stops being an acceptable answer.
The other reason was exposure. I had a vague sense that full-stack development involved a lot of moving parts: frontend frameworks, backend frameworks, databases, authentication, APIs, and deployment, but I had never touched most of them. I genuinely believed that if I wanted to build anything real, I needed years of learning before I'd know enough. The 100 days proved that belief wrong. Not because the learning was shallow, but because the velocity of learning-by-building is faster than I had given it credit for.
The Journey: 100 Days in Brief
Days 1–60: The JavaScript stack
Started with React, moved to TypeScript in React, then Node.js and Express for backend, MongoDB and Mongoose for the database, and finished with Next.js. Sixty days covering the entire JavaScript full-stack. By the end of this stretch, I had built a task management app with Next.js and MongoDB, a tour listing app in React with TypeScript, and a full authentication system with React, Express, and MongoDB, registration, login, JWT-based sessions, and a dashboard showing registered users.
Days 61–72: Python
Came into this stretch overconfident. I'd used Python in university and thought a quick refresher was all I needed. Sat down to write a class and couldn't do it. Spent three days actually learning Python properly, functions, OOP, modules, exception handling, before touching Django at all. The humility check was necessary.
Days 73–85: Django and Flask
Built DevBoard, a job board application in Django, during the building phase of the Django learning. Then spent eight days learning Flask, routes, templates, SQLAlchemy, WTForms, and authentication with Flask-Login, and built a small expense tracker as the Flask capstone.
Days 86–100: DevCollab
The capstone project. Fourteen days building a full-stack developer collaboration platform from scratch, Django REST Framework backend, Next.js frontend, PostgreSQL database, deployed on Railway and Vercel.
Projects Built
Not all of these are finished. Not all of them work perfectly. That's the honest truth, and I'm not going to hide it.
Task Management App — (Link)
Built with Next.js and MongoDB. Users can create, update, and delete tasks. No authentication. Functional for what it is — a clean CRUD app that demonstrated the Next.js and MongoDB stack working together.
Tour Listing App
Built with React and TypeScript. Displays a list of tours with their details. A smaller project, but it was my first real TypeScript project, and the type safety caught several bugs during development that plain JavaScript would have let slip through.
Authentication System — (Link)
Built with React, Express.js, and MongoDB. Users can register and log in, and the dashboard shows the list of registered users. JWT-based authentication. This was the first project where a real backend connected to a real frontend — the moment things started feeling like full-stack development rather than just front-end.
Flask Expense Tracker — (Link)
Built with Flask, Flask-SQLAlchemy, Flask-WTForms, and Flask-Login. Users can log expenses with amounts, categories, descriptions, and dates. See a filtered list and running total. A small but complete application that covers the full Flask stack.
DevBoard: Django Job Board
Built with Django during the project-building phase of the Django learning section. Employers can sign up and post jobs. Candidates can sign up and apply to posted jobs. The concept is clean, and the employer side works. The candidate side has issues with the apply flow, the job listings page, and some of the routing logic isn't working correctly. There are bugs I'm actively debugging and working on. This one isn't live yet, and I'm not going to pretend it is.
DevCollab: Developer Collaboration Platform (Link)
The capstone. Details below.
DevCollab: The Capstone Project
Click to see the Full Tech Stack
DevCollab is a platform where developers with project ideas can find collaborators, and developers looking to work on interesting projects can find them. You post a project with a description, the tech stack, and the roles you need. Other developers browse, find something they want to contribute to, and send a collaboration request with a message. The project owner reviews requests and accepts or rejects them. Everyone has a public profile showing their skills, bio, and active projects.
Architecture
Two completely separate applications:
- Backend: Django + Django REST Framework, PostgreSQL database, deployed on Railway
- Frontend: Next.js (App Router), Tailwind CSS, deployed on Vercel
They communicate exclusively over HTTP. The Next.js frontend makes API calls to the Django backend using Axios with JWT interceptors. The interceptor attaches the access token to every authenticated request automatically, and when the token expires, it silently refreshes it using the refresh token and retries the original request.
Authentication is JWT-based using djangorestframework-simplejwt. Access tokens expire in 30 minutes, refresh tokens in 7 days. Token rotation is enabled; every refresh generates a new refresh token and blacklists the old one.
The Django backend exposes a REST API with these main resource groups: auth endpoints (register, login, logout, token refresh), user profile endpoints (get and update your own profile, view any public profile by username), project endpoints (full CRUD with search and filter by tech stack and role), and collaboration request endpoints (send, list, accept/reject, view your own sent requests). Custom permission classes enforce ownership; only project owners can edit or delete their projects, only project owners can accept or reject requests, and only the requester can view their own sent requests.
The Next.js frontend has nine main pages: a landing page, browse projects with search and filter, project detail with a four-state action button (login prompt for guests, edit/delete for owners, status badge for existing requesters, apply button for new requesters), create project, edit project, apply to a project, a dashboard for managing your projects and incoming requests, a public profile page, and an edit profile page.
What features made it in and why
The collaboration request lifecycle: send, accept, reject, and track status, is the core of the app, and it works. The project CRUD is complete. Authentication is solid. Public profiles work. Search and filter on the browse page work.
Current status: live but work in progress
DevCollab is deployed and accessible. The core flows work. But there are bugs. The frontend has rough edges, some loading states are incomplete, some error messages are raw API text that didn't get replaced before deployment, and there are edge cases in the collaboration request flow that behave unexpectedly. The backend API is solid but hasn't been fully load-tested, and there are likely edge cases in the permission logic that haven't been hit yet.
This is the honest state of it. It works well enough to demonstrate the concept and the architecture. It is not polished enough to put in front of real users and walk away. That work is ongoing.
Honest Lessons
Building takes longer than you think. Every time.
I came into this challenge with a mental model where building was the easy part: you learn the tools, you have an idea, you know what to build, you just build it. What I discovered is that this model is wrong in a specific and humbling way. Writing code is fast. Making code work is slow. The gap between "I have written the code" and "this actually does what I intended in all cases" is where the real time goes.
DevBoard isn't live because the routing logic broke in ways I didn't anticipate. DevCollab has bugs that survived testing because I tested the happy path, but not the edge cases. Neither of these is a skill failure; they're a failure to budget realistic time for debugging and testing. AI can give you the code. Making it work, debugging it, and testing it properly is work that cannot be shortcut, AI or no AI.
Overconfidence is the enemy of learning.
The Python refresher situation on day 62 is the clearest example. I thought I knew Python. I didn't know Python. I wasted two days before admitting that to myself and starting properly. The same thing happened with Django's URL routing, and it's Django's migration system. I assumed I understood them and paid for it in debugging time when I was wrong. The pattern is always the same: overestimate your understanding, skip the fundamentals, then spend three times as long fixing the consequences.
Writing about what I built every day forced me to actually understand what I was doing rather than just copying it. You can copy code without understanding it. You cannot write a coherent explanation of code without understanding it. The posts were the accountability mechanism and the comprehension check at the same time.
Knowing tools is not the same as knowing how to use them.
By day 100, I had touched React, TypeScript, Next.js, Express, MongoDB, Django, Flask, PostgreSQL, DRF, JWT authentication, and deployment on Railway and Vercel. I know what all of these are, how they fit together, what problems they solve, and how to build with them at a basic to intermediate level. But none of that is the same as being able to build a polished, production-quality application with them. That comes from more projects, more debugging, more edge cases, and more time.
What's Next
A few months ago, I didn't know what to build. I had ideas, but didn't know how to build them and wasn't familiar with the necessary tools to execute them. I always thought that my lack of knowledge and understanding of how to use tools was holding me back. Now I have the tools. What I have instead of the old problem is a pile of unfinished business.
DevBoard needs to be fixed and deployed. DevCollab needs its rough edges smoothed, its bugs resolved, and its missing features completed. These aren't new projects; they're commitments I made during this challenge that aren't fully honoured yet.
That's the immediate focus. Finish what was started. Both applications are live, working, and presentable.
After that, the plan is job hunting, offering freelance services, and continuing to build. The 100 days didn't make me a senior developer. They made me someone who knows enough to be dangerous, someone who can pick up a task, figure out what's needed, build something that mostly works, debug what doesn't, and ship it. That's enough to start.
The 100 days are done. The work? Far from done.
If you enjoyed this, follow me here:
I've been posting mostly in
#100daysofcode
#webdev
You can also connect with me on LinkedIn as well. This is where I am active the most.
Thanks for reading. Really appreciate anyone who was following the journey along.
Top comments (0)