<![CDATA[Talo Engineering]]>https://talo-engineering.hashnode.devRSS for NodeSat, 31 Oct 2026 22:15:40 GMT60<![CDATA[I’m Building 25 Dating Apps with One PWA Codebase]]>https://talo-engineering.hashnode.dev/i-m-building-25-dating-apps-with-one-pwa-codebasehttps://talo-engineering.hashnode.dev/i-m-building-25-dating-apps-with-one-pwa-codebaseSat, 24 Oct 2026 21:43:03 GMTI’m building 25 dating apps through Talo.

There’s Tamil Talo for the Tamil community, Punjabi Talo for the Punjabi community, and Shia Talo for the Shia Muslim community. Each has its own name, landing page, and application hostname. They share an Expo application, an API, and a database.

The product goal is simple: help someone meet a person from their community over a first Coffee Date. The engineering challenge is giving each service a recognizable identity while keeping registration, chat, notifications, and updates maintainable.

Here’s how the PWA implementation works—and the browser behavior that makes it more interesting than changing a logo.

Why Build 25 Dating Apps?

A person looking for a Tamil dating app may care about sharing a language, family context, or cultural background. Someone looking for an Ismaili dating app may start with a different requirement. Each person still needs room to explain what matters to them individually.

That is the reason for the community-specific entry points. Tamil Talo can explain who its service is for from the first page. Punjabi Talo can do the same for its audience. Neither name tells us everything about a person’s beliefs, preferences, or compatibility.

The shared experience is a reviewed introduction, a private choice to meet or pass, and—when both people agree—help arranging a roughly 60-minute date at a supported public cafe. Accepting that invitation means being willing to have a conversation. It does not commit either person to a relationship or another date.

One Catalog Connects the Brand to the Application

We keep community IDs, names, and hostnames in a maintained catalog. The web application resolves its brand from the hostname, and shared components use that result for their displayed name.

The route from discovery to the app looks like this:

Tamil Talo landing page       Punjabi Talo landing page
          |                              |
tamil.withtalo.com             punjabi.withtalo.com
          |                              |
          +------ shared Expo app -------+
                         |
                  shared API and DB

Our Expo application also shares code between Web and Native. Browser-specific installation and notification behavior lives in Web modules, so the common product logic does not need to implement every platform interaction itself.

Make the PWA Identity Stable

The brand needs to survive the move from a browser tab to the home screen.

When a browser requests /manifest.webmanifest, a Worker reads the base manifest, looks up the hostname, and overrides the identity fields. The core transformation is small:

const entry = entryByHostname(url.hostname);
const name = entryBrandName(entry?.id);

const brandedManifest = {
  ...manifest,
  id: entry ? `/talo/${entry.id}` : "/talo",
  name,
  short_name: name,
  start_url: "/activate?source=pwa",
  scope: "/",
};

Tamil’s host gets the name Tamil Talo and manifest ID /talo/tamil. Punjabi’s host gets Punjabi Talo and /talo/punjabi.

We derive that identity from the host rather than a member’s current selection. Otherwise, installation behavior could depend on account state or the last community link someone visited. A fixed host identity stays predictable before and after login.

The relative start_url opens the activation route on that same community host. That route reads the saved application state and chooses the next screen.

Our current PWA icons and base theme colors are shared. The community-specific pieces include the hostname, name, manifest ID, and in-app brand presentation.

For a concrete example, explore Tamil Talo’s Tamil dating app and its community-specific landing page.

Here are the actual public landing pages, captured on October 24, 2026. Their shared layout keeps the community name and explanation specific to each service.

Tamil Talo public landing page with its Tamil dating app heading, service description, and cafe image.

Tamil Talo’s public brand page.

Punjabi Talo public landing page with its Punjabi dating app heading, service description, and cafe image.

Punjabi Talo’s public brand page.

Instagram Changes the Installation Problem

The happy path starts in a normal browser. A real discovery path can start inside Instagram or Facebook.

Our installation flow checks user-agent indicators for those apps and Android WebViews. It treats that detection as a heuristic and retains manual guidance.

On iPhone and iPad, eligible pages opened outside Safari attempt a Safari handoff using x-safari-https. The redirect is limited to recognized origins and permitted routes. It skips Safari and installed PWAs, excludes credential-bearing URLs, and does not forward unknown query parameters.

The OS or host app can block the attempt, so we keep a copyable link and instructions for opening it in Safari. On Android, the in-app-browser flow guides the person to copy the link and open it in Chrome; it does not automatically launch Chrome.

The handoff link preserves the community destination and a return path to installation. Authentication happens in the destination browser. That can mean signing in again, but it avoids putting a signed-in session into a URL.

Once in a supported browser, iPhone and iPad users get illustrated home-screen instructions. Android uses beforeinstallprompt when available, with a manual fallback when it is unavailable or dismissed.

Our Service Worker Does Not Precache the App Shell

This is a deliberate tradeoff in Talo’s PWA implementation.

For same-origin page navigations, the worker fetches from the network with cache: "no-store". If that request fails, it returns a reconnect-and-retry screen. It does not serve a cached application shell.

We give up offline use of the application, while avoiding a Service Worker that keeps returning an old app shell. This describes the worker’s policy; it does not disable every browser or CDN cache.

Worker activation also does not force a page reload. Someone filling out a profile, uploading a photo, or completing a payment should not lose their current interaction because a worker updated.

The same policy applies across the community hosts, so it can be maintained as one implementation.

Four States We Keep Separate

A successful installation prompt is an incomplete picture of whether someone can return to the app. Our implementation distinguishes:

  1. Standalone launch: the authenticated member actually opens the PWA in standalone mode.
  2. Notification permission: the browser reports that notifications are allowed.
  3. Subscription registration: the Push subscription is successfully registered with our server.
  4. Remote delivery: a notification actually reaches the device, which needs separate verification.

Permission can succeed while subscription registration fails. An installation event does not prove a standalone launch. Keeping those facts separate makes failures easier to locate without inventing successful earlier steps.

Sharing infrastructure also does not merge the services’ membership rules. A hostname determines presentation; it does not establish a person’s identity, eligibility, or permission for an introduction.

The 25 Community Dating Apps

These are Talo’s current community brands as of October 24, 2026. Each link goes to the service’s brand overview, where readers can check its audience and supported locations.

The current regional offer is in Canada. Country-neutral names and URLs do not imply worldwide availability; check the relevant service page before joining.

The engineering work is to keep one core reliable while preserving the identity and service boundaries of each app. The product question is whether that experience helps people move from discovering their community’s service to a Coffee Date. Both deserve their own evidence.

]]>