DEV Community: Yunus Khan

Designing Ethical, Privacy-Preserving Sponsorships for a Static Web App

Yunus Khan — Sat, 24 Oct 2026 20:30:31 +0000

Designing Ethical, Privacy-Preserving Sponsorships for a Static Web App

Can a free web application generate revenue without relying on behavioral advertising, intrusive pop-ups, or extensive user tracking?

That is a question I have been exploring while working on SabrTime, an Islamic Progressive Web App focused on duas, prayer-related tools, tasbeeh, and spiritual reflection.

The idea is to design a direct sponsorship system that allows suitable businesses to support the project through clearly labelled advertisements while preserving user privacy and keeping essential features accessible.

This article documents the proposed architecture, security considerations, advertiser review process, and implementation roadmap. The system described here is a design under development, not a claim that a complete advertising platform is already live.

Project: https://sabrtime.in/

The Problem: Monetization Without Compromising Trust

Many independent applications depend on advertising networks, subscriptions, donations, or affiliate marketing.

Each model has trade-offs.

Third-party advertising can introduce external scripts, cookies, tracking requests, and limited control over the final advertisement. Subscription models may restrict access for users who cannot pay. Affiliate programs can introduce referral tracking and unpredictable revenue.

For an application built around personal values, these trade-offs deserve careful consideration.

The questions I wanted to investigate were:

Can advertisements be selected by page context instead of personal browsing history?
Can a publisher review every campaign before it appears?
Can paid placements be clearly distinguished from editorial content?
Can campaign performance be measured without building individual user profiles?
Can essential application features remain free?

These questions form the basis of the proposed sponsorship architecture.

The Proposed Model: Direct, Contextual Sponsorship

Rather than immediately integrating a conventional advertising network, the proposed system would allow businesses to apply for direct sponsorship placements.

A campaign would be reviewed before publication. Approved advertisements could then appear in designated areas of the application, such as selected educational articles or non-essential tool pages.

For example, a publisher of educational books might sponsor a relevant resource page. The placement would be labelled as sponsored, link to the advertiser's website, and remain separate from the article's editorial conclusions.

The application would not need to infer the visitor's religious practices or create a behavioral profile to display that placement.

This is contextual sponsorship: the placement is selected according to the page or section, rather than a profile of the individual visitor.

A Simple Architecture for a Static Application

A static frontend can display approved sponsorship content without requiring a complex advertising server.

However, static hosting alone does not provide secure administrative authentication, private storage, payment verification, or campaign-management permissions.

A practical architecture therefore separates public campaign delivery from private administration.

The diagram represents a proposed workflow rather than a deployed system.

Public campaign configuration

A small pilot could use a curated JSON configuration containing approved campaign information.

For example:

{
"campaignId": "campaign-001",
"advertiserName": "Example Book Publisher",
"placement": "educational-content",
"status": "approved",
"startDate": "2026-11-01",
"endDate": "2026-11-30",
"label": "Sponsored",
"destinationUrl": "https://example.com/"
}

This is an illustrative schema. It does not represent a real advertiser or an active campaign.

The frontend could use this configuration to decide which placement to render and whether the campaign is within its scheduled dates.

The configuration should contain only information intended to be public. Credentials, payment secrets, private applications, and administrative tokens must never be placed in client-side files.

Why not build an advertising platform immediately?

A new project does not necessarily need real-time bidding, audience segmentation, an advertiser dashboard, or a sophisticated analytics pipeline.

Those systems increase implementation complexity and create additional security and privacy responsibilities.

A manually managed pilot can help answer the more important initial question: do suitable advertisers actually want this type of placement?

Infrastructure should grow in response to demonstrated demand rather than assumptions about future scale.

Security Boundaries Matter

One of the most important architectural lessons is that a public frontend cannot be trusted to enforce private business rules.

Suppose a campaign record contains:

{
"status": "approved"
}

That value is useful for rendering a public campaign, but it does not prove that an administrator approved the campaign. A user can modify client-side data and JavaScript in their own browser.

The real approval process must be enforced by the publishing workflow or a trusted backend.

A production implementation should account for:

Authentication for campaign administrators.
Authorization checks for approval and modification actions.
Server-side validation of campaign dates and destinations.
Protection against unauthorized campaign changes.
Secure handling of payment credentials.
A reliable mechanism to pause or withdraw a campaign.
Audit records for important administrative actions.

If a static file is updated manually, access to the repository and publishing process becomes part of the security boundary. A larger deployment should introduce an appropriate authenticated management service.

For a broader introduction to web application security, the "OWASP Cheat Sheet Series" (https://cheatsheetseries.owasp.org/) is a useful resource.

Privacy by Design

Privacy should influence the architecture before analytics and advertising scripts are added.

The initial design would aim to avoid behavioral advertising, cross-site tracking, and persistent personal advertising profiles.

Contextual selection

A campaign can be selected according to a predefined placement identifier:

function selectCampaign(campaigns, placement, now = Date.now()) {
return campaigns.filter((campaign) => {
if (campaign.status !== "approved") return false;
if (campaign.placement !== placement) return false;

const start = Date.parse(`${campaign.startDate}T00:00:00Z`);
const end = Date.parse(`${campaign.endDate}T23:59:59Z`);

return Number.isFinite(start) &&
  Number.isFinite(end) &&
  now >= start &&
  now <= end;

});
}

This example demonstrates basic filtering logic. It does not implement secure approval, campaign storage, payment verification, or a complete production advertising system.

Production code would also need to define time-zone semantics, validate campaign data, handle unavailable assets, and choose a deterministic display strategy when multiple campaigns match.

The key point is that placement selection can be based on the current page without requiring a visitor's personal profile.

Minimize external dependencies

Even without an advertising network, privacy risks can arise from third-party images, analytics libraries, destination websites, and hosting infrastructure.

A privacy review should examine network requests, cookies, browser storage, referrer behavior, server logs, and data-retention practices.

A static frontend is not automatically tracking-free. Privacy claims should be based on the system that is actually deployed and tested.

For implementation guidance, see the "MDN Web Security documentation" (https://developer.mozilla.org/en-US/docs/Web/Security).

Screening Advertisers and Destination Pages

Direct sponsorship offers greater control over advertising content, but it also creates a moderation responsibility.

A campaign should not be approved solely because its banner looks appropriate.

The proposed review process would examine:

The advertiser's identity and contact details.
The advertised product or service.
The wording and imagery.
The destination website.
Pricing, material conditions, and commercial claims.
Potential scams, misleading redirects, or unsafe payment flows.
Whether the campaign follows the publisher's published eligibility policy.

For SabrTime, the proposed policy would be informed by Islamic ethical principles and would exclude clearly unsuitable categories.

However, a publisher should not claim that every approved advertisement has received independent religious certification unless that certification genuinely exists.

Advertising approval is a review decision, not automatically a religious endorsement.

Campaigns should also be reviewed again if the destination page or advertised product changes materially after approval.

Make Commercial Content Explicit

A sponsored placement should never imitate an editorial recommendation or a religious resource.

The user interface should make the commercial relationship obvious.

For example:

Example Book Publisher

Explore the publisher's educational catalogue.

Visit advertiser

This is an illustrative HTML component, not an existing SabrTime production component.

In a real implementation, the card would also need accessible styling, appropriate link behavior, content validation, and a reliable process for managing campaign expiration.

The "rel="sponsored"" attribute identifies the commercial nature of the link. The "noopener noreferrer" attributes help control aspects of opening the destination in a new tab.

Google's guidance on "qualifying outbound links" (https://developers.google.com/search/docs/crawling-indexing/qualify-outbound-links) explains how paid links should be identified.

The sponsorship label should remain visible even when the card is styled to match the rest of the application.

Measuring Campaign Performance Without Individual Profiles

Advertisers need evidence that a placement is working. That does not mean every click must be connected to a persistent user identity.

A minimal reporting system could measure:

Aggregate impressions.
Aggregate clicks.
Campaign start and end dates.
Basic rendering errors.
Campaign renewals.
Moderation and approval outcomes.

Click-through rate is calculated as:

[
CTR = \frac{\text{Clicks}}{\text{Impressions}} \times 100
]

For example, 25 clicks from 1,000 measured impressions would produce a 2.5% click-through rate.

This is an illustrative calculation, not a measured result from the project.

The system must define what counts as an impression. A card being loaded is not necessarily equivalent to being visible to a user.

A small pilot could use aggregate event counts without retaining individual click histories. Any analytics implementation should still be reviewed for unnecessary identifiers, IP-address retention, third-party requests, and applicable privacy requirements.

What About Payments?

Payment processing should be treated as a separate, trusted component.

The browser must not be allowed to declare a campaign paid simply because a user reaches a success page or changes a client-side variable.

A production payment flow should verify payment status through the payment provider's trusted mechanisms and reconcile the result with the campaign record.

Other important requirements include:

Clear campaign pricing and duration.
Refund and cancellation terms.
Payment receipts and accounting records.
Protection of API secrets.
A process for disputed or failed payments.
Appropriate tax and consumer-law review.

A small pilot could begin with manually agreed sponsorships and controlled campaign publication before introducing an automated payment workflow.

The implementation choice should reflect the project's scale and available operational resources.

A Practical Development Roadmap

The proposed system can be developed incrementally.

Phase 1: Define the policy

Document eligible categories, prohibited content, review criteria, sponsorship labels, and privacy expectations.

Phase 2: Build the display component

Create an accessible sponsored card with a clear label, validated destination, and placement rules.

Phase 3: Introduce controlled publishing

Maintain an approved campaign configuration and restrict access to the publishing workflow.

Phase 4: Run a limited pilot

Test mobile layouts, keyboard navigation, campaign expiration, broken links, and the effect on essential application features.

Phase 5: Evaluate the evidence

Measure aggregate campaign performance, gather user feedback, and determine whether advertisers see enough value to continue.

Phase 6: Expand only when justified

If the pilot demonstrates demand, consider a secure administrative interface, campaign scheduling, payment reconciliation, and aggregate reporting.

This approach avoids investing prematurely in a large advertising platform before the underlying business model has been validated.

Applying the Approach to SabrTime

SabrTime is an Islamic PWA focused on duas, worship-related tools, and spiritual reflection.

Its proposed sponsorship model explores whether direct commercial support can help sustain free resources without making invasive tracking or intrusive advertising a requirement.

The intended principles are:

Essential worship features remain accessible.
Sponsored content is clearly identified.
Advertisers are reviewed before publication.
Commercial placements do not control religious editorial content.
Personal religious activity is not used to construct advertising profiles.
Campaign administration and payment processing receive appropriate security controls.

The sponsorship feature is a work in progress. These principles describe the intended design and should not be interpreted as proof that all the controls are already implemented.

Project reference: https://sabrtime.in/

Lessons for Independent Developers

The broader lesson is that monetization architecture should follow the product's values.

Before choosing an advertising provider or building an ad server, developers can ask:

What user data is actually necessary?
Can page context replace behavioral profiling?
Who approves commercial content?
How can paid links be disclosed?
What happens when a campaign becomes unsafe?
Which components require server-side enforcement?
What evidence would justify investing in a more complex platform?

The answers may differ across products, but making these decisions early can reduce unnecessary complexity later.

A static application can be a useful starting point for a small sponsorship pilot. A production commercial system still needs appropriate security, operational controls, and honest privacy disclosures.

Conclusion

Privacy-conscious sponsorship is not simply a matter of removing third-party advertising scripts.

It requires a deliberate approach to campaign selection, moderation, disclosure, data minimization, security, and commercial accountability.

The proposed SabrTime model explores a straightforward starting point: direct sponsorship, contextual placements, human review, and aggregate reporting.

The next step is to validate the model through a limited implementation and real feedback before investing in more complex infrastructure.

For independent developers, the most useful question may not be how many advertisements an application can display, but how it can generate sustainable revenue while preserving the trust of the people who use it.

Disclosure: This article was prepared with AI assistance and describes a proposed feature under development. It does not claim that the complete sponsorship system is deployed or that any advertiser has been independently halal-certified.

I Built DeenGuide: A Situation-Based Islamic Guidance Tool With an SEO-First Architecture

Yunus Khan — Sun, 13 Sep 2026 20:04:57 +0000

Most Islamic websites are organized around topics.

Prayer.
Fasting.
Duas.
Wudu.

But that's not necessarily how people think when they actually need help.

They usually arrive with a situation:

«“I have no water. What should I do?”»

«“I missed a prayer. How do I make it up?”»

«“I have doubts about my wudu.”»

«“Can I make dua in my own language?”»

«“How do I find the Qibla?”»

That observation became the starting point for DeenGuide, a situation-based Islamic guidance tool built as part of "SabrTime" (https://sabrtime.in/).

Live tool: "SabrTime DeenGuide" (https://sabrtime.in/tools/deenguide.html)

The goal wasn't to build another generic Islamic article library.

The goal was to build a structured system where a user can start with a real-life situation and reach clear, source-based guidance with as little friction as possible.

What Is DeenGuide?

DeenGuide is designed around a simple question:

“What are you dealing with?”

Instead of requiring users to understand complicated Islamic terminology first, DeenGuide lets them search or browse everyday situations.

The system is organized around areas such as:

Wudu & Purification
Salah
Fasting
Dua & Dhikr
Spiritual Life

A situation can then become its own dedicated resource.

Visit the "DeenGuide interface" (https://sabrtime.in/tools/deenguide.html) to see the current implementation.

Why Situation-Based Architecture?

Consider two approaches.

Traditional structure

Islamic Website
↓
Prayer
↓
Prayer Guide
↓
Various situations

The user has to discover the relevant section.

DeenGuide

DeenGuide
↓
Category
↓
Situation
↓
Guidance
↓
Sources
↓
Related resources

This is closer to how people actually search.

Someone may not search:

«“Islamic purification jurisprudence”»

They may search:

«“What if I have no water for wudu?”»

The difference is between topic intent and situation intent.

That distinction is central to the architecture.

The Main DeenGuide URL Is Only the Entry Point

The main "DeenGuide page" (https://sabrtime.in/tools/deenguide.html) isn't intended to be the entire knowledge base.

It acts as the navigation layer.

SabrTime
↓
DeenGuide
↓
Category
↓
Situation
↓
Detailed guidance
↓
Related SabrTime content

This creates a potential content graph rather than a collection of disconnected articles.

The same philosophy is used throughout the "SabrTime Blog" (https://sabrtime.in/blog/), where different Islamic topics are organized into supporting resources.

Situation Pages Can Become Search Resources

One of the most important technical ideas behind DeenGuide is that individual situations can have their own URLs.

For example:

/tools/deenguide/
↓
Category
↓
Situation
↓
Detailed answer
↓
Related situation
↓
Supporting article

This is important for both users and search engines.

A specific URL can represent a specific intent.

It also means that the project can grow without turning the main DeenGuide page into one enormous document.

Internal Linking Is Part of the Product

I don't see internal linking as just an SEO technique.

For DeenGuide, it is part of the UX.

Imagine a user looking for information about missed prayers.

The immediate DeenGuide answer can help them understand what to do.

But they may also need a deeper explanation.

That's where the SabrTime "Missed Prayers / Qaza guide" (https://sabrtime.in/blog/missed-prayers-qaza-guide.html) becomes useful.

The journey becomes:

User Situation
↓
DeenGuide
↓
Immediate Answer
↓
Deep Guide
↓
Related SabrTime Tools

This is much stronger than having an isolated blog post.

Building a Content Graph

The long-term architecture can look like this:

                     SabrTime
                        │
          ┌─────────────┴─────────────┐
          │                           │
      DeenGuide                      Blog
          │                           │
      Categories                  Deep Guides
          │                           │
      Situations ◄────────────────────┤
          │                           │
          └──────────┬────────────────┘
                     │
              Related Resources
                     │
                   Tools

This creates relationships between user situations, educational content and practical tools.

Instead of treating every page as an independent SEO asset, the objective is to build a connected information system.

Qibla Is a Good Example of the Architecture

Suppose someone searches:

«“Which direction is Qibla?”»

The short answer may be enough.

But another user may ask:

«“What is my exact Qibla degree?”»

Another may ask:

«“Does Qibla work without internet?”»

Another may ask:

«“Why is my phone compass pointing somewhere strange?”»

These are related but distinct intents.

SabrTime has supporting resources such as:

"How to Find Qibla Direction" (https://sabrtime.in/blog/qibla-direction-guide.html)
"Is Qibla East or West?" (https://sabrtime.in/blog/which-direction-is-qibla.html)
"Qibla Direction in Degrees" (https://sabrtime.in/blog/qibla-direction-degrees.html)
"Airplane Mode and Digital Qibla" (https://sabrtime.in/blog/airplane-mode-qibla-compass.html)

The Qibla content demonstrates why a connected content architecture can be more useful than one enormous article.

Prayer Content Can Form Another Cluster

The same model works for Salah.

DeenGuide can provide situation-based answers while deeper SabrTime resources handle specific topics.

Relevant supporting resources include:

"Missed Prayers / Qaza" (https://sabrtime.in/blog/missed-prayers-qaza-guide.html)
"Sujood as-Sahw" (https://sabrtime.in/blog/sujood-as-sahw-guide.html)
"Sajdah Tilawah" (https://sabrtime.in/blog/sajdah-tilawah-guide.html)
"Friday Sunnah Checklist" (https://sabrtime.in/blog/friday-sunnah-checklist.html)
"Adhan Meaning" (https://sabrtime.in/blog/adhan-meaning.html)

The architecture can become:

Salah
│
├── Missed Prayer
│ └── Qaza Guide
│
├── Prayer Mistake
│ └── Sujood as-Sahw
│
├── Quran Recitation
│ └── Sajdah Tilawah
│
└── Friday
└── Friday Sunnah

Dua Is Another Natural Knowledge Cluster

Dua questions are especially suitable for situation-based navigation.

A user may start with:

«“I'm anxious.”»

Then discover:

"Duas for Anxiety" (https://sabrtime.in/blog/duas-for-anxiety.html)
"Why Isn't My Dua Being Answered?" (https://sabrtime.in/blog/why-dua-not-answered.html)
"Can You Make Dua in English?" (https://sabrtime.in/blog/dua-in-english.html)
"How to Check If a Dua Is Authentic" (https://sabrtime.in/blog/how-to-verify-a-dua-is-authentic.html)
"Everyday Duas" (https://sabrtime.in/blog/everyday-duas.html)
"Dua for Parents" (https://sabrtime.in/blog/dua-for-parents.html)
"Istikhara" (https://sabrtime.in/blog/istikhara-guide.html)

This creates an important relationship:

Situation
↓
Relevant Dua
↓
Source Verification
↓
Deeper Explanation

Quran Content Creates Another Layer

SabrTime also has Quran-focused resources.

For example:

"Surah Al-Fatiha" (https://sabrtime.in/blog/surah-al-fatiha-meaning.html)
"Surah Al-Ikhlas" (https://sabrtime.in/blog/surah-al-ikhlas-meaning.html)
"Surah Al-Mulk" (https://sabrtime.in/blog/surah-al-mulk-meaning.html)
"Surah Al-Kahf" (https://sabrtime.in/blog/surah-al-kahf.html)
"Ayyub (AS) and the Cold-Water Story" (https://sabrtime.in/blog/ayyub-cold-water.html)

These can support situations involving prayer, patience, hardship, remembrance and Quranic reflection.

Tasbeeh and Dhikr Can Become Habit-Based Resources

Another interesting cluster is Dhikr.

SabrTime has supporting resources such as:

"How to Do Tasbeeh" (https://sabrtime.in/blog/tasbeeh-guide.html)
"Tasbeeh-e-Fatima" (https://sabrtime.in/blog/tasbeeh-e-fatima.html)
"Digital Tasbeeh Counter" (https://sabrtime.in/blog/digital-tasbeeh-counter.html)
"Daily Dhikr Habit" (https://sabrtime.in/blog/daily-dhikr-habit.html)
"Durood Tunajjina" (https://sabrtime.in/blog/durood-tunajjina.html)
"Durood on Friday" (https://sabrtime.in/blog/durood-friday.html)

This connects content with actual product functionality.

Article
↓
Learn
↓
Try
↓
SabrTime Tool
↓
Build Habit

The website isn't only explaining worship.

It can also provide tools for practicing it.

Product + Content Architecture

The larger SabrTime architecture can therefore become:

                     SabrTime
                        │
    ┌───────────────────┼───────────────────┐
    │                   │                   │
 DeenGuide             Blog               Tools
    │                   │                   │
Situations          Deep Guides        Prayer Times
    │                   │               Qibla
    │                   │               Tasbeeh
    │                   │               Reflection
    └───────────────────┼───────────────────┘
                        │
                      Ebooks

This means content, tools and guidance don't have to exist independently.

They can reinforce each other.

The Blog Should Support the Tool — Not Compete With It

This is one of the most important architectural decisions.

There should be a clear difference:

DeenGuide

“What should I do?”

Blog

“Help me understand this deeply.”

SabrTime tools

“Help me practice.”

That creates three different user intents.

WHAT DO I DO?
↓
DeenGuide

WHY / HOW DOES THIS WORK?
↓
Blog

HOW DO I PRACTICE IT?
↓
SabrTime Tools

Source Transparency

Islamic content has an additional trust requirement.

Users need to know:

“Where did this answer come from?”

DeenGuide explains its methodology and emphasizes source-based guidance.

The product also acknowledges legitimate differences of scholarly opinion instead of presenting every issue as if there is always only one possible position.

This creates:

Question
↓
Answer
↓
Source
↓
Verification

That is a critical part of the product.

DeenGuide Is Not a Fatwa Engine

This distinction is important.

DeenGuide is designed as a general educational guidance system.

It isn't intended to replace a qualified scholar.

For personal, complex or high-stakes religious questions, users should consult qualified local scholarship.

That gives the system a clear boundary:

DeenGuide
↓
General guidance
↓
Sources
↓
Context
↓
Scholar when necessary

This is a much better product boundary than pretending an automated system can replace Islamic scholarship.

Technical SEO Starts With Architecture

SEO isn't only about keywords.

For a system like DeenGuide, the bigger question is:

How are pages connected?

A possible architecture is:

Homepage
↓
DeenGuide
↓
Category
↓
Situation
↓
Related Situation
↓
Deep Guide
↓
Tool

This creates a semantic content graph.

Search engines can discover relationships.

Users can discover related answers.

And the site owner can understand how content clusters are developing.

Avoiding Programmatic SEO Spam

There is an obvious temptation here.

If 50 situation pages work, why not create 5,000?

That can become a problem.

The objective shouldn't be:

«Generate as many URLs as possible.»

It should be:

«Create a useful page when a real user has a distinct situation.»

A useful rule is:

Distinct user intent
+
Distinct useful answer
+
Reliable source
+
Navigation value
=
Potentially justified page

If two pages are practically identical, they probably don't need to exist as separate SEO pages.

Internal Link Quality Matters More Than Link Quantity

A page shouldn't contain 30 random internal links just because they are available.

Links should answer the next logical question.

For example:

Qibla question
↓
Qibla Direction Guide
↓
Exact Qibla Degrees
↓
Qibla Compass

Or:

Missed Prayer
↓
Qaza Guide
↓
Prayer Resources
↓
SabrTime Prayer Tools

The "SabrTime Blog" (https://sabrtime.in/blog/) provides many natural nodes for this type of contextual linking.

Mobile-First Architecture

SabrTime is designed around a mobile-first reality.

A situation page should ideally require:

minimal JavaScript
fast initial rendering
readable HTML
direct URLs
simple navigation
no unnecessary account wall
no intrusive advertising

The ideal journey is:

Open
↓
Understand
↓
Act

Not:

Open
↓
Wait
↓
Popup
↓
Login
↓
Navigate
↓
Find answer

Progressive Enhancement

A useful principle for DeenGuide is:

HTML first
↓
Content accessible
↓
JavaScript enhances experience

rather than:

JavaScript loads
↓
Application initializes
↓
Content appears

For an information-heavy product, keeping the core content accessible makes the architecture easier to crawl, share and maintain.

Technical SEO Checklist

If I scale DeenGuide to hundreds of situations, every page should eventually pass a checklist like this:

[ ] Unique URL
[ ] Unique title
[ ] Unique meta description
[ ] One clear H1
[ ] Clear search intent
[ ] Useful answer near the top
[ ] Detailed explanation where necessary
[ ] Source references
[ ] Scholarly differences identified
[ ] Parent category link
[ ] DeenGuide link
[ ] Related situation links
[ ] Relevant blog links
[ ] Relevant tool links
[ ] Canonical URL
[ ] Crawlable HTML
[ ] Mobile-friendly layout
[ ] Fast rendering
[ ] Valid structured data where appropriate
[ ] Sitemap inclusion when indexable
[ ] No accidental noindex
[ ] No orphan page
[ ] No broken internal links

For technical validation, useful resources include "Google Search Central" (https://developers.google.com/search), "Google Search Console" (https://search.google.com/search-console/about), "PageSpeed Insights" (https://pagespeed.web.dev/) and "Schema.org" (https://schema.org/).

Structured Data Should Describe Reality

Structured data can help machines understand a page.

Depending on the actual content, potential types can include:

WebPage
Article
BreadcrumbList
FAQPage

But schema should describe content that genuinely exists on the page.

It shouldn't be used as a ranking shortcut.

The actual page content, information architecture, internal links, performance and source quality remain fundamental.

Search Console Can Become a Product Research Tool

One of the most interesting future possibilities is using search data to discover new situations.

Suppose Search Console shows queries such as:

what if I have no water for wudu
can I pray with a bandage
forgot how many rakah
missed salah what to do
can I make dua in english
qibla without internet

These aren't just SEO keywords.

They are product requirements.

The workflow becomes:

Search Query
↓
User Problem
↓
Potential Situation
↓
DeenGuide Page
↓
Supporting Guide
↓
Tool / Action

This turns SEO data into product research.

The SabrTime Content Graph

At scale, the architecture could look like this:

                       SabrTime
                          │
         ┌────────────────┼────────────────┐
         │                │                │
     DeenGuide           Blog             Tools
         │                │                │
     Situations       Deep Guides      Prayer Times
         │                │             Qibla
         │                │             Tasbeeh
         │                │             Reflection
         └────────────────┼────────────────┘
                          │
                        Ebooks

And individual content clusters can look like:

         QIBLA
           │
   ┌───────┼────────┐
   │       │        │
Basic    Degrees   Compass
   │       │        │
Region   Cities   Offline
   │       │        │
   └───────┼────────┘
           │
       Qibla Tool

Or:

         SALAH
           │
   ┌───────┼─────────┐
   │       │         │
 Missed  Mistakes   Friday
   │       │         │
 Qaza    Sahw      Sunnah
   │       │         │
   └───────┼─────────┘
           │
      Prayer Tools

Reflection and Sharing Can Add Another Layer

SabrTime also has a reflection-oriented product direction.

That introduces another possible user journey:

Situation
↓
Guidance
↓
Reflection
↓
Reflection Card
↓
Share
↓
Return to SabrTime

The important technical principle is that the shareable artifact should point back to its canonical SabrTime resource.

That makes social sharing a distribution layer rather than creating disconnected content.

Ebooks Can Become the Long-Form Layer

SabrTime also has an ebook layer, including:

"The Sabr Handbook" (https://sabrtime.in/e-books/the-sabr-handbook.html)
"New Muslim Starter Guide" (https://sabrtime.in/e-books/new-muslim-starter-guide.html)

This creates another level:

Quick Situation
↓
DeenGuide
↓
Detailed Blog Guide
↓
Long-form Ebook

Not every user needs the deepest level.

But users who do want more can continue naturally.

The Architecture Can Eventually Support Hundreds of Situations

Imagine:

5 major categories
↓
50 situations
↓
200 situations
↓
500 situations

The goal isn't to end up with:

500 isolated URLs

The goal is:

Category
↕
Situation
↕
Related Situation
↕
Deep Guide
↕
Tool
↕
Reflection

That is what makes the architecture scalable.

The Biggest Lesson

The biggest lesson from building DeenGuide isn't a particular meta tag or schema property.

It's architecture.

A useful web product needs three things working together:

User Intent
+
Information Architecture
+
Technical SEO

If one is missing, the system becomes weaker.

A technically perfect website with poor information architecture is difficult to use.

A useful product with poor crawlability is difficult to discover.

And a highly optimized website without genuinely useful content has nothing worth ranking for.

The Bigger Idea Behind DeenGuide

DeenGuide isn't really just a collection of Islamic answers.

Technically, it can become a:

Situation → Guidance → Source → Action knowledge graph.

The architecture can eventually look like:

              USER SITUATION
                    │
                    ▼
             ┌─────────────┐
             │  DeenGuide  │
             └──────┬──────┘
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
    SOURCES     SITUATIONS     GUIDES
       │            │            │
       └────────────┼────────────┘
                    ▼
              SabrTime Tools
                    │
                    ▼
                Reflection
                    │
                    ▼
                 Sharing

The long-term objective isn't to create the largest number of pages.

It's to create the most useful connections between real-life questions, trustworthy sources, practical guidance and supporting resources.

That's the technical foundation I'm building DeenGuide on.

SabrTime Resource Map

Main Product

"SabrTime" (https://sabrtime.in/)
"DeenGuide" (https://sabrtime.in/tools/deenguide.html)
"SabrTime Blog" (https://sabrtime.in/blog/)
"SabrTime SEO Tools" (https://sabrtime.in/seo-tools/)
"SabrTime Ebooks" (https://sabrtime.in/e-books/)

Prayer
-Missed Prayers / Qaza
-Sujood as-Sahw
-Sajdah Tilawah
-Friday Sunnah
-Adhan

Prayer Category
-Qibla
-Qibla Direction Guide
-Is Qibla East or West?
-Qibla Direction in Degrees
-Airplane Mode Qibla

Dua
-Duas for Anxiety
-Why Dua Isn't Answered
-Dua in English
-Dua Authenticity
-Everyday Duas
-Dua for Parents
-Istikhara

Quran
-Surah Al-Fatiha
-Surah Al-Ikhlas
-Surah Al-Mulk
-Surah Al-Kahf
-Ayyub (AS) and the Cold-Water Story

Tasbeeh & Dhikr
-Tasbeeh Guide
-Tasbeeh-e-Fatima
-Digital Tasbeeh Counter
-Daily Dhikr Habit
-Durood Tunajjina
-Durood on Friday

Long-Form Resources
-The Sabr Handbook
-New Muslim Starter Guide

Technical References
-Google Search Central
-Google Search Console
-PageSpeed Insights
-Schema.org
-MDN Web Docs
-web.dev

Final Takeaway

The interesting part of DeenGuide isn't simply that it answers Islamic questions.
The interesting part is the architecture behind it:

REAL-LIFE SITUATION
↓
DEENGUIDE
↓
SOURCE-BASED ANSWER
↓
RELATED SITUATION
↓
DEEP SabrTime GUIDE
↓
PRACTICAL TOOL
↓
REFLECTION
↓
SHARE

That turns SabrTime from a collection of pages into a connected Islamic information and utility system.
And that's the direction I'm continuing to build toward.
SabrTime: sabrtime.in
DeenGuide: sabrtime.in/tools/deenguide.html

webdev #seo #technicalseo #javascript #html #pwa #webperformance #informationarchitecture #islamictech #buildinpublic #productdevelopment

How We Built an SEO System for a Small Website Using AI, Content Clusters & Technical SEO

Yunus Khan — Tue, 01 Sep 2026 10:06:49 +0000

When you launch a new website, SEO can feel like shouting into an empty room.

You publish an article.

Nothing happens.

You publish another.

Still nothing.

That was one of the challenges we faced while building SabrTime, a free Islamic digital companion focused on prayer, reflection, consistency, and useful Islamic tools.

Instead of treating SEO as simply "write more blog posts,"
We started building a repeatable system around technical SEO, search intent, content clusters, internal linking, and AI-assisted content production.

This is the workflow we are using and the lessons that can be adapted to almost any small website.

Start With the Website, Not the Blog

One of the biggest mistakes a new website can make is creating dozens of blog posts before understanding what the website actually offers.

We first looked at:

Website structure
Existing pages
Search intent
Important features
Existing content
Sitemap
Metadata
Internal links
Indexability
Structured data
Open Graph information
Canonical URLs

SabrTime isn't only a blog.

It is a web-based Islamic companion with tools and resources around prayer, Qibla, Tasbeeh, spiritual habits, and Islamic learning.

That meant the SEO strategy could connect informational content with actual useful tools.

The main website acts as the hub:

SabrTime → Tools → Resources → Blog → Educational content

This structure gave us many opportunities to build topical relevance.

You can explore the project here: "SabrTime" (https://sabrtime.in/).

Focus on Search Intent Instead of Just Keywords

Instead of targeting only highly competitive terms such as:

Islamic app
Prayer app
Quran app

we started looking at specific problems users might actually search for.

For example:

How to find Qibla direction
Does airplane mode affect a Qibla compass?
How to pray missed prayers
What does Adhan mean?
How to do Tasbeeh
What is the Qibla direction for a city?
How to build a daily Dhikr habit

These queries have much clearer intent.

For example, we created location-specific and educational Qibla resources rather than writing one generic article and stopping there.

The important part isn't simply putting a keyword into an article.

The article needs to actually solve the user's problem.

Build Content Clusters Instead of Random Articles

Instead of publishing unrelated articles, we started grouping content into topics.

For example, a Qibla content cluster can include:

Qibla

→ How to Find Qibla Direction
→ Qibla Direction in Degrees
→ Qibla Direction by City
→ Airplane Mode & Digital Qibla Compass
→ History of the First Qibla

For example, our "Qibla Direction in Dallas" (https://sabrtime.in/blog/qibla-direction-dallas-tx.html) article focuses specifically on the Qibla direction for Dallas.

We also created content around "airplane mode and Qibla compasses" (https://sabrtime.in/blog/airplane-mode-qibla-compass.html).

These aren't random articles.

They're different pieces of content supporting the same broader topic.

This approach can be used for almost any niche.

A fitness website could create:

Fitness

→ Home workouts
→ Beginner workouts
→ Push-up guide
→ Squat guide
→ Workout recovery

A SaaS website could create:

Email Marketing

→ Email marketing guide
→ Email subject lines
→ Open rates
→ Email automation
→ Newsletter strategy

The principle is the same:

«Build topical depth instead of publishing random keywords.»

AI Helped Us Scale the Content Workflow

Claude became particularly useful in our content-development workflow.

But we didn't simply tell AI:

«"Write me an SEO article."»

Instead, we used a structured process.

Topic

↓

Search intent

↓

Research

↓

Article structure

↓

How I Diagnosed and Fixed Keyword Cannibalization Between Two Nearly-Identical Blog Posts

Yunus Khan — Wed, 26 Aug 2026 15:48:01 +0000

I thought publishing more useful content would automatically give my website more opportunities to rank.

Then I noticed something uncomfortable.

Two articles on my site were covering almost the same subject.

Both were useful.
Both were properly indexed.
Both answered similar questions.
And both were competing for overlapping search intent.

I had accidentally created a small SEO architecture problem inside my own blog.

I'm building "SabrTime.in" (https://sabrtime.in/), a small Islamic companion app focused on practical digital tools for everyday worship. As a solo developer, I also manage the website, content, SEO, and product development myself.

While working on the site's content, I published two articles around Tasbeeh:

How to Do Tasbeeh — A Complete Guide
Digital Tasbeeh Counter: How It Works & Why Muslims Are Switching

The first article is about the practice itself.

The second is supposed to be about the technology and use case of digital Tasbeeh counters.

Sounds different enough, right?

At first, I thought so too.

But when I looked at the actual content and search intent, the overlap became obvious.

The Problem Wasn't Duplicate Content

This is where SEO gets misunderstood.

Keyword cannibalization doesn't necessarily mean you have two pages containing identical paragraphs.

The more interesting problem is intent overlap.

If two URLs are trying to satisfy essentially the same searcher's question, a search engine has less information about which page should be the primary result.

For example, imagine these two pages:

/page-a
"How to Do Tasbeeh"

/page-b
"Digital Tasbeeh Counter"

Their titles are different.

But if both pages explain:

what Tasbeeh means
how many times to recite it
common Tasbeeh counts
the same hadith
how to count Tasbeeh
why Muslims use a counter
FAQs about Tasbeeh

...then the distinction between the pages starts becoming blurry.

That was happening on my site.

The two articles were not technically duplicates.

But parts of their search intent were duplicates.

And that distinction matters.

How I Found It

I didn't start by running an expensive SEO crawler.

I started with the simplest question:

«"Why do I have two pages that could answer the same searcher's question?"»

I compared the pages manually.

Then I looked at the queries and pages appearing in Google Search Console.

The useful report here is:

Search Console → Performance → Search results → Queries → Pages

If you investigate a particular query and discover multiple URLs receiving impressions for it, that's worth investigating.

It doesn't automatically prove cannibalization.

Google can legitimately rank multiple pages from the same site for one query.

But when those pages also have highly overlapping content and intent, you've got a stronger signal that your information architecture needs work.

The Two Pages Had Different Jobs — But I Hadn't Made That Clear Enough

This was the key realization.

The solution wasn't simply:

«"Delete one article."»

The solution was:

«Give each article a clearly different job.»

I defined the two pages like this.

Page 1 — The Practice

Primary intent:

«How do I perform Tasbeeh correctly?»

This page should answer questions about the Islamic practice itself.

It can cover:

Meaning of Tasbeeh
Correct method
Common counts
Tasbeeh after Salah
Tasbeeh Fatima
Common mistakes
Relevant Islamic references
Building a consistent dhikr habit

This is the educational/pillar page.

Page 2 — The Tool

Primary intent:

«How does a digital Tasbeeh counter work, and should I use one?»

Now the content becomes more product and technology oriented.

It can cover:

What a digital Tasbeeh counter is
Physical vs digital counters
How a phone counter works
Advantages and limitations
Offline functionality
Privacy considerations
Tracking repetitions
When a digital counter is useful
How SabrTime implements the feature

The article still needs enough Islamic context to be useful.

But it shouldn't become another complete guide to Tasbeeh.

That's the important distinction.

I Removed Unnecessary Overlap

This was probably the most useful part of the exercise.

I went through the overlapping sections and asked:

«"Does this information belong here because it helps this page's primary intent, or am I including it because it's another keyword opportunity?"»

Those are very different reasons.

If a section existed only because I thought:

«"This keyword might help the page rank."»

I questioned it.

For example, the digital counter article doesn't need a massive standalone explanation of every aspect of performing Tasbeeh.

That's already the job of the Tasbeeh guide.

Instead, I can briefly explain the relevant concept and link to the detailed guide.

Conceptually:

Tasbeeh Guide
│
│ explains the practice
▼
Digital Tasbeeh Counter
│
│ explains the technology
▼
SabrTime Counter

Now the pages support each other instead of competing with each other.

Internal Linking Became More Important

Once I had separated the intent, internal links became much more meaningful.

Instead of randomly linking between articles, I could establish a relationship.

Tasbeeh guide → Digital counter

«If you prefer counting dhikr digitally, here's how digital Tasbeeh counters work.»

And:

Digital counter → Tasbeeh guide

«Before using a digital counter, learn the traditional method and recommended Tasbeeh practices.»

Now the relationship is obvious.

One page explains the practice.

The other explains the tool.

That's much cleaner than having two pages both trying to be the complete answer.

I Didn't Immediately Canonicalize One Page

Canonicalization was one of the first technical solutions I considered.

But I didn't want to use a canonical tag as a shortcut for a content architecture problem.

If two pages have genuinely different purposes, blindly canonicalizing one to the other can throw away useful search opportunities.

So my approach was:

Identify overlapping intent.
Decide which page owns the broader topic.
Give the second page a narrower purpose.
Remove unnecessary overlap.
Improve internal linking.
Monitor Search Console.
Only consider stronger consolidation if the pages still don't have a meaningful distinction.

In other words:

Fix the information architecture before reaching for a technical directive.

The Interesting Part: This Is Basically Refactoring

As a developer, this way of thinking made the problem much easier.

Imagine I had two functions:

function tasbeehGuide() {
// explains Tasbeeh
// explains counts
// explains methods
// explains how to count
}

function digitalTasbeehCounter() {
// explains Tasbeeh
// explains counts
// explains methods
// explains how to count
// explains digital counting
}

That's a code smell.

The functions have overlapping responsibilities.

You'd probably refactor them.

SEO content can have the same problem.

Instead of thinking:

«"I need another article targeting another keyword."»

Think:

«"What responsibility does this URL own?"»

That mental model changed how I approached my blog.

My New Rule for Creating Content

Before publishing another article, I now ask five questions.

What exact question does this page answer?

Not:

«"What keyword am I targeting?"»

But:

«"What does the searcher actually want?"»

Do I already have a URL answering this?

Search the existing site before creating a new article.

If I already have one, what is genuinely different here?

If the answer is just:

«"The title is different."»

That's probably not enough.

Can I describe the difference in one sentence?

For example:

«"This article explains Tasbeeh."»

versus:

«"This article explains digital Tasbeeh counters."»

If I can't clearly articulate the distinction, the pages probably aren't differentiated enough.

Where should the new article fit in my site's information architecture?

A blog shouldn't just be a collection of URLs.

It should behave more like a knowledge graph.

Related pages should have relationships.

What I'm Watching Now

I don't consider the problem "fixed" simply because I edited the pages.

SEO changes need to be measured.

I'm watching:

Which URL receives impressions for broader Tasbeeh queries
Whether the digital-counter page gains visibility for tool-related searches
Whether the Tasbeeh guide retains its educational queries
CTR changes
Average position
New queries appearing for each page
Whether impressions become less fragmented between the two URLs

The important thing is that I'm not expecting an overnight result.

The goal isn't:

«"Make one URL rank #1."»

The goal is:

«Make it obvious which URL should rank for which intent.»

That's a much more sustainable strategy.

What I Learned as a Solo Developer

The biggest lesson wasn't actually about SEO.

It was about content architecture.

When you're building alone, it's incredibly easy to think about every article independently:

«"This seems like a useful topic. I'll write it."»

Then six months later, you have 30 articles that individually look fine but collectively overlap.

That's exactly like accumulating technical debt.

A little duplication doesn't look dangerous.

But eventually:

Article A ──┐
├── overlapping intent
Article B ──┘

becomes a problem you have to untangle.

So now I'm treating SEO content more like software architecture.

Every URL needs a responsibility.

Every important topic needs a clear primary page.

Related pages should support each other rather than competing unnecessarily.

The Bigger Lesson

If you have a small website and your rankings aren't behaving the way you expect, don't immediately assume you need more backlinks, more articles, or more keywords.

Sometimes the problem is simpler:

You may have already written the answer — twice.

Before publishing your next article, search your own website.

Look at the existing URLs.

Compare their titles, headings, FAQs, and search intent.

Then ask:

«"If I were Google, which of these two pages would I consider the better answer?"»

If the answer isn't obvious, that's probably your next SEO task.

I'm still experimenting with this on "SabrTime.in" (https://sabrtime.in/), but this change has already altered how I plan content.

I don't want to build a blog with hundreds of pages.

I want to build a site where every page has a reason to exist.

And, like good code, good content architecture should make the system easier to understand — not harder.

The pages behind this experiment

"SabrTime.in" (https://sabrtime.in/) — the Islamic app I'm building
"Digital Tasbeeh Counter" (https://sabrtime.in/blog/digital-tasbeeh-counter.html) — the technology/tool-focused article
"Tasbeeh Guides" (https://sabrtime.in/blog/tasbeeh-guides.html) — the practice/educational side

If you're also building a content-heavy product as a solo developer, I'd be interested to know:

Have you ever discovered two of your own pages competing for the same search intent?

seo #webdev #indiedev #buildinpublic #devto

How I Built an Offline-First Qibla Compass for a PWA Without an Internet Connection

Yunus Khan — Sun, 09 Aug 2026 12:14:35 +0000

When you're travelling, one of the simplest problems can become surprisingly difficult: finding the Qibla direction without an internet connection.

I wanted to solve this problem while building SabrTime, an Islamic PWA focused on making everyday worship tools available with minimal dependencies, no mandatory login, and an offline-first experience.

The result was an offline-capable Qibla compass that can calculate the direction toward the Kaaba using the device's location and orientation sensors.

Why Offline Qibla Matters
Most web applications assume that the user has an active internet connection.

That isn't always true.

A person may be:

Travelling by airplane
In an area with poor network coverage
Abroad without mobile data
Inside a building with unreliable connectivity
Using airplane mode

A Qibla tool shouldn't necessarily stop being useful just because the network disappears.

This led me to an important design principle:

«Calculate what can be calculated locally, and use the network only when it is actually necessary.»

The Basic Architecture

The Qibla calculation itself doesn't require a server.

The basic flow is:

Device Location
↓
Latitude + Longitude
↓
Calculate Bearing to Kaaba
↓
Device Orientation Sensor
↓
Calculate Relative Direction
↓
Display Qibla Compass

The Kaaba's geographic coordinates are fixed, so the application can calculate the bearing locally once it knows the user's latitude and longitude.

Calculating the Bearing to the Kaaba

The first step is determining the initial bearing between the user's location and the Kaaba.

For two points on Earth, we can use the following formula:

const lat1 = userLatitude * Math.PI / 180;
const lat2 = kaabaLatitude * Math.PI / 180;

const deltaLon =
(kaabaLongitude - userLongitude) * Math.PI / 180;

const y = Math.sin(deltaLon) * Math.cos(lat2);

const x =
Math.cos(lat1) * Math.sin(lat2) -
Math.sin(lat1) * Math.cos(lat2) * Math.cos(deltaLon);

let bearing = Math.atan2(y, x);

bearing = bearing * 180 / Math.PI;
bearing = (bearing + 360) % 360;

The resulting value represents the initial compass bearing toward the Kaaba.

This is useful because the calculation happens entirely on the device.

There is no need to send the user's coordinates to a remote API simply to calculate a direction.

Getting the User's Location

The browser's Geolocation API can provide the user's current coordinates.

A simplified implementation looks like this:

navigator.geolocation.getCurrentPosition(
(position) => {
const latitude = position.coords.latitude;
const longitude = position.coords.longitude;

calculateQibla(latitude, longitude);

},
(error) => {
console.error("Unable to get location:", error);
}
);

Of course, a production application needs to handle permission denial, unavailable location data, low accuracy, and other edge cases.

Using Device Orientation

Knowing the Qibla bearing isn't enough for a compass interface.

We also need to know which direction the device is facing.

Modern browsers can expose device orientation information through sensor APIs, although implementation details and permission requirements can vary between browsers and operating systems.

The basic concept is:

Qibla Bearing
-
Device Heading
=
Relative Qibla Direction

For example, if the Qibla bearing is 280° and the device is currently facing 250°:

280° - 250° = 30°

The UI can then tell the user that the Qibla is approximately 30° to the right.

The Difficult Part: Sensors Are Messy

This sounds straightforward until you actually test it on physical devices.

A compass isn't perfectly stable.

The readings can be affected by:

Magnetic interference
Metal objects
Device hardware
Sensor noise
Indoor environments
Browser differences
Device calibration
Rapid device movement

So a good compass interface shouldn't simply trust one sensor reading.

Instead, the application needs to smooth readings and provide clear visual feedback.

Handling Sensor Noise

One simple approach is to maintain a rolling set of readings and smooth the result.

For example:

const readings = [];

function smoothHeading(newHeading) {
readings.push(newHeading);

if (readings.length > 10) {
readings.shift();
}

return readings.reduce((sum, value) => sum + value, 0)
/ readings.length;
}

This is only a basic example. Circular values such as 359° and 1° require special handling because a normal arithmetic average can produce incorrect results.

That's an important lesson when working with compass data:

Angles aren't ordinary numbers.

Building It as a PWA

The next challenge was making the experience work even when connectivity disappears.

A Progressive Web App can cache the application's static resources so that previously loaded functionality remains available offline.

The architecture becomes:

          ┌───────────────┐
          │    PWA UI     │
          └───────┬───────┘
                  │
    ┌─────────────┴─────────────┐
    ↓                           ↓

Local calculations Cached resources
↓ ↓
Qibla bearing Offline interface
↓
Device sensors
↓
Qibla direction

The key idea is that the compass calculation doesn't need a continuous internet connection.

Privacy Was Another Design Goal

Location data is sensitive.

For an Islamic utility like a Qibla compass, I wanted the architecture to minimize unnecessary data transmission.

If the calculation can happen locally, there is little reason to send the user's exact coordinates to a remote server merely to determine a bearing.

This is one reason I prefer a privacy-first, client-side approach wherever practical.

What About Airplane Mode?

This is where the offline-first approach becomes particularly useful.

With network connectivity disabled, a PWA can still provide functionality that doesn't depend on an external server.

The important distinction is:

Offline does not mean “everything works without hardware or permissions.”

The application may still require:

Previously cached application resources
Location permission
Device location capability
Orientation sensors
Browser support

The goal is to remove the unnecessary dependency on the internet, not to magically bypass device requirements.

Testing on Real Devices

One of the biggest lessons from this project was that browser-based sensor applications should be tested on actual phones.

A feature can appear perfect in desktop development tools but behave differently on a physical device.

I recommend testing:

With Wi-Fi enabled
With mobile data disabled
In airplane mode
Indoors
Outdoors
After rotating the device
On multiple browsers where possible

This catches problems that aren't obvious during normal development.

What I Learned

Building this feature taught me that an offline-first web application isn't simply about adding a service worker.

It requires thinking about the entire dependency chain.

For every feature, ask:

«Does this actually need the internet?»

If the answer is no, move the computation to the client whenever practical.

For a Qibla compass, this means location + mathematical calculation + device sensors can do most of the work locally.

The SabrTime Implementation

I built this approach into SabrTime, an Islamic PWA that includes prayer tools, Qibla, Islamic resources, and other everyday worship utilities.

You can explore the project here:

SabrTime: https://sabrtime.in/

I also documented the Qibla approach in more detail in this article:

Airplane Mode Qibla Compass: https://sabrtime.in/blog/airplane-mode-qibla-compass.html

If you're interested in the broader problem of maintaining useful Islamic tools while travelling, I also wrote about "missed prayers and Qaza" (https://sabrtime.in/blog/missed-prayers-qaza-guide.html) and practical guidance around making up missed Salah.

Final Thoughts

The web doesn't always need to depend on the cloud.

For many utility applications, calculations can happen directly on the user's device. This can improve:

Offline reliability
Privacy
Performance
Resilience
User experience

The Qibla compass was a good example of this principle.

Instead of asking a server:

«“Where is the Qibla from this location?”»

the phone can calculate the answer itself.

That small architectural decision makes the feature much more useful when the user is travelling — precisely when a Qibla compass may be needed most.

I'm continuing to experiment with offline-first and privacy-focused web development while building SabrTime, and I'll be sharing more of the technical lessons from the project.

What Google Search Console Is Teaching Me as a Solo Developer

Yunus Khan — Sat, 01 Aug 2026 07:29:13 +0000

When I launched SabrTime, I expected Google to discover my pages quickly.

That didn't happen.
Today, only 13 pages of my website are indexed,people are already discovering my content through Search.
Instead of chasing shortcuts, I've started trusting the data.

My Search Console Snapshot
Over the last few months, I've seen:
✅ 13 pages indexed
📈 Search impressions growing month after month
🔍 Hundreds of search queries triggering my pages
🌍 Visitors finding content from different countries
📱 Most traffic coming from mobile devices

That was enough to convince me that SEO is a long-term investment.

Lesson 1: Impressions Matter Before Clicks
One thing I misunderstood was impressions.
At first, I only cared about clicks.
Now I pay close attention to impressions because they tell me Google is beginning to understand my website—even if users aren't clicking yet.
Every impression is a sign that my content is entering the search ecosystem.

Lesson 2: Unexpected Keywords Are Opportunities
Some of my pages started appearing for search queries I never intentionally targeted.
That helped me discover new content ideas and improve existing pages around topics users were already searching for.
Instead of guessing what people want, I now let Search Console guide my content strategy.

Lesson 3: Technical SEO Matters
While reviewing Search Console, I found several technical issues that needed attention:
Improving internal links
Fixing indexing problems
Updating meta titles and descriptions
Making pages easier for Google to crawl
None of these changes created overnight success, but together they improved the health of my website.

Lesson 4: Publishing Consistently Beats Publishing Perfectly
Rather than waiting for the "perfect" article, I focused on publishing useful content consistently.
Every quality page becomes another opportunity for Google to understand what your website is about.

What I'm Working Toward
My next goals are simple:
Increase indexed pages beyond 13
Continue improving Core Web Vitals
Earn relevant backlinks naturally
Publish content people genuinely find useful
SEO isn't about gaming the algorithm.
It's about building something worth discovering.

Final Thoughts
I'm still at the beginning of my SEO journey, but Google Search Console has completely changed how I think about building websites.
The data has helped me stop guessing and start making better decisions.
If you're also building a website, what has Google Search Console taught you?

About My Project
I'm applying these lessons while building SabrTime, a privacy-focused Islamic web app with prayer times, Qibla direction, duas, an ibadah tracker, tasbeeh, and other daily Islamic tools.

🌐 https://sabrtime.in⁠�

Hello Dev Community! I'm Yunus Khan

Yunus Khan — Sat, 18 Jul 2026 08:13:34 +0000

👋 Assalamu Alaikum and hello everyone! 👋

My name is Yunus Khan, an independent developer from India who enjoys building products that solve real problems and make technology more meaningful.

My current passion project is SabrTime—a free Islamic web app designed to help Muslims stay connected with their faith through modern technology.

🌐 Try SabrTime: https://sabrtime.in

🌙 What is SabrTime?

SabrTime is more than just a prayer app. It's an all-in-one spiritual companion featuring:

🕌 Accurate Prayer Times
🧭 Qibla Compass
📿 Digital Tasbeeh Counter
🤲 Mood-Based Duas
📖 Prayer & Dua Library
📅 Islamic Calendar
📈 Ibadah & Streak Tracker
🧠 Islamic Quiz
🌍 Multi-language support

I'm constantly adding new features and improving the experience based on community feedback.

The project is also open source, and I'd love to hear your suggestions or contributions.

⭐ GitHub: https://github.com/Kyunus175/sabrtime

💻 What I'll Share Here

On Dev.to, I'll write about:

My web development journey
Building and scaling SabrTime
JavaScript, HTML, CSS, Firebase, and PWAs
SEO and performance optimization
Lessons learned while developing as a solo developer
Open-source experiments and side projects

I'm excited to learn from this amazing community, share my experiences, and connect with developers from around the world.

Thank you for reading my first post! If you have any feedback about SabrTime or ideas for future features, I'd love to hear them in the comments.

🌐 Website: https://sabrtime.in
⭐ GitHub: https://github.com/Kyunus175/sabrtime

webdev #javascript #pwa #opensource #indiedev #devjourney