Background
DeenCal is the second iteration of KareemCal, the main motivation behing the second iteration was honestly because I was fed up with file uploading mechanism.
For context, I built KareemCal to address a challenge I was personally facing as a Muslim student: a demanding workload that often pulled me away from my religious practices. I wasn’t comfortable with that - so I decided to create a solution. After browsing around for a while, I came across Prayercal. However, I noticed that Prayercal’s prayer times were consistently off - by about 15 minutes - compared to when they actually should occur1.
Yellow: Competitor, Blue: PrayerCal
Yellow: Competitor, Blue: PrayerCal
I would later find out this was due to the developer hard-coding Timezone:Europe/London.
Key Features
KareemCal now features a fully reworked design system - optimized for ease of use, attention-grabbing headlines, and a custom walkthrough tutorial for first-time users. It also includes greater compliance with RFC 5545, the standard for calendar data exchange. Instead of requiring .ics file downloads, KareemCal now uses a dynamic webcal publishing system over HTTPS - powered by FastAPI for real-time calendar syncing. Significant improvements were made to timezone accuracy - the system now adjusts prayer times based on the user's detected address timezone, providing a far more precise experience globally. After launch, we received several insightful feature requests from users:
- Person 1: Suggested a task-based scheduling system integrated with DeenCal. The idea: use an algorithm (or AI) that organizes tasks based on user-set priorities for the day - mimicking productivity tools like Motion, but tailored for Islamic routines.
- Person 2: Recommended adding additional prayer time calculation methods such as ISNA, Umm al-Qura, and other widely recognized Sunni calculation committees.
Design Challenges
One of the biggest design challenges was evaluating my own previous work2. It’s often just as hard to refactor your own designs as it is to write something new. Once you’ve built something methodically, it takes a different mindset to re-examine it critically, identify friction points, and look for ways to elevate it.
Original Home Page
Original App Page
For this iteration, I wanted it to feel more interactive and dynamic - like a living product. I added gradient transitions to guide the user's eyes across the screen, paired with new hover effects to make it feel more polished and production-ready.
Now generally - and this might surprise you - I avoid using AI in my projects. I find that it often robs the experience of what makes building fun: the struggle. But that said, it has its place.
For example, I was stuck trying to rethink the /app page layout. So, I turned to v0.dev, and it actually sparked some clever ideas. It suggested a tabbed layout that maintained a sleek, single-page look, and I was like: yep, that's the cherry on top.
Technical Challenges
I can't overstate how tricky it was to get RFC 5545 compliance to actually behave. I used the iCalendar validator and passed all checks - but it turns out that passing doesn't mean it'll work everywhere.
One major pain point: getting Outlook to recognize and accept a generated .ics file. I tried everything - setting headers, encoding in UTF-8, hosting the file statically to rule out backend issues. Still no dice.
Eventually, I found this obscure Outlook support thread after digging through the trenches of the internet. I even reached out to the folks at PrayerCal but never heard back. So one compromise on the road to release: KareemCal currently supports Google Calendar and Apple Calendar only.
If anyone at Microsoft Outlook team is reading this - please either adopt the same .ics parsing logic as Google, or at least make proper docs on how your `.ics` processing *actually works* 😅
The second big challenge was figuring out how to create and serve .ics files efficiently. My original idea was to hash each user’s location and store the generated file in a database. But since the Google Geocoding API includes the user's exact latitude,longitude - the chance of someone being at the exact same spot for a re-request is basically zero.
So instead, I switched to a hash based on their email + salt. That way, the same email always maps to the same calendar file, which implicitly rate-limits access. Smart, right?
But here comes the tradeoff: should these files even be stored? Each calendar is about 80KB. Scale that to 1,000 users and now you’re looking at 80MB (not GB - slight math slip earlier), sitting in storage... doing nothing.
Hosting on platforms like Railway or Fly.io penalizes more for storage than for network transfer. So I ran the numbers:
- Storing 1 GB (~12,500 calendars) might cost me about $0.15 in DB charges.
- Whereas generating them on-the-fly costs ~$0.02 per GB transferred, so I could serve around 90x more calendars (~93,750 calendars) before hitting $0.15.
Storage Based Pricing from Fly.io
Request Based Pricing from Fly.io
That means dynamic generation is cheaper and more scalable - just like how PrayerCal does it. (I confirmed this by submitting the same email twice and getting different calendars each time - they're clearly regenerating.)
My approach prioritizes rate-limiting and user fairness. Could someone bypass the system by using multiple emails? Sure. But for now, this balance between cost, complexity, and fairness feels right.
Conclusion
Building DeenCal was one of the most fulfilling projects I’ve worked on - from the earliest design iterations to the final implementation. Every stage of development, including late-night debugging sessions and spontaneous UI redesigns, felt genuinely exciting.
What made this project even more special was the constant feedback and conversations I had with friends, developers, and members of the Muslim community. These interactions pushed me to refine features, rethink usability, and explore technical improvements I wouldn’t have considered alone.
On launch day, DeenCal quickly gained traction, jumping to over 500+ users - a number that both surprised and encouraged me. It’s a clear reminder that when you build something rooted in a personal need and shared values, it resonates deeply.
This is just the beginning. I’m looking forward to evolving DeenCal further with continued input from the community, and, insha’Allah, making it an even more helpful and empowering tool.