Dhikrly (ذِكْرلي) is a daily Adhkār, Du'ā, and Ṣalāh (prayer) tracker — an offline-first Progressive Web App with cross-device sync, live at dhikrly.com. I built it solo, end-to-end: product, design, and full-stack engineering, on Next.js 14, TypeScript, Tailwind CSS, and Supabase, with prayer-time calculation via adhan.js and background notifications via web-push and Vercel Cron.

The app tracks two things: adhkār/du'ā completion (with streaks and a 16-week heatmap) and the five daily prayers (with Prayed / Jamā'ah / Delayed / Missed status, plus Sunnah, Tahajjud, and Nafl tracking). Both of those only matter if the app can actually remind a user at the right moment — and that's where the hardest problem in the whole build showed up.

This post walks through it using the STAR framework: Situation, Task, Action, Result.

Situation

The entire value proposition of Dhikrly rests on timely reminders — five daily prayers plus morning/evening adhkār, each tied to a specific, location-dependent time that shifts every day. The obvious first approach — schedule a client-side timer while the app is open — quietly falls apart the moment a user closes the tab or the PWA goes to the background. Browsers (and iOS Safari in particular) suspend or kill background JS execution, so any reminder logic living in the page itself simply stops running exactly when it's needed most: when nobody has the app open, which for a prayer app is most of the day.

As a solo developer with no backend team and no native app shell to lean on, I had to solve this with only what a PWA gives you.

Task

I needed a notification system that would reliably fire at the correct, per-user, per-location prayer and adhkār times — independent of whether the PWA was open, backgrounded, or fully closed — and do it without a native app, without a dedicated ops team, and without breaking on the platform most hostile to background web execution (iOS).

Action

1. Ruled out client-only scheduling. Any approach that depended on the page or even the service worker staying alive to decide when to notify was a dead end — it had to work with the app fully closed, so the "when" had to be decided server-side, not client-side.

2. Moved scheduling to the server. I built a Vercel Cron job hitting an API route (app/api/cron/notifications) that runs on a schedule, computes each user's next prayer and adhkār times server-side using adhan.js against their saved location, and triggers a push for anyone due a reminder — the client doesn't need to be running at all for this to work.

3. Built the delivery path with the Web Push API. Subscriptions are managed through a dedicated app/api/push endpoint (subscribe/unsubscribe) and stored per-device, so notifications go out via web-push with VAPID keys. On the client, a service worker (public/sw.js) listens for push events and renders the native notification — this is the piece that lets a notification appear even when the browser tab isn't open, and it's paired with a usePushSubscription hook to manage permission state and re-subscription when it lapses.

4. Kept prayer-time math off the client's clock. Because reminders are computed server-side against adhan.js, correctness doesn't depend on trusting whatever time zone or clock state the user's device happens to be in — the server calculates once, per user, against their stored location.

5. Versioned the data model as it evolved. Local storage keys like duas_checked_v3 and salah_log_v1 reflect schema iterations to the tracking data as the notification and streak logic matured — offline-first storage that also has to sync cleanly to Supabase across devices adds real constraints on how forgiving (or not) you can be with reshaping that data later.

6. Shipped it behind a disciplined branch workflow. Working alone didn't mean working carelessly: everything flows feature/* → develop → main, with main auto-deploying to production via Vercel and develop kept always-deployable — partly so a notification-path change couldn't go live untested.

Result

Prayer and adhkār reminders now fire from the server regardless of the app's open/closed state, which was the entire point — a prayer tracker that only reminds you while you're already looking at it isn't solving the actual problem. The app has shipped through release 1.4.0 across 60 commits, running in production at dhikrly.com with cross-device sync, offline support, and the full Ṣalāh and Adhkār tracking feature set live.

Takeaways

Building this alone meant the constraint wasn't "how do I write this code" but "which layer should even be responsible for this decision" — and pushing the scheduling logic server-side, rather than fighting the browser to keep client-side timers alive, was the choice that made the feature trustworthy rather than merely working in a demo.

Dhikrly is live at dhikrly.com.

Introduction to Client-Side Storage

This tutorial explores how to use IndexedDB for web application data storage, including setting it up and manipulating data using its API. By the end of this guide, you'll have a functional to-do application that utilizes IndexedDB.

What is IndexedDB?

IndexedDB is a low-level API for client-side storage. It provides a persistent NoSQL database in the browser, allowing applications to store various types of data, such as:

• Files and blobs

• Images and videos

• Structured data (objects, lists, and arrays)

IndexedDB is widely used for progressive web apps (PWAs), caching, and gaming applications, as it supports transactions and large-scale data storage.

Base HTML Structure

Create a basic to-do application with an interface for viewing and adding tasks. Open index.html and add the following:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>TODO APP</title>
    <script src="index.js" defer></script>
    <link href="styles.css" rel="stylesheet">
</head>
<body>
    <h1>TODO APP</h1>
    <section>
        <aside class="view">
            <h2>TODOs</h2>
            <div class="todos"><ol></ol></div>
        </aside>
        <aside class="add"> 
            <h2>Add Todo</h2>
            <form>
                <div>
                    <label for="title">Todo Title</label>
                    <input id="title" type="text" required>
                </div>
                <div>
                    <label for="desc">Todo Description</label>
                    <input id="desc" type="text" required>
                </div>
                <div>
                    <button>Save</button>
                </div>
            </form>
        </aside>
    </section>
</body>
</html>

This structure includes:

1. A section to display to-dos stored in IndexedDB.

2. A form to add new to-dos to the database.

Basic Styling

Open styles.css and add the following styles:

html {
    font-family: sans-serif;
}

body {
    margin: 0 auto;
    max-width: 800px;
}

h1 {
    text-align: center;
}

section {
    display: flex;
    justify-content: center;
    padding: 10px;
    background: #3182d4;
}

.add, .view {
    padding: 30px;
    width: 40%;
}

.add {
    background: #ebe6e6;
}

ol {
    list-style-type: none;
}

Initializing IndexedDB

Now, let’s create the IndexedDB database and an object store (todo_tb) to store our to-do items. Open index.js and add the following:

let db;
const openOrCreateDB = window.indexedDB.open('todo_db', 1);

openOrCreateDB.addEventListener('error', () => console.error('Error opening DB'));

openOrCreateDB.addEventListener('success', () => {
  console.log('Successfully opened DB');
  db = openOrCreateDB.result;
});

openOrCreateDB.addEventListener('upgradeneeded', init => {
  db = init.target.result;

  db.onerror = () => {
    console.error('Error loading database.');
  };

  const table = db.createObjectStore('todo_tb', { keyPath: 'id', autoIncrement:true });

  table.createIndex('title', 'title', { unique: false });
  table.createIndex('desc', 'desc', { unique: false });
});

Explanation:

• Creates an IndexedDB database (todo_db).

• Creates an object store (todo_tb) with an auto-incrementing ID.

• Adds indexes for title and desc.

Saving Data to IndexedDB

Next, let’s implement the function to save to-do items to the database.

const todos = document.querySelector('ol');
const form = document.querySelector('form');
const todoTitle = document.querySelector('#title');
const todoDesc = document.querySelector('#desc');
const submit = document.querySelector('button');

form.addEventListener('submit', addTodo);

function addTodo(e) {
  e.preventDefault();
  const newTodo = { title: todoTitle.value, body: todoDesc.value };
  const transaction = db.transaction(['todo_tb'], 'readwrite');
  const objectStore = transaction.objectStore('todo_tb');
  const query = objectStore.add(newTodo);
  query.addEventListener('success', () => {
    todoTitle.value = '';
    todoDesc.value = '';
  });
  transaction.addEventListener('complete', () => {
    showTodos();
  });
  transaction.addEventListener('error', () => console.log('Transaction error'));
}

Retrieving and Displaying Data

To display stored to-dos, modify the IndexedDB success event listener:

openOrCreateDB.addEventListener('success', () => {
  db = openOrCreateDB.result;
  showTodos();
});

Then, define showTodos to fetch and display stored items:

function showTodos() {
  while (todos.firstChild) {
    todos.removeChild(todos.firstChild);
  }
  const objectStore = db.transaction('todo_tb').objectStore('todo_tb');
  objectStore.openCursor().addEventListener('success', e => {

    const pointer = e.target.result;
    if(pointer) {
      const listItem = document.createElement('li');
      const h3 = document.createElement('h3');
      const pg = document.createElement('p');
      listItem.appendChild(h3);
      listItem.appendChild(pg);
      todos.appendChild(listItem);
      h3.textContent = pointer.value.title;
      pg.textContent = pointer.value.body;
      listItem.setAttribute('data-id', pointer.value.id);
      const deleteBtn = document.createElement('button');
      listItem.appendChild(deleteBtn);
      deleteBtn.textContent = 'Remove';
      deleteBtn.addEventListener('click', deleteItem);
      pointer.continue();
    } else {
      if(!todos.firstChild) {
        const listItem = document.createElement('li');
        listItem.textContent = 'No Todo.'
        todos.appendChild(listItem);
      }

      console.log('Todos all shown');
    }
  });
}

Deleting Data

To implement deletion, define the deleteItem function:

function deleteItem(e) {
  const todoId = Number(e.target.parentNode.getAttribute('data-id'));
  const transaction = db.transaction(['todo_tb'], 'readwrite');
  const objectStore = transaction.objectStore('todo_tb');
  objectStore.delete(todoId);
  transaction.addEventListener('complete', () => {
    e.target.parentNode.parentNode.removeChild(e.target.parentNode);
    alert(`Todo with id of ${todoId} deleted`)
    console.log(`Todo:${todoId} deleted.`);
    if(!todos.firstChild) {
      const listItem = document.createElement('li');
      listItem.textContent = 'No Todo.';
      todos.appendChild(listItem);
    }
  });
  transaction.addEventListener('error', () => console.log('Transaction error'));
}

Conclusion

IndexedDB is a powerful storage solution for modern web applications. In this tutorial, we:

• Set up an IndexedDB database

• Implemented Add, Retrieve, and Delete functionalities

• Built a to-do application using IndexedDB

Drawbacks of IndexedDB

• Complex API compared to LocalStorage

• Asynchronous operations make debugging harder

• Browser limitations (some older versions don’t support it fully)