In my final year of school, I opened a text editor and decided to code my own agenda rather than use an existing one. Three years later, it's still running.
Context
agendDAY wasn't born in a classroom. In my final year, I wanted to get organised and decided to build the tool rather than use one. At the time, I was starting from zero: I didn't know how PHP communicates with MySQL, what a session is, or why a SQL query can be dangerous. I discovered everything by breaking things.
The project then evolved throughout my BTS SIO SLAM. Every skill learned in class found an immediate application on agendDAY: PHP sessions led to authentication, CSS variables to the light/dark theme, hashing functions to secure password management.
Hosted on OVH, Apache server, MySQL database. No framework initially because I didn't know any.
The Product
That wasn't the original plan. Initially, agendDAY just displayed dates and that was it. Each feature was added when I had the tools to do it properly: event CRUD, then authentication, then the light/dark theme, then email reminders.
I also designed a full landing page hero with interactive calendar preview, features section, testimonials and call-to-action. Not because it was required, but because I wanted it to feel like a real product. That's where I started thinking about the user before thinking about the code.
The Calendar
Displaying a monthly calendar sounds simple until you tackle it. First problem: what day of the week does the 1st fall on? Then: how do you offset the empty cells at the start of the grid? How do you handle February? How do you navigate between months without reloading the page?
I built the grid entirely in JavaScript dynamic DOM node creation, offset calculation, highlighting the active day. The sidebar updates on every cell click and fetches the day's events from the database.
CRUD & Modals
Adding an event means: opening a modal without reloading, validating on the client side, sending a PHP request, writing to the database, returning a response, updating the interface. On paper it's linear. In practice, I wrote dozens of variations before getting something clean.
The critical point was managing data per user. An event belongs to a specific account that seems obvious, but that's where I understood why you shouldn't let the client send their own ID in requests, and why prepared queries exist.
BTS Versions
During my BTS, I added registration and login. That meant correctly managing PHP sessions, hashing passwords with bcrypt, and not letting one user access another's data.
The light/dark theme introduced me to CSS variables. An attribute on the <body>, properties that cascade, and a preference stored in localStorage.
Email reminders, sent via PHPMailer, introduced a different logic: a task triggered server-side at a specific time, independently of what the user is doing. My first encounter with the concept of asynchronous processing.
Takeaways
The real difficulty of this project wasn't technical it was progressing without any reference points. When something breaks, there's no one next to you to point at the line of code. You dig, you test, you break something else while fixing it, and you start again. It took time, but I understood what I was doing.
agendDAY is still live today, with code written across several different eras. You can see traces of every learning inside it. I'm not ashamed of that: it's proof the project served its purpose.