red.systems / blog / donezo

DoneZo: My first ever project

· 4 min read · Java Data Structures Algorithms

Back in my second year of college, we were handed a prerequisite project for Object-Oriented Programming (OOP). The only catch? It required strict data encapsulation, and we were forced to use javax.swing.

Before this project, my entire coding worldview was limited to a year of procedural C programming—basically just printf() statements, command-line terminal loops, and basic file handling. I didn't know what SQL was. I didn't know how a backend talked to a frontend. I had absolutely no idea how a session or an authentication system worked under the hood.

All I had was a team of stressed-out friends, a deadline, a fresh grasp of Java syntax, and pure, unadulterated logic.

This is the story of how we built DoneZo—a high-performance weekly orchestration engine—completely from first principles. It’s still the proudest project I’ve ever built.

1. Figuring out javax.swing

When we started, we were staring at a blank canvas. Our UI/UX designers pulled an absolute miracle and knocked out gorgeous Figma designs in just two days. Then, our frontend dev stepped up and seamlessly translated those designs into actual working code.

But making a weekly calendar planner in Java Swing when you’ve only ever written terminal apps is a humbling experience.

Our first massive breakthrough was just figuring out how to get visual blocks to render on the screen to represent time slots. Once we got the UI to stop throwing layout tantrums, we had to make the actual "engine" work.

2. The Spatial-Temporal Collision Engine

The core feature of DoneZo is that it auto-places your tasks into open slots in your week and instantly tells you if you have a schedule conflict. The fancy architectural term for this is a Spatial-Temporal Collision Engine.

While staring at absolutely nothing while thinking about my life decisions, I randomly realized we could model the entire 7-day week as a 2D matrix grid split into 15-minute intervals.

Instead of writing heavy, looping search algorithms to see if your tasks overlapped, we implemented an O(1) constant-time check. We mapped out time as a binary occupancy grid (like a chess bitboard). 

         [15-min blocks]
          00:00  00:15  00:30  00:45
Mon [ 0 ] [ 0 ]  [ 1 ]  [ 1 ]  <-- 1 means occupied!
Tue [ 0 ] [ 0 ]  [ 0 ]  [ 0 ]

If a user tries to drop a task into a slot, the engine performs a lightning-fast bitmask-style occupancy check. If the grid coordinate hits a true or a 1, boom—instant conflict detection. We even had to hand-roll custom edge-case logic to handle "midnight wrap-arounds" so tasks crossing the 00:00 boundary didn't break reality.

3. What the f*** is an SQL

Because I didn't know databases existed, I had to fall back on what I knew from C: file handling.

We built a custom persistence layer out of raw flat files. But if you're saving tasks to a text file, what happens if a user types a comma or a space in their task title? It breaks your parser. To solve this parsing collision problem, my groupmate invented a specific alphanumeric delimiter: a36f9a45416c.

Our text files looked like a chaotic string of text separated by this random hash. It wasn't elegant, but it meant our data parsing was completely deterministic.

Hand-Rolling Auth and Sessions

For security and user isolation, I looked at file handling and thought, "Why don't we just give every user their own isolated database file?"

  • Authentication: When you sign up, your credentials get appended to a master accounts file. When you log in, we read the file and check your inputs.
  • Session Management: To make the application remember who was logged in when switching screens, I created a temporary session file that wrote the active user's ID to disk and read it back when needed.

I literally figured this out on the fly the night before the presentation.

4. Task Prioritization Algorithm

To prevent users from suffering from scheduling decision paralysis, we created a prioritization formula to quantify how important a task actually is.

Instead of just sorting by date, we built a multi-criteria decision model using dynamic weights:

  • Urgency Decay: Calculated via (30 − daysLeft). The closer the deadline, the heavier the score.
  • Difficulty Weights: Hard tasks got 20 points, Medium got 10, and Easy got 5.
  • The Quick Win: We injected a micro-task bonus to prioritize fast, easy tasks to give users a dopamine hit.

To balance cognitive load, our TaskSorter grouped these prioritized tasks into roughly 70-point daily chunks so users wouldn't look at their calendar and immediately want to quit.

Final Thoughts

Look, if I look back at the source code today, I know it's objectively terrible. It's janky, it ignores industry standards, and it's held together by duct tape, Java syntax, and sheer willpower.

But it taught me a lesson that no textbook ever could: software engineering depth isn't about the frameworks you know; it's about your ability to solve problems from first principles. We didn't need a heavy relational database or an external library. We just needed logic.

Shoutout to the team for surviving that Mini Hackathon and getting 2nd place. It remains my favorite project to date.