Forem: DevTECH

I Built an AI Islamic Companion App. Here's What Actually Surprised Me

DevTECH — Thu, 14 May 2026 09:12:11 +0000

Building for a faith-based audience is the same as building for any other audience.
Just ship fast, iterate, repeat.
That's what I thought before I started MyTazki an AI-powered Islamic
companion PWA with Quran audio, Duas, prayer times, a Qibla compass, AI dhikr
sessions, and push notifications for Adhan. Six months and 35+ features later,
here are the technical decisions that genuinely surprised me for better

and worse.

1. Contract-First API Changed Everything (and I Almost Skipped It)

The most impactful DX decision in the project wasn't the AI stack or the database
choice. It was writing the OpenAPI spec first and generating everything from it.
Here's the flow:

lib/api-spec/openapi.yaml
↓ (pnpm --filter @workspace/api-spec run codegen)
lib/api-client-react/src/generated/api.ts ← React Query hooks
lib/api-zod/src/generated/api.ts ← Zod validators

Orval reads the spec and generates type-safe React Query hooks and Zod schemas
in one command. The server validates inputs with the generated Zod schemas. The
frontend calls the generated hooks. If the contract changes, a single codegen run
propagates it everywhere TypeScript screams at every inconsistency before a
single test runs.
Before this, I was hand-writing fetch() calls, manually keeping types in sync,
and debugging a mismatch between what the server sent and what the client expected.
After? I haven't written a raw fetch() on the frontend in four months.
The lesson: **the five hours you spend writing the OpenAPI spec saves you fifty

hours of type drift.**

2. I Used a Key-Value Store Instead of PostgreSQL — No Regrets

MyTazki runs on @replit/database, a simple key-value store. No schema migrations.
No SQL. No connection pooling. Just get, set, and list.
That sounds naive for a production app, but here's the reality: every entity that
would live in a relational table maps cleanly to a key pattern:

user:{userId} → profile object
streak:{userId} → { currentStreak, totalDays, lastCheckin }
push:{userId} → subscription object
aiUsage:{userId}:{date} → number (daily AI call count)
duas:{duaId} → dua object
sessions:{sessionId} → session object

The gotcha is the return type. db.get() returns OkResult | ErrResult — not the
value directly. Every single read needs:


typescript
const result = await db.get(`user:${userId}`);
const user = result.ok ? result.value : null;

Forget that check and you're silently working with an error object that looks truthy.
I forgot it exactly twice. Both times were memorable.

The real limitation is joins. When you need "all duas favorited by user X," you
either store an index (favs:{userId} → [duaId, duaId, ...]) or do a full scan.
For a prayer app at this scale, that trade-off is acceptable. For anything with
complex relational queries, it's a pain.

3. The iOS Safari Audio Hack No One Writes About
The Quran reader plays 114 surahs with per-ayah audio from everyayah.com. Each
ayah is a separate .mp3 file in the format SSSAAA.mp3 (surah + ayah, zero-padded).

On desktop Chrome: trivial. Create an Audio element, update src on each ayah,
call play(). Works perfectly.

On iOS Safari: the moment you update audio.src and call play(), Safari
treats it as a new user-initiated play event — and blocks it, because iOS requires
audio to be triggered directly by a user gesture. Autoplay restrictions apply to
every new src assignment.

The fix: one persistent Audio element, never replaced — only src swapped.

// Created once, at component mount  never recreated
const audioRef = useRef(new Audio());
function playAyah(surah: number, ayah: number) {
  const src = `https://everyayah.com/data/Alafasy_128kbps/
    ${String(surah).padStart(3,'0')}
    ${String(ayah).padStart(3,'0')}.mp3`;
  audioRef.current.src = src;
  void audioRef.current.play(); // Works — iOS sees this as continuation
}

The first play() call must happen inside a user gesture handler (a tap). After
that, swapping src and calling play() on the same element inherits that
gesture permission for the session. Destroying and recreating the Audio element
resets the permission.

This took me a day and a half to figure out. Saving you the half.

4. AI Rate Limiting in a KV Store  Simpler Than You Think
The AI companion routes through Anthropic's Claude. Without rate limiting, one
motivated user could burn through significant API credits in an afternoon. The
solution is 20 AI requests per user per day, tracked with a single KV key:

const dateKey = new Date().toISOString().split('T')[0]; // "2026-05-14"
const usageKey = `aiUsage:${userId}:${dateKey}`;
const result = await db.get(usageKey);
const count = result.ok ? Number(result.value) : 0;
if (count >= 20) {
  return res.status(429).json({ error: "Daily AI limit reached. Resets at midnight." });
}
await db.set(usageKey, count + 1);
// ... call Claude

Keys naturally expire with the date — no cron job needed to clean up. Today's key
is aiUsage:user123:2026-05-14. Tomorrow it's aiUsage:user123:2026-05-15. The
old key just sits there taking up negligible space until you decide to clean it.

5. Qibla Compass: Web APIs Are Wilder Than I Expected
The Qibla page shows a compass needle pointing toward Mecca. The math is
straightforward — a great-circle bearing from the user's coordinates to
(21.4225° N, 39.8262° E). The Web part is where it gets interesting.

The Web Magnetometer API (DeviceOrientationEvent + webkitCompassHeading on
iOS) gives you the device's heading relative to magnetic north. Android exposes
DeviceOrientationEvent.alpha (rotation around Z-axis). But:

iOS requires HTTPS and explicit permission (DeviceOrientationEvent.requestPermission())
only available in a user gesture handler.
Android Chrome exposes the API but many mid-range devices have poor magnetometer
calibration  the needle drifts.
Desktop browsers mostly return null for magnetometer data.
The fallback chain I settled on:

GPS bearing (always available) → show Qibla direction on map
+ Magnetometer (when available) → animate live compass needle
+ Calibration prompt when accuracy is low → "Wave your phone in a figure-8"

The figure-8 calibration prompt was the most-commented feature in user feedback.
Turns out most people have never calibrated their phone compass and find it
genuinely surprising that this is a thing.

6. Push Notification Scheduling Is a Scheduler Problem
Prayer times differ by location. Fajr in London in January is 7:14 AM. In Karachi
in June, it's 4:02 AM. You can't pre-schedule notifications — you have to compute
them fresh for each user, each day, from their stored coordinates.

The approach: a scheduler loop running every 60 seconds on the API server, checking
whether any prayer time falls within the next minute for any subscribed user:

setInterval(async () => {
  const subscribers = await getAllPushSubscribers(); // list prefix scan
  for (const { userId, subscription, preferences } of subscribers) {
    const user = await getUser(userId);
    const times = await getPrayerTimes(user.lat, user.lon);
    for (const prayer of PRAYERS) {
      if (!preferences[prayer]) continue;
      const prayerTime = times[prayer]; // e.g. "05:23"
      if (isWithinOneMinute(prayerTime)) {
        await sendPushNotification(subscription, {
          title: `${prayer} time`,
          body: `It's ${prayerTime} — time for ${prayer} prayer`,
        });
      }
    }
  }
}, 60_000);

The cold-start problem: if the server restarts at 5:22 and Fajr is at 5:23, the
first tick runs at 5:22:00 and sends the notification. If the restart takes more
than 60 seconds, you miss the window. For a prayer app, missing Fajr is bad UX.
The mitigation: start the interval with an immediate first tick (setImmediate +
setInterval), and log all misses for monitoring.

7. The Cultural UX Layer Is a Real Engineering Problem
Every technical decision in an Islamic app has a cultural dimension that isn't
obvious until you're building it.

Arabic RTL: React renders fine with dir="rtl", but flexbox reverses
direction in unintuitive ways. Every flex container near Arabic text needs explicit
direction management. I standardized on Amiri (font-family: "Amiri, serif") for
all Arabic text — it renders Quranic Arabic with correct diacritics and ligatures.
Using a generic serif font for Quranic text is visually wrong in a way that users
notice immediately.

Hijri calendar: The Hijri date doesn't map 1:1 to Gregorian — it's a lunar
calendar that shifts by ~11 days per year. I use aladhan.com for both prayer
times and Hijri date conversion. Trying to calculate this locally is a rabbit hole
I'm glad I didn't go down.

Tasbih counter: A simple counter with a haptic feedback tap. Sounds trivial.
The UX constraint: it must work with one hand while sitting in prayer. No accidental
resets. Every interaction must be deliberate. The reset button is hidden behind a
long-press, not a tap. Users asked for this explicitly.

Gender-neutral Duas: Some duas in classical Arabic are grammatically gendered.
For a library of 110+ duas, deciding which to include, how to present gender
variants, and whether to show transliteration by default required real product
thinking — not just copy-paste from an API.

What I'd Do Differently
Start with SSR or a static shell. The SPA approach means search crawlers that
don't execute JavaScript see an empty <div id="root">. I added a pre-render
trick (H1 inside #root that React replaces on mount) but proper SSR or
prerendering would have been cleaner from day one.

Use Postgres earlier. The KV store got me to v1 fast, but the index management
complexity starts compounding around feature #15. A lightweight Postgres setup
from the start would have been worth the initial overhead.

Design the push notification UX before the infrastructure. The scheduler was
fun to build. Designing the permission request flow — when to ask, what to say,
how to handle denial gracefully — took longer than the scheduler itself.

The Stack, For Reference
Frontend: React + Vite, TypeScript 5.9, Tailwind CSS, pnpm workspaces
Backend: Express 5, @replit/database (KV), JWT auth, bcryptjs
AI: Anthropic Claude via API proxy
Push: web-push, VAPID, 60s scheduler loop
API Design: OpenAPI spec → Orval → React Query hooks + Zod schemas
Build: esbuild (CJS bundle for the server)
MyTazki is live at mytazki.com — free, no credit card,
works on any device as a PWA. If you're building for underrepresented communities
or faith-based audiences, I'm happy to answer questions in the comments.

How I Built an AI-Native Islamic Growth Platform Optimized for SEO, GEO & AI Search

DevTECH — Tue, 12 May 2026 10:48:09 +0000

The Problem

Most Islamic apps today still look and behave like utility tools from 2018.

They focus on:

prayer times
Quran reading
Qibla direction
static dua collections
donation-driven experiences

But almost nobody is building:

AI-native Islamic experiences
emotional wellness systems
guided Islamic growth journeys
semantic SEO ecosystems
AI-search optimized platforms
retention-focused Muslim lifestyle products

That gap is exactly why I started building MyTazki.

What Is MyTazki?

MyTazki is an AI-first Muslim lifestyle platform focused on:

Quran reflections
guided Islamic journeys
Azkar and duas
emotional wellness
Islamic habits
AI-powered spiritual growth

The goal was not to build another Islamic utility app.

The goal was to build:

"Calm + Duolingo for Muslim spiritual growth."

The Biggest Shift: GEO Instead of Traditional SEO

Most websites still optimize only for Google search rankings.

I decided to optimize MyTazki for:

Google AI Overviews
ChatGPT retrieval
Perplexity citations
conversational AI systems
semantic search
voice search

This is where GEO (Generative Engine Optimization) becomes important.

Instead of writing pages only for humans or keywords, the site architecture is designed for:

AI retrievability
semantic clustering
topical authority
conversational intent
structured knowledge graphs

Semantic SEO Architecture

Instead of random blog posts, the platform uses semantic SEO silos.

Main clusters include:

Emotional Wellness
Salah & Prayer
Quran Reflections
Islamic Habits
AI Islamic Companion

Each cluster contains:

hub pages
supporting articles
journey funnels
related content graphs
FAQ schema
speakable schema
conversational search formatting

The result:

A deeply connected Islamic semantic knowledge graph.

GEO Optimization Strategy

Every page contains:

AI summary blocks
conversational questions
FAQ sections
structured schema
semantic relationships
short-answer formatting

Example queries targeted:

"Can Islam help anxiety?"
"How do I reconnect with Allah?"
"What dua helps overthinking?"
"How can I build Islamic habits?"

This dramatically improves:

AI citations
retrieval quality
semantic relevance
long-tail visibility

Internal Linking Became the Real SEO Moat

One of the biggest realizations:

Modern SEO is no longer about isolated pages.

It is about:

semantic relationships
crawl architecture
entity understanding
contextual linking
topical depth

So every page inside MyTazki links contextually into:

emotional wellness pages
Quran reflections
guided journeys
routines
AI experiences

This creates a semantic web instead of a content library.

AI-Native User Experience

Another major focus was emotional UX.

Most Islamic apps overload users with:

cluttered dashboards
generic gold Islamic UI
too many features
weak onboarding

I wanted MyTazki to feel:

calm
minimal
emotionally safe
modern
reflective

Closer to:

Calm
Headspace
Notion

than traditional religious utility apps.

Building a Freemium Islamic Product

One difficult challenge:

How do you monetize respectfully?

The solution was:

Free = Islamic knowledge remains accessible
Premium = personalization, AI guidance, routines, and deeper experiences

Premium features include:

AI Islamic companion
guided journeys
habit tracking
emotional wellness systems
journaling
AI reflections
personalized routines

The subscription layer is designed around:

retention
emotional consistency
guided growth

not aggressive SaaS upsells.

Tech Stack

Current stack:

React
TypeScript
Node.js
Express
PostgreSQL
Razorpay subscriptions
Semantic JSON-LD schema
GEO-focused rendering

Built entirely with:

Replit
AI-assisted workflows
iterative semantic architecture

Biggest Lessons Learned

1. AI Search Is Real

Traffic is increasingly coming from:

AI summaries
conversational search
semantic retrieval
recommendation systems

Building for AI retrieval early creates a major advantage.

2. Emotional Intent Beats Generic Keywords

These keywords are brutal:

Islamic app
Quran app
Muslim app

But emotional long-tail intent is massively under-served.

Examples:

how to reconnect with Allah
best dua for anxiety
Islamic routine for peace
how to stop missing salah

Those are much stronger acquisition channels.

3. Internal Linking Is Everything

A semantic content graph outperforms disconnected blog spam.

Especially for:

AI search
topical authority
GEO
crawl depth
engagement

What’s Next

Current focus areas:

subscription system
AI personalization
emotional journey infrastructure
retention systems
backlinks
social SEO loops
AI citation optimization

The long-term goal is to build:

the default AI-native Muslim growth platform.

Final Thought

I think the next generation of successful products will not just be:

SEO optimized
visually polished
feature rich

They will be:

emotionally intelligent
AI retrievable
semantically structured
retention focused
deeply personalized

That is the direction I’m trying to push with MyTazki.COM

Would love feedback from other builders working on:

AI products
semantic SEO
GEO optimization
wellness apps
faith-tech
retention systems

Thanks for reading.

My co-founder got PCOS. So I quit my job and built a meal planning app for 100 million Indian women.

DevTECH — Wed, 22 Apr 2026 08:27:32 +0000

So this is a bit of a long one. Grab chai.

About two years ago, Priya — my co-founder and the person who basically stress-tests everything I build — got diagnosed with PCOS. Not shocking on its own, 1 in 5 Indian women has it. What was shocking was what happened next.

Her doctor handed her a printed sheet. A diet plan. It said things like "avoid refined carbs" and "eat low-GI foods." That's it. No context. No recipes. No mention of the fact that she grew up eating idli and sambar every morning, that her mum cooks with coconut oil, that she doesn't have 90 minutes to make something from a wellness blog written by someone in California.

She googled "PCOS diet plan India." Got 40 tabs of conflicting advice. Some said no rice. Some said brown rice is fine. One said drink fenugreek water at 6am. She tried three different apps. None of them knew what Ragi Dosa was.

She asked me — the one who supposedly knows about software — "why doesn't something like this exist?"

I didn't have a good answer. So I started building.

The thing I got wrong first

My first instinct was to build a calorie tracker. That was stupid. Nobody wants to log every meal. That's not a product, that's homework.

What Priya actually needed was someone to just... tell her what to cook. Specifically. For her body. With food she already knows how to make.

That reframe changed everything. This wasn't a tracking app. It was a decision app. Every morning it answers one question: "Aaj kya banau?" — What should I cook today?

What I actually built

MealCoreAI is a progressive web app that generates a full 7-day Indian meal plan — breakfast, lunch, snack, dinner — tailored to your health condition. Not "Indian food" in a vague sense. Ragi dosa. Bajra roti. Moong dal. Palak paneer. Real food that real Indian families cook.

We cover 7 health tracks: PCOS, Diabetes, Thyroid, Pregnancy, Kids, Fitness, and General. Each one has completely different dietary rules baked in.

For PCOS, that means low-GI, high-protein, no deep-fried stuff — because insulin resistance is the core driver of most PCOS symptoms and you can genuinely move the needle through food.

For Thyroid, it means being careful about cruciferous vegetables — most people don't know that eating too much gobi (cauliflower) can interfere with thyroid medication. The app just... handles that. You don't need to know the science.

For Pregnancy, we strip out anything that's risky — papaya, raw eggs, certain high-mercury fish — while making sure every day hits iron, folate and calcium targets. Because that stuff matters more than macros when you're 20 weeks in.

The technical part (skip if you just want the story)

The hardest thing wasn't the AI. It was the dish database.

I spent two weeks just building a database of 55 Indian dishes with full nutritional data and health flags. Every dish has columns like pcos_safe, diabetes_safe, thyroid_safe, pregnancy_safe. These aren't guesses — I worked through them with a nutritionist.

The reason this matters: when you ask GPT-4 to "generate a PCOS meal plan," it will confidently give you dishes that have no nutritional backing, make up calorie counts, and occasionally recommend something that's actively bad for the condition. I've seen it recommend bhatura for a diabetic. Bhatura!

My fix was to constrain the AI to only choose from our validated dish IDs. It doesn't generate meal names — it picks dish IDs from a numbered list. The AI becomes a smart selector, not a free-form generator. Hallucinations dropped to basically zero.

The stack is React 19 + Vite on the front, Express 5 on the back, PostgreSQL with Drizzle ORM, and OpenAPI 3.1 as the single source of truth for the API. Orval auto-generates the React Query hooks from the spec, which means I never manually write API client code. When the spec changes, one command regenerates everything.

The whole thing is open source: github.com/InoxxAIsource/mealmate

Push notifications — the thing that took three restarts

I wanted the app to actually remind you to cook at meal time. Not "Hey, don't forget to log your meal!" — I hate those. I wanted it to say "Lunch time! Today you're making Moong Dal + Bajra Roti." Your actual meal. By name.

Web Push on Android is fine. iOS nearly broke me.

On iOS, push notifications only work in Safari 16.4 or higher, and only when the app is added to the Home Screen. Not when it's open in a browser tab. Not when it's running as a bookmark. Actually installed to the Home Screen.

Getting users to do that is a UX problem. So I built a custom bottom sheet that detects whether you're on iOS, whether you've already installed it, and shows you step-by-step instructions with the actual Safari share button icon. It only appears once — if you dismiss it, it doesn't come back for 30 days. Because if there's one thing worse than a bad feature it's a naggy one.

When the scheduler fires (it runs every 30 seconds and checks the time), it pulls the user's active meal plan, finds today's dish for that meal slot, and sends a notification with the actual dish name. That specificity is what makes people leave notifications on.

What surprised me

The feature people use most isn't the AI generation. It's the Swap button.

Nobody follows a meal plan perfectly. You open the fridge on a Tuesday morning and the one thing the plan calls for isn't there. So you tap Swap, and the AI instantly replaces just that one meal while leaving the rest of the week untouched.

That single interaction — swap one meal, keep everything else — made the product feel alive instead of rigid. It went from "a plan you're supposed to follow" to "a plan that adapts to you." Which is what it should be.

Where it's at today

The app is live at mealcoreai.com. Free tier gives you a 7-day plan, grocery list, nutrition tracking and AI chat. Pro is ₹499/month or ₹2,999/year.

The sitemap has 282 pages. Lighthouse is 97/96/100/100. It's been indexed by Google for about 48 hours.

We're pre-revenue but post-product. If you have PCOS, diabetes, are pregnant, or are raising kids in India and want to try it — genuinely free, no credit card, no email sequences from me.

If you're building for India (or any market that isn't SF)

The generic advice is always "build for the user you know." But most of us building software are building for users who look like us — people with fast internet, English as a first language, and food habits from a Western diet.

1.4 billion people don't fit that profile.

The opportunity isn't to copy Noom and translate it to Hindi. It's to start from scratch with the actual constraints of real Indian life: shared family meals, regional cuisines that differ wildly, health conditions that are dramatically more prevalent than in the West, and real people who just want to know what to cook for dinner without a 45-minute deep dive into nutrition science.

That's what I'm trying to build. Slowly. One swap button at a time.

Code is at github.com/InoxxAIsource/mealmate — React 19, Express 5, Drizzle ORM, OpenAPI codegen, VAPID push, the works. Proper README with setup instructions. MIT licensed.

Ask me anything in the comments. Happy to go into the AI prompt architecture, the iOS push hell, or why I chose Drizzle over Prisma.

How to Calculate Cricket Arbitrage: The Maths Behind Guaranteed Profits

DevTECH — Fri, 17 Apr 2026 14:44:16 +0000

Most people who discover cricket arbitrage betting make the same mistake — they understand the concept immediately but then reach for a spreadsheet to do the stake calculations. By the time they've typed in the odds and formulas, the window has closed.

I've been building CricketArb for the past few months, and one of the most common questions I get is: how do I actually calculate what to stake on each side?

Let me break down the exact maths, then point you to the free tool that does it live as you type.

The Core Formula

For a two-outcome match:

Arb% = (1 / Odds_A) + (1 / Odds_B)

If Arb% is below 1.00 (100%), you have an arbitrage opportunity. Profit margin = 1 - Arb%.

Real IPL 2026 example:

Bet365: CSK to win @ 2.10
Betfair: MI to win @ 2.05

Arb% = (1/2.10) + (1/2.05) = 0.4762 + 0.4878 = 0.9640

That's 3.6% guaranteed profit regardless of result.

Stake Allocation

You don't split 50/50. You allocate proportionally so both outcomes return the same amount.

With ₹10,000 total stake:

Stake_A = 10000 × (1/2.10) / 0.9640 = ₹4,940
Stake_B = 10000 - 4940 = ₹5,060

Verification:

Bet365: ₹4,940 × 2.10 = ₹10,374
Betfair: ₹5,060 × 2.05 = ₹10,373

Both return ₹10,373 → guaranteed ₹373 profit on ₹10,000 stake.

Why Manual Calculation Fails in Practice

During live IPL, odds move every few seconds. By the time you've opened a spreadsheet, one of three things has happened: the window closed, you made an error under pressure, or you staked the wrong amount on one side.

This is why I built the cricket arbitrage calculator — it recalculates on every keystroke, shows you the arb percentage live, and generates a Telegram-ready summary you can paste instantly.

3-Way Arbs (Test Cricket / Draw Markets)

Arb% = (1/Odds_A) + (1/Odds_Draw) + (1/Odds_B)

Same rule: below 100% = sure bet. The calculator handles 3-way arbs with a single toggle.

The Polymarket Edge

Pure bookmaker vs bookmaker arbs are increasingly rare. The real edge is cross-platform arbs between traditional bookmakers and prediction markets.

Polymarket prices cricket outcomes in cents (52¢ = 52% implied probability). Their trader base is crypto-native, not cricket-native. When a wicket falls during an IPL powerplay, Bet365 reprices in under 5 seconds. Polymarket can take 30-60 seconds. That lag is where the best windows open.

More detail in the full cricket arbitrage calculator guide — includes worked IPL 2026 examples and a walkthrough of every calculator output metric.

If "sure bet" is the terminology you know, that guide is also covered at sure bet calculator for cricket — same maths, additional PSL examples.

Try It

Free calculator (live recalculation): https://cricketarb.com/calculator
Live scanner terminal: https://cricketarb.com/terminal
Telegram signals: t.me/cricedge
GitHub: github.com/InoxxAIsource/cricedge-arb-scanner