DEV Community: Hashir WebX Studio

What WhatsApp's Cloud API forces you to design before you send a single reminder

Hashir Khan — Thu, 05 Nov 2026 09:04:05 +0000

I thought the hard part of a reminder app would be the user interface. Turns out the hard part is everything that needs to happen before the first reminder can even get sent out.

Why I'm building this

People don't forget to pay for their subscriptions. They forget to cancel them. The idea was to have the reminder show up in the right place, a couple days in advance, when I can still cancel the payment.

It turned into RenewChime: a WhatsApp-first subscription tracker. Default currency is PKR and everything is managed via a chat.

What I built

Next.js (App Router), TypeScript, Tailwind
Supabase for Auth, Postgres and Row Level Security
Subscriptions CRUD, dashboard, analytics and reminders screen
Rule-based chat bot (add Netflix 1500 PKR monthly 5th, list, upcoming, paid Netflix, snooze Netflix 2d)
Cron route that finds due reminders and sends them

Status, honestly: the whole flow works end to end on a mock provider. The Cloud API provider is written behind the same interface but isn't tested against Meta yet. I'm still getting a test number and templates approved.

How it's structured

1. One provider interface. The app never talks to WhatsApp directly.

interface WhatsAppProvider {
  sendTemplate(to: string, template: string, params: string[]): Promise<void>;
  sendText(to: string, text: string): Promise<void>;
  verifySignature(rawBody: string, headers: Headers): boolean;
}

A mock implementation is the default. The real one is selected with an env var. That's what let me build the whole product before Meta approved anything.

2. Consent is data, not a checkbox. whatsapp_contacts stores opted_in_at, opted_out_at and last_inbound_at. The cron skips any contact without a recorded opt-in, and STOP sets opted_out_at immediately.

3. Templates vs free text. A business can't start a conversation with free text. Reminders go out as pre-approved templates:

Hi {{1}}, your {{2}} subscription ({{3}} {{4}}) renews on {{5}}.
Reply PAID, SNOOZE or CANCEL.

Free-form replies are only allowed within 24 hours of last_inbound_at. This also bit me with verification codes: a number that has never messaged you has no open window.

4. Claim before you send. Two overlapping cron runs shouldn't double-send. Instead of check-then-send, each run claims a row atomically (simplified):

update reminders
set claimed_at = now()
where id = $1 and status = 'queued' and claimed_at is null
returning id;

Only the run that gets a row back sends. Failed sends retry after 5 and 15 minutes, then are marked failed.

5. The webhook trusts nothing. It verifies X-Hub-Signature-256 against the raw body with a timing-safe compare, and dedupes inbound messages by provider message ID.

What I'd have shipped without noticing

Month-end renewals: a subscription on Jan 31 has to roll to Feb 28, not March 3.
Money stored as integer minor units, converted only for display.
Quiet hours and timezones: reminders outside 9am to 9pm local time move to the next window.

Result

Working today: add, pause, cancel and mark-paid via UI or chat, reminders scheduled at 7, 3 and 1 day, atomic sending, and Row Level Security tested with two users. Next: real delivery through the Cloud API.

Live: https://renewchime.vercel.app
GitHub: comment "Chime" I'll send it to you

Final thoughts

The platform's constraints turned out to be product design in disguise. Opt-in, templates and the 24-hour window are annoying to build around, but they're exactly what keeps a reminder from feeling like spam.

Should I break down the reminder engine in a follow-up? Want the provider layer as a small open-source package? And what should I build next?

I Built a Full SaaS-Style WhatsApp Subscription Management System, Here's How

Hashir Khan — Wed, 10 Jun 2026 08:50:46 +0000

Most subscription tools are complex, overpriced, and ignore how small businesses actually operate.
In Pakistan and across emerging markets, businesses manage subscriptions through WhatsApp. Not emails. Not portals. WhatsApp.
So I built a complete frontend system around that exact workflow.

Why I Built This

While working as a Frontend Engineering Intern at Peham LTD, I kept noticing the same gap: businesses needed a clean way to manage subscriptions tied to WhatsApp-based communication workflows.
Existing SaaS dashboards are built for enterprise. They assume complex CRMs, payment APIs, and dedicated ops teams.

But a local gym, a newsletter creator, or a service business running on WhatsApp? They need something simpler — and more focused.

I wanted to build a real SaaS-style product that solved this specific problem. A system with a proper landing page, an admin dashboard, and a workflow that maps to how these businesses actually communicate with their users.

What I Built

WhatsApp Subscription Management System — a complete frontend SaaS application with two core parts:

🏠 Landing Page

Clean, conversion-focused hero section
Feature highlights explaining the WhatsApp-first workflow
Pricing section
Call-to-action flows
Fully responsive across all screen sizes

📊 Admin Dashboard

Subscription overview and stats
Subscriber list with status management (active, paused, cancelled)
WhatsApp message workflow triggers
Clean UI with intuitive navigation
Mobile-responsive layout

Tech Stack

React.js — component-based architecture
Modern CSS — responsive, utility-first styling
React Router — client-side navigation between landing and dashboard
Component composition — reusable UI elements across views
Vercel — deployed and live

🔗 Live Demo: whatsappsubscriptionmanagementsyste-flax. vercel.app

How I Built It — The Breakdown

Landing Page Architecture The landing page was designed as a standalone marketing surface. I separated it from the dashboard routing intentionally — different goals, different component trees.

Key sections:

HeroSection — above-the-fold hook with CTA
FeaturesGrid — card-based feature breakdown
Pricing Section — tiered plan layout
Footer — links and brand close

Each section is a standalone component. Easy to update independently without touching unrelated UI.

2. Admin Dashboard Structure

The dashboard follows a classic SaaS layout pattern:

Fixed sidebar with navigation
Top bar with context and user info
Main content area with dynamic views

I built the subscriber management table as a controlled component with local state, cleanly handling status filters, row actions, and empty states.

3. WhatsApp Workflow UI

This is the most unique part of the system. Instead of generic "send email" buttons, the workflow UI is built around WhatsApp actions — message triggers tied to subscription lifecycle events (onboarding, renewal reminder, cancellation confirmation).
Each trigger maps to a clear UI state. No backend yet — but the frontend is structured to plug into a WhatsApp API layer (like Twilio or Meta's Cloud API) without a rebuild.

4. Responsive Design Strategy

I used a mobile-first approach throughout:

Sidebar collapses to a hamburger on mobile
The subscriber table becomes a card list on smaller screens
Landing page sections stack cleanly on all breakpoints

No UI library — custom responsive components. More control, less bloat.

Result & What I Learned:

The system is live and fully functional as a frontend application.
What I got out of this build:

✅ Deeper understanding of SaaS dashboard architecture in React
✅ Cleaner thinking about component separation and responsibility
✅ Hands-on experience designing around real-world workflows (not textbook features)
✅ Confidence in building landing page + dashboard as one cohesive product

The biggest shift was thinking like a product engineer rather than just a UI developer. Every component decision is tied back to: Does this serve the user's actual workflow?

Final Thoughts:

Frontend engineering isn't just about shipping UI — it's about building systems that fit how people actually work.
This project pushed me to design around a specific, real use case. Not a generic CRUD app. A product that understands its users communicate through WhatsApp, not email, and builds the entire experience around that.
That kind of thinking — workflow-first, not feature-first — is what I want to carry into every project I build at Hashir WebX Studio.

Let's Talk 💬

🔗 Live Demo

Want the source code? Drop a comment, and I'll share the GitHub link.
Should I break down the WhatsApp workflow architecture in a dedicated post?
What kind of SaaS dashboard should I build next — open to ideas from the community.

Built by Hashir WebX Studio — React.js • Next.js • TypeScript • SaaS UI Engineering