DEV Community

Cover image for Why do scheduling apps need my email? I built a 100% Client-Side Timetable Builder instead 📅🚀
admin@adawati.app
admin@adawati.app

Posted on • Originally published at adawati.app

Why do scheduling apps need my email? I built a 100% Client-Side Timetable Builder instead 📅🚀

Let’s be honest. Have you ever tried to find a simple web app to build a weekly schedule or timetable?

You usually encounter two scenarios:

It’s a clunky Excel template that looks terrible on mobile.

It’s a "modern" app that demands your email, makes you verify your account, and then throws a paywall at you just to export your schedule.

All of this just to map out 5 or 6 university courses across a week!

As a developer, I found this ridiculous. A timetable app doesn't need a heavy backend, user authentication, or a database. So, I decided to build the Adawati Timetable Builder — a blazing fast, 100% client-side scheduling tool with zero backend.

Here is how I built it and the technical hurdles I bypassed using standard web APIs. 🛠️

🚫 The "No-Database" Approach (State Persistence)
When you build an app without a database, the immediate question is: How do we save the user's data so they don't lose it on refresh?

I heavily relied on the localStorage API.
Whenever a user adds a course, the app updates an array of objects representing the schedule, stringifies it, and saves it locally. When the DOM loads, it checks localStorage, parses the JSON, and hydrates the UI instantly.

The result? The user gets an "auto-save" experience identical to a cloud app, but their academic schedule never leaves their physical device. Absolute privacy, and $0 server costs for me.

⏱️ Detecting Time Conflicts in the Browser
If you add a class on Monday from 09:00 to 10:30, you shouldn't be able to add another Monday class at 10:00.

Instead of sending an HTTP request to a server to validate this payload, I wrote a lightweight validation engine that runs in the browser.
To make the math easy, the app converts all times into "minutes from midnight". Before a new course is injected into the DOM, the algorithm loops through the existing courses for that day and checks for overlaps:

New Start Time < Existing End Time && New End Time > Existing Start Time

If it returns true, the UI instantly throws a warning. Because there is no network latency, the feedback is lightning-fast.

🖼️ The Final Boss: DOM to High-Res PNG
The number one feature students want is the ability to download their timetable to use as a phone lock screen.

Converting a complex HTML/CSS layout (grids, flexbox, text) into a downloadable image is notoriously tricky. I used the Canvas API to take a "snapshot" of the DOM.
However, if you've ever done this, you know the exported image often looks blurry, especially on Retina displays.

The fix: I programmatically forced the Canvas to render at 3x the normal resolution before generating the Base64 data URL. The result is a beautifully crisp PNG that downloads directly to the user's device without a single server round-trip.

👉 Try it out yourself!
If you want to see how smooth a 100% client-side app can feel, try building a quick schedule (and try to trigger the time conflict warning) here:
Adawati Timetable Builder

Question for the dev community: Have you ever worked with DOM-to-Image libraries (like html2canvas)? How did you handle the blurry text issue or CSS cross-browser quirks? Let me know in the comments! 👇

Top comments (0)