Honesty time. The plan was to deploy DevBoard today. That's not happening, and I think it's worth writing about why, because what happened this week is more representative of real software development than any clean tutorial ever is.
What Got Built
DevBoard is a developer job board with two sides: employers who post jobs and candidates who apply. Over the past few days, I built the foundation and the complete employer side:
The foundation (Day 73):
- Custom user model from scratch using
AbstractUser— something that has to be done before the very first migration, or it becomes a nightmare to fix later - Two distinct user roles — employer and candidate — each with their own profile model linked via
OneToOneField - Automatic profile creation using Django signals, so the right profile is always created the moment a user registers
- Separate registration flows for each role, with role-aware redirects after login
- Custom decorators for role-based access control —
@employer_requiredand@candidate_required
The employer dashboard (Day 74):
- Job model with full details — title, description, location, job type, experience level, salary range, tech stack, deadline, and active/inactive status
- Application model linking candidates to jobs, with a status system — pending, reviewed, accepted, rejected
-
unique_togetherconstraint preventing duplicate applications at the database level - Employer dashboard showing all listings with application counts using ORM annotations
- Full CRUD for job listings — post, edit, delete with a confirmation step
- Job applications page where employers can see every applicant and update their status
All of this works. An employer can register, post a job, manage their listings, and review applications.
What's Still Left
The candidate side and the visual layer aren't done yet:
- Job listings page with search and filter
- Job detail page with the four-state apply button
- Application flow for candidates
- Candidate dashboard showing application statuses
- REST API with DRF
- Tailwind CSS styling across all pages
- Deployment
What Actually Happened
Day 74's work took two days instead of one. The list of issues I ran into:
Page not found errors everywhere. The jobs app URLs weren't included in the project's main urls.py properly. Simple fix once I found it, but it took longer than it should have to track down.
Wrong pages being shown. URL pattern ordering in Django matters more than I expected. When I had jobs/<int:pk>/ and jobs/post/ defined in the wrong order, Django was interpreting the string "post" as a pk and routing to the wrong view. Moving the static paths above the dynamic ones fixed it.
Logic not working correctly. The employer ownership check, making sure an employer can only edit and delete their own jobs, was passing the wrong value in a couple of places. The view was running but operating on the wrong data.
The signal didn't fire. Profile creation via signals wasn't working because I forgot to import the signals module in apps.py's ready() method. Users were being created with no profile attached, which caused attribute errors everywhere downstream.
None of these were unsolvable problems. All of them were fixed. But each one took time to debug, understand, and fix properly, and that time adds up.
The Real Lesson
I planned this project assuming a roughly linear relationship between features and time. One feature equals roughly one day. That's not how building works.
The first day of any new area: models, signals, URL routing, always takes longer because you're encountering edge cases you haven't seen before. The second day in the same area is much faster because you've already been burned once. Day 74 was the first real day of building in Django without a tutorial holding my hand. Of course, it took longer.
What I should have done differently is plan more buffer into the building days. Learning days are more predictable; you cover a topic, and you're done. Building days depend on what breaks, and something always breaks.
What's Next
Rather than delaying the 100 days of code remaining progress to finish the DevBoard, I'm doing both in parallel from tomorrow.
DevBoard will get completed at a slower pace, alongside the 100 days of code, a few hours here and there until it's done. I'm estimating about a week to finish the candidate side, API, styling, and deployment. When it's fully live, I'll write a post about it.
What I'd Recommend
Build the foundation first and don't rush it. The custom user model decision, the role system, the signal wiring: these are the things that would have been painful to undo mid-project. Getting them right on day one meant every day after had a solid base to build on.
Expect debugging to take as much time as building your code. While AI LLM models can easily generate code these days, debugging and ensuring it functions correctly is a significant task on its own. When you encounter an issue, take a moment to slow down. Carefully read the entire error message. Check the URL patterns, examine the imports, and ensure that signals are correctly wired up. Most errors in Django come with clear messages once you know where to look.
And don't treat a plan as a contract. The plan exists to give direction. When reality diverges from the plan, and it will, adjust the plan; don't pretend the divergence didn't happen.
Thanks for reading. Feel free to share your thoughts!
