Skip to content
Data engineering

Prayer-Time Software Needs Provenance, Not False Precision

๐ŸŒ™ District-aware Sehri and Iftar schedules for Bangladesh, with PDF exports and protected timetable management. Next.js, PostgreSQL, Prisma.

Written by Montasim
2 min read

Ramadan Clock interface preview

The visible feature was only the surface

Sehri/Iftar schedules need a clear local-time public view and an auditable maintenance workflow because external prayer-time sources, district selection, and timetable corrections can change the result.

The system also had to respect concrete constraints. Calculated times depend on source, method, location, and local authority. External fetching requires retry/rate limiting and must not overwrite validated data indiscriminately. Duplicate date/location rows and malformed bulk imports must be rejected.

My role covered product design and full-stack engineering, with responsibility for product workflows, data boundaries, and delivery.

I turned the constraints into boundaries

Next.js public/admin UI; schedule service for query/import/status/formatting; Prisma/PostgreSQL with unique (date, location) records and tagged cache; Aladhan adapter with retry/token-bucket controls plus export generators.

Persist normalized date/location times rather than calculate every public request.

Validate JSON/CSV size, fields, row limits, and duplicates before writes.

Use tagged caching/revalidation for reads and explicit source/method caveats for accuracy.

The key decision: Persist normalized date/location times.

The implementation had to prove the model

I delivered the work across the full path: Built today/calendar/location views and live status. Implemented authenticated administration, multi-district fetch progress, upload history, and cache controls. Created robust JSON/CSV import and data model. Added PDF/image export, API docs, Vitest, and operational guides.

The result is concrete: Visitors can check daily and full Ramadan schedules. Administrators can import/fetch/manage location data. Duplicate/malformed records are rejected. Users can export schedules while seeing source/accuracy guidance.

The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.

Working through a similar challenge?

Share your context, constraints, and timeline to start a focused conversation.

Discussion

Join the conversation about this article

0 comments

Loading discussion

Fetching the latest comments.

Leave a reply

Respond to the article or continue the discussion.

Ctrl + Enter to post

Your email stays private. Comments are stored securely.