DEV Community: Faizullah

Building a Website for a Language Institute: Designing for Trust, Not Just Clicks

Faizullah — Fri, 19 Jun 2026 08:13:21 +0000

By Faiz Ullah — Full-Stack Developer & Founder of DG Technology

Most websites I build need to convert a visitor into a click — sign up, add to cart, download. Chinova Institute, a Chinese-language institute offering classes, HSK exam prep, translation, interpretation, and visa consultancy, needed something different: it needed to convert a visitor into trust before they'd ever pick up the phone.

That difference shaped almost every decision I made building it.

Education Sites Sell Credibility, Not Just Information

An e-commerce site can lean on product photos and price tags to do the persuading. An institute site has to persuade with something harder to fake: evidence that the people behind it are real and qualified.

That's why the site is built around a dedicated founder page rather than burying credentials in an "About Us" paragraph. A prospective student deciding whether to commit to months of language classes wants to know who is teaching, what their background is, and why they're credible — not just a feature list of "course types offered."

Structuring Content for Multiple, Different Intents

A single visitor to an institute site might be there for any of several very different reasons:

A student wanting weekly Chinese classes
Someone prepping specifically for the HSK proficiency exam
A business needing a one-off translation or interpreter
Someone navigating a visa process tied to travel or work in China

Cramming all four into one generic "Services" list undersells each one. Instead, I treated them as distinct service categories, each described in its own terms — a language learner and a business needing certified translation are evaluating completely different things, and the copy needs to speak to each separately rather than using one generic pitch for everyone.

Why Open Graph Tags Matter More Than People Think

Institute and consultancy websites get shared constantly — in WhatsApp groups, Facebook community pages, forwarded links between friends deciding where to study. If the link preview that shows up is broken or generic, that referral — often the highest-trust kind of lead there is — gets wasted.

I made sure every key page had proper Open Graph metadata with dedicated preview images:

<meta property="og:image" content="og-image.png">
<meta property="og:title" content="Chinova Institute — Learn Chinese in Islamabad">

The founder page even gets its own preview image (og-founder.png) distinct from the main site — because when someone shares "check out this guy's profile," the preview should show the person, not a generic logo.

Performance as a Trust Signal

For a site like this, I skipped frameworks and build tooling entirely — plain HTML, CSS, and a small amount of vanilla JavaScript. Partly for simplicity, but also because a slow-loading institute site quietly undermines its own credibility. If the page that's supposed to convince someone you're a serious, professional operation takes three seconds to paint, that's working against you before a single word of copy is even read.

What I'd Tell Someone Building a Service/Consultancy Site

Lead with the people, not just the service list. Trust-based businesses convert on credibility, not features.
Don't force unrelated service types into one generic pitch. Separate audiences need separate framing, even on the same page.
Treat link-preview metadata as part of the conversion funnel, not an afterthought — shared links are often your highest-trust traffic.
Keep the stack as light as the content allows. Speed is itself a credibility signal for this category of site.

The Stack

Layer	Technology
Structure	Semantic HTML5
Styling	Custom CSS3
Interactivity	Vanilla JavaScript
SEO	Sitemap, robots.txt, full Open Graph metadata

Faiz Ullah
Full-Stack Developer · Founder of DG Technology
🌐 faizullah.pk · 💻 github.com/faizullahpk/chinova-institute

Building a site for a trust-based business — education, consultancy, or professional services? Follow along — I write about the practical decisions behind real client websites.

I Built a Full E-Commerce Store With Zero Frameworks — Here's What I Learned

Faizullah — Fri, 19 Jun 2026 08:10:23 +0000

By Faiz Ullah — Full-Stack Developer & Founder of DG Technology

Every e-commerce build I'd done before reached for React almost by reflex. So when I built JKMart — a grocery and pansar (spice/herb) store — I deliberately went the other way: no framework, no build step, no dependencies. Just HTML, CSS, and vanilla JavaScript.

It forced me to relearn fundamentals that frameworks quietly hide from you. Here's what stood out.

State Management Without a Framework

React trains you to think "state lives in a component, re-render on change." Without that abstraction, you have to build the same discipline by hand. I centralized everything — products, categories, cart, site settings — into one structured data store, and treated every UI update as "read from the store, write back to the store, re-render the affected DOM section."

const store = {
  products: [...],
  cart: [],
  addToCart(id) {
    this.cart.push(id);
    renderCart(); // explicit, not automatic
  }
};

The difference from React: nothing happens automatically. Every single re-render is a function you call yourself. It's more typing, but it also means there's no mystery about why something on screen updated — you can trace it line by line.

The Cart Has to Survive a Refresh

A cart that empties itself when the customer accidentally refreshes the page is a lost sale. With no backend session and no framework state layer, persistence comes down to localStorage directly:

function saveCart() {
  localStorage.setItem('cart', JSON.stringify(store.cart));
}
function loadCart() {
  store.cart = JSON.parse(localStorage.getItem('cart') || '[]');
}

It's a small thing, but it's the kind of detail that separates a demo from something that actually works the way a shopper expects.

Search That Feels Instant

Live product search needs to filter as the user types, not after they hit Enter. The naive version re-filters the entire product list on every keystroke, which is fine for a small catalog but teaches a bad habit. I built it to debounce input and search across multiple fields (name, category, tags) at once, so it stayed fast and felt forgiving of partial or imprecise queries.

Depth Without a 3D Library

I wanted product cards to feel tactile — a subtle tilt that responds to the cursor, the kind of detail that makes a static catalog feel alive. Rather than reaching for a 3D library, this is just trigonometry on mouse position relative to the card's center:

card.addEventListener('mousemove', (e) => {
  const rect = card.getBoundingClientRect();
  const x = (e.clientX - rect.left) / rect.width - 0.5;
  const y = (e.clientY - rect.top) / rect.height - 0.5;
  card.style.transform = `perspective(800px) rotateY(${x * 10}deg) rotateX(${-y * 10}deg)`;
});

No dependency, no bundle size cost — just a few lines of CSS transform math.

An Admin Panel That's Also Just HTML

The admin panel — product management, category editing, site settings — is built the exact same way as the storefront: vanilla JS reading and writing the same data store, just rendering a different UI on top of it. There's no separate "admin framework." It's the same toolkit, pointed at a different audience.

When Not Reaching for a Framework Actually Makes Sense

This isn't an argument that frameworks are bad — for an app with deep nested state and dozens of interacting components, React earns its complexity. But for a focused storefront like this:

Zero build step means the entire site is editable and previewable by just opening the file
Zero dependencies means no npm audit surprises, no version upgrades breaking things a year later
Instant load — there's no JS bundle to download and parse before the page becomes interactive

For a project of this scope, that trade-off was worth it.

What I'd Tell Someone Building Their First Vanilla JS Project

Centralize your state into one object, even without a framework forcing you to. Scattered global variables are where bugs breed.
Persist anything the user would be annoyed to lose — cart contents, form drafts — to localStorage immediately, not just on submit.
Debounce expensive operations like search filtering, even in a small app. It's a habit worth having by default.
Don't assume you need a library for interaction polish. A lot of "wow" details are a few lines of math.

The Stack

Layer	Technology
Structure	Semantic HTML5
Styling	Custom CSS3, gradients & animations
Logic	Vanilla JavaScript (ES6+)
Persistence	`localStorage`
Build	None

Faiz Ullah
Frontend Developer · Full-Stack Engineer · Founder of DG Technology
🌐 faizullah.pk · 💻 github.com/faizullahpk/ecommerce-store-demo

Curious about when to reach for a framework and when not to? Follow along — I write about practical, real-world full-stack decisions.

Building a Multi-Vendor Marketplace From Scratch: Lessons From 30,000 Lines of React

Faizullah — Fri, 19 Jun 2026 07:52:04 +0000

Building a Multi-Vendor Marketplace From Scratch: Lessons From 30,000 Lines of React

By Faiz Ullah — Full-Stack Developer & Founder of DG Technology

Most "build an e-commerce site" tutorials stop at a product list and a cart. They don't deal with the actual hard part: three different types of humans — customers, sellers, and admins — all needing their own secure space inside the same app, talking to each other in real time, without ever stepping on each other's data.

That's what I set out to build with Ecommerce, a multi-vendor marketplace that grew to over 30,000 lines of React. Here's what I learned engineering it.

The Real Challenge: Three Apps in One

A single-vendor store is one application. A multi-vendor marketplace is really three applications sharing a database:

Customers browse, buy, and chat with sellers
Sellers manage their own storefront, fulfill orders, and request payouts
Admins oversee everyone — approving sellers, resolving disputes, releasing payouts

The temptation is to bolt all three onto one App.js with a bunch of if (userType === 'admin') checks scattered everywhere. That gets unmanageable fast. Instead, I built three fully independent authentication systems, each with its own protected route guard:

<Route element={<ProtectedCustomerRoute />}>...</Route>
<Route element={<ProtectedSellerRoute />}>...</Route>
<Route element={<ProtectedAdminRoute />}>...</Route>

Each guard checks its own session state independently. A seller session can never accidentally leak into the admin view, even if someone tries to manipulate the URL directly.

Real-Time Chat Without a Custom Server

I wanted buyers and sellers to message each other live — no page refresh, no polling. Rather than standing up a WebSocket server, I leaned on Firestore's real-time listeners, which turned out to be the right call for a project this size:

onSnapshot(query(messagesRef, orderBy('timestamp')), (snapshot) => {
  // UI updates instantly as new messages arrive
});

This single pattern powers chat, unread-message counts, and live presence — all without me managing a single socket connection.

The Presence Problem

Showing whether a seller is "online" sounds trivial until you actually build it. A simple isOnline: true flag breaks the moment someone closes their laptop without logging out — they stay "online" forever.

The fix is a heartbeat pattern: the seller's client writes a lastSeen timestamp every few seconds while the tab is active, and stops the moment the tab closes or loses visibility:

document.addEventListener('visibilitychange', () => {
  if (document.hidden) stopHeartbeat();
  else startHeartbeat();
});

Anyone viewing the seller's profile just checks: was the last heartbeat recent? No server-side cron job needed, no stale "online" ghosts.

Media at Scale: Don't Make Your Database Hold Images

Early on I made the rookie mistake of storing image data directly. That doesn't scale — Firestore documents have size limits, and serving large base64 blobs kills load times.

The fix was routing all uploads through Cloudinary, using unsigned upload presets so the API secret never has to live in client-side code:

formData.append('upload_preset', cloudinaryConfig.uploadPreset);
const res = await fetch(`https://api.cloudinary.com/v1_1/${cloudName}/upload`, {
  method: 'POST', body: formData
});

Cloudinary then handles resizing, format conversion, and CDN delivery — the database only ever stores a URL.

The Payout Problem Nobody Talks About

Letting sellers earn money is the easy half. Letting them withdraw it safely is the half that actually matters. I built a dedicated WithdrawalRequestsManager so that:

A seller requests a withdrawal
The request enters a pending queue — funds are not released automatically
An admin reviews and approves it manually before money moves

This manual checkpoint is deliberate. Automating payouts sounds efficient until the first fraud attempt — a human review step at the money boundary is the cheapest fraud prevention you can build.

What I'd Tell Someone Building Their First Marketplace

Separate your three user types from day one. Retrofitting role isolation onto a single auth system later is painful.
Use your database's real-time features before reaching for a custom server. Firestore's listeners replaced what would have been a whole separate real-time service.
Never store binary media where structured data lives. Offload it to dedicated media infrastructure immediately.
Put a human checkpoint wherever money actually leaves the system.

The Stack

Layer	Technology
Frontend	React, React Router
UI	Material UI (MUI)
Database	Firebase Firestore
Auth	Firebase Authentication
Realtime DB	Firebase Realtime Database (presence)
Media	Cloudinary

Faiz Ullah
Full-Stack Developer · Founder of DG Technology
🌐 faizullah.pk · 💻 github.com/faizullahpk/multivendor-marketplace

If you're building something with multiple user roles and real-time data, I'd love to hear about it — follow along for more on shipping real-world full-stack systems.

Building an E-Commerce Store That Installs Like an App (Without a Native App)

Faizullah — Fri, 19 Jun 2026 07:50:19 +0000

By Faiz Ullah — Full-Stack Developer & Founder of DG Technology

Every e-commerce founder eventually asks the same question: "Should we build a native app?" Native apps are expensive, slow to update, and most users won't bother installing one for a store they're not sure they'll buy from twice.

When I built Yala Bazaar — a multi-category electronics store — I went a different route: build a Progressive Web App that gets 90% of the native-app experience (installable icon, offline support, app-like speed) for a fraction of the engineering cost.

Here's how it actually works under the hood.

What Makes a Website "Installable"

The browser doesn't show an "Add to Home Screen" prompt for just any site. Two specific pieces unlock it:

1. A web manifest describing the app's identity:

{
  "name": "Yala Bazaar",
  "icons": [{ "src": "icon-512.svg", "sizes": "512x512" }],
  "display": "standalone",
  "start_url": "/"
}

2. A registered service worker — a script that runs independently of any open tab and can intercept network requests:

self.addEventListener('install', (event) => {
  event.waitUntil(caches.open('v1').then(cache => cache.addAll(CORE_ASSETS)));
});

Once both are present, browsers offer to install the site like a real app — same home-screen icon, same full-screen launch, no browser chrome.

Deploying Without Downtime (The Part Most Tutorials Skip)

A live store can't go down mid-deploy — every minute offline is lost sales. I deployed Yala Bazaar to Cloudflare Pages, which solves two problems most people don't think about until they hit them:

Atomic deploys. The new version builds entirely on the side. Only once it's 100% ready does Cloudflare flip the live URL to it instantly. Visitors only ever see the fully-old or fully-new version — never a half-deployed broken state.

Content-addressed uploads. Every file is fingerprinted. Change one HTML file, and only that one file re-uploads — not the whole site. A small content fix deploys in seconds, not minutes.

This matters more than it sounds like it should: it's the difference between deploying fearlessly throughout the day versus batching changes because every deploy feels risky.

Live Chat Without Standing Up Chat Infrastructure

Customers abandon carts when they have a question and nobody to ask. I wanted live chat support, but didn't want to run a dedicated chat server for what's fundamentally a small-to-medium store.

The answer was the same pattern I'd use again and again: Firebase's real-time listeners as a lightweight pub/sub system. A customer's message writes to Firestore; the support dashboard listens for new documents and the message appears with no polling and no custom backend:

onSnapshot(collection(db, 'chats', chatId, 'messages'), (snap) => {
  renderNewMessages(snap.docChanges());
});

For a store at this scale, this replaces what would otherwise be a whole WebSocket service — for free, with infrastructure I don't have to maintain.

Separating "Browse" From "Manage"

A storefront has three very different audiences hitting it: shoppers browsing products, sellers managing their own listings, and admins running the whole operation. I kept these as separate page bundles (seller.html, admin.html) rather than one giant single-page app trying to be everything to everyone.

The benefit is concrete: a shopper's bundle never has to download seller/admin code they'll never use, keeping the actual storefront — the page that needs to load fastest — as lean as possible.

What I'd Tell Someone Building Their First Online Store

Don't default to a native app. A well-built PWA covers most of the value at a fraction of the cost and maintenance burden.
Pick a host with atomic, fingerprinted deploys. It changes how confidently you can ship small fixes.
Use your database's real-time features for chat/support before building custom infrastructure.
Keep your storefront bundle lean — don't make shoppers download code meant for sellers or admins.

The Stack

Layer	Technology
Frontend	HTML5, CSS3, Vanilla JavaScript
Installability	Web Manifest + Service Worker (PWA)
Auth & Chat	Firebase
Hosting	Cloudflare Pages

Faiz Ullah
Full-Stack Developer · Founder of DG Technology
🌐 faizullah.pk · 💻 github.com/faizullahpk/yala-bazaar-store

Thinking about whether your next project needs a native app or not? Follow along — I write about practical, real-world decisions in shipping full-stack products.

Clean Architecture on Android: What I Learned Building a Wallpaper App From Scratch

Faizullah — Fri, 19 Jun 2026 07:49:07 +0000

By Faiz Ullah — Android Developer & Founder of DG Technology

A wallpaper app sounds simple: fetch images, show a grid, let the user tap "set wallpaper." I built exactly that — WallReddit, a native Android app pulling images from Reddit — and used it as an excuse to do something I'd wanted to get right for a while: a genuinely clean, layered architecture instead of the "everything in one Activity" approach most small apps fall into.

Here's what building it taught me.

Why Bother With Clean Architecture for "Just a Wallpaper App"

It's tempting to skip architecture for a small app. But the moment you add offline favorites, a download manager, NSFW filtering, and a background auto-rotation feature, an unstructured app turns into a maze of interdependent code that's terrifying to touch.

So I split the app into three layers with one hard rule: dependencies only point inward.

ui/        → talks to → domain/        → talks to → data/
(Compose)                (use cases,                (Retrofit, Room,
                          pure Kotlin)                DataStore)

The payoff: the domain layer has zero Android imports. No Context, no Activity, nothing Android-specific — just plain Kotlin business logic. That means it's trivially testable and would survive a total UI rewrite untouched.

Reactive Settings Without the Boilerplate

Every setting in the app — dark mode, AMOLED mode, grid density, NSFW visibility — needed to update the UI instantly when changed, from anywhere in the app. Instead of manually plumbing callbacks everywhere, I exposed every preference as a Kotlin Flow backed by Jetpack DataStore:

val isDarkMode: Flow<Boolean> = dataStore.data.map { it[DARK_MODE_KEY] ?: false }

Any screen can collectAsState() on this and the UI updates the instant the value changes anywhere else in the app — no event bus, no manual notification, no stale state.

Fighting Reddit's Anti-Scraping Defenses

Reddit's public JSON endpoints are great until you hit their CDN's bot protection — a default Retrofit client gets 403 Forbidden almost immediately. The fix is straightforward but easy to miss: send a real browser User-Agent and proper timeout/retry configuration:

OkHttpClient.Builder()
    .addInterceptor { chain ->
        chain.proceed(chain.request().newBuilder()
            .header("User-Agent", "WallReddit/1.0 (Android)")
            .build())
    }

It's a one-line fix, but without it the entire app silently fails to load any content — the kind of bug that's invisible until you actually test against the real network.

Wallpapers Look Wrong Without Real Math

The naive way to "set a wallpaper" is to just hand the bitmap to Android's WallpaperManager and hope for the best. The result: stretched, cropped, or letterboxed images depending on the device's aspect ratio.

The actual fix is computing the transform yourself before handing off the bitmap — comparing the image's aspect ratio to the screen's, then applying a Matrix for center-crop or fit-to-screen:

val scale = max(screenWidth / bitmapWidth, screenHeight / bitmapHeight)
matrix.setScale(scale, scale)

This is the difference between an app that looks like an amateur project and one that looks production-grade — and it's invisible work nobody notices unless you get it wrong.

Background Work That Doesn't Drain the Battery

Auto-rotating wallpapers on a schedule means running work when the app isn't even open. Android's background execution limits make naive approaches (a Service that just runs forever) both unreliable and battery-hostile.

WorkManager is the right tool here specifically because it respects Doze mode and battery optimization automatically — your job runs reliably without you having to reinvent Android's power management:

val request = PeriodicWorkRequestBuilder<AutoWallpaperWorker>(interval, TimeUnit.HOURS)
    .setConstraints(Constraints.Builder().setRequiresBatteryNotLow(true).build())
    .build()

What I'd Tell Someone Building Their Second Android App

Keep your domain layer Android-free. It's the single highest-leverage architectural decision you can make.
Expose settings as reactive streams, not getter functions. Future-you will thank present-you.
Test your networking against the real API, not a mock — anti-bot measures only show up in production traffic.
Use WorkManager for anything recurring. Don't fight the OS's power management; work with it.

The Stack

Layer	Technology
Language	Kotlin
UI	Jetpack Compose, Material 3
Architecture	MVVM + Clean Architecture
Networking	Retrofit + OkHttp
Local storage	Room, DataStore
Pagination	Paging 3
Background work	WorkManager
Images/Video	Coil, Media3

Faiz Ullah
Android Developer · Full-Stack Engineer · Founder of DG Technology
🌐 faizullah.pk · 💻 github.com/faizullahpk/wallpaper-app-android

Building something on Android and hitting architecture questions? Follow along — I write about real-world mobile and full-stack engineering.

How I Built a Real-Time Multiplayer Game with Socket.IO, Firebase & Pakistani Payment Gateways

Faizullah — Wed, 10 Jun 2026 20:03:49 +0000

How I Built a Real-Time Multiplayer Game with Socket.IO, Firebase & Pakistani Payment Gateways

By Faiz Ullah — Full-Stack Developer & Founder of DG Technology

When people think of multiplayer games, they imagine big studios and huge teams. But a real-time, money-handling, cheat-proof multiplayer platform can be built by one engineer who understands the architecture deeply. This is the story of Ludo Battle — a real-time multiplayer Ludo tournament platform I built end-to-end, from the WebSocket game engine to the Android APK to the payment integration.

I'll walk through the hard parts, the decisions that mattered, and the lessons that apply to any real-time application — not just games.

The Challenge

Build a platform where:

2 to 4 players play live Ludo matches with sub-second synchronization
Players deposit and withdraw real money through local payment gateways
Nobody can cheat — not the dice, not the moves, not the outcomes
It runs on the web and as a native Android app
It works on Pakistani mobile networks, where strict NATs and unstable connections are the norm

That last constraint shaped a lot of decisions. Building for ideal conditions is easy. Building for real-world 4G in Pakistan is the actual engineering.

Architecture Decision #1: The Server Owns Everything

The single most important principle in any real-money game: the client is a renderer, never a decision-maker.

If the browser decides what the dice rolled, a cheater opens DevTools and rolls a six every time. So in Ludo Battle, the server is the source of truth for every piece of game state. The client sends intentions ("I want to roll", "I want to move this token"), and the server decides what actually happens.

Here's the dice roll — it lives on the server and uses Node's cryptographically secure random generator, not Math.random():

import { randomInt } from 'crypto';

function rollDice() {
  return randomInt(1, 7);  // 1–6, cryptographically secure
}

Math.random() is predictable and can be exploited. crypto.randomInt cannot. For real money, this difference matters.

Every move is validated the same way: when a player sends game:move, the server computes the legal moves from the current board state and rejects anything illegal before applying it. The client literally cannot make an illegal or impossible move stick.

Architecture Decision #2: A Clean Real-Time Event Model

The entire live experience runs over Socket.IO. I designed the events around clear namespaces so the codebase stays readable as it grows:

room:create   room:join   room:leave   room:spectate
game:roll     game:move
chat:send     chat:msg
voice:join    voice:signal   voice:leave

Rooms map directly to Socket.IO rooms, so broadcasting game state or chat to exactly the right players is a one-liner:

io.to(`room:${roomId}`).emit('chat:msg', message);

This structure means game logic, chat, and voice are cleanly separated but share the same connection — no extra sockets, no wasted overhead.

Architecture Decision #3: Voice Chat That Survives Real Networks

I wanted players to talk during games. The naive approach — routing audio through the server — is expensive and laggy. Instead I used peer-to-peer WebRTC, where the audio flows directly between players and the server only helps them find each other (signaling).

The catch: most Pakistani mobile users are behind strict NATs that block direct P2P connections. The fix is a TURN server that relays audio when a direct connection isn't possible. The app fetches TURN credentials per session and falls back gracefully:

Try direct connection (STUN)
If blocked → relay through TURN
Either way → players can talk

This is the difference between voice chat that "works on my machine" and voice chat that works for a farmer on a 4G connection in South Punjab.

Architecture Decision #4: Payments Without the Liability

Handling money means handling risk. I deliberately chose a hosted-redirect payment flow for JazzCash and EasyPaisa so that no card or wallet credentials ever touch my server.

The flow:

User taps "Deposit"
My backend builds a signed payload and returns it
The user is redirected to JazzCash/EasyPaisa's own secure page to approve
The gateway sends a callback to my server
My server verifies the HMAC signature before crediting a single rupee

That HMAC verification step is critical — it's how the server knows a callback genuinely came from the gateway and wasn't forged by someone trying to fake a deposit. Skipping it is how platforms get drained.

I also built a test mode: when no gateway credentials are configured, deposits credit instantly. This let me build and test the entire economy locally without touching real money or waiting on merchant approval.

Architecture Decision #5: One Codebase, Two Platforms

The frontend is React + TypeScript + Vite. To ship it as a native Android app without rewriting everything, I used Capacitor, which wraps the web build into a real APK that I can distribute directly — no Play Store gatekeeping required.

One important real-world gotcha: Android blocks insecure WebSocket connections. The app must talk to an HTTPS backend or the sockets silently fail in the APK. Discovering and solving that kind of platform-specific issue is where real shipping experience comes from.

What I Learned

Trust nothing from the client. This one principle prevents an entire category of exploits.
Design for the worst network, not the best. Building for Pakistani 4G made the app rock-solid everywhere.
Security isn't a feature you add later — crypto.randomInt, HMAC verification, and server-authoritative logic had to be in the foundation.
Separation of concerns scales. Clean event namespaces and layered logic kept a complex real-time system maintainable.

The Stack, Summarized

Layer	Technology
Frontend	React, TypeScript, Vite, Tailwind, Zustand
Backend	Node.js, Express, Socket.IO
Auth	Firebase Phone OTP + JWT
Payments	JazzCash, EasyPaisa (HMAC-verified)
Voice	WebRTC + TURN
Mobile	Capacitor → Android APK

Closing Thoughts

Ludo Battle taught me that the gap between a "demo" and a "product" is almost entirely in the parts users never see: the anti-cheat, the payment verification, the network resilience. Anyone can render a game board. Making it fair, secure, and reliable on real-world networks is the actual work.

If you're building something real-time, money-handling, or mobile — or you just want to talk architecture — I'd love to connect.

Faiz Ullah
Full-Stack Developer · Cybersecurity Engineer · Founder of DG Technology
🌐 faizullah.pk · 📧 work@faizullah.pk · 💻 github.com/faizullahpk

If you found this useful, follow me here and on GitHub — I write about real-world full-stack engineering, building for emerging markets, and shipping products solo.