01 - Context & Background
Pathao Food was invisible on the web
By 2023, Pathao Food was one of Bangladesh's most-used food delivery services - but it existed entirely inside a mobile app. If someone searched "order KFC online Dhaka" or "best biryani delivery near Dhanmondi" on Google, Pathao didn't show up. The entire user acquisition funnel started and ended inside the app stores.
This was a compounding problem. Pathao was spending on paid acquisition to drive app installs. But organic search - the highest-intent, lowest-cost channel in any market - was untouched. Foodpanda had a web presence. International players like Uber Eats built their organic channels years ago. Pathao had nothing.
The business also faced a structural ceiling: every new city or partner needed to be activated entirely through app infrastructure. There was no lightweight way to test market demand, onboard restaurant partners, or create digital presence for a new geography without a full app rollout.
The visibility gap
Zero web search presence
Pathao Food had no indexable web pages. Google searches for food delivery in Dhaka, Chittagong, or Kathmandu returned competitors - not Pathao.
The acquisition gap
100% paid-dependent growth
All new user acquisition required app install campaigns. There was no organic funnel - every user cost money to acquire, and organic search value was zero.
The expansion gap
Slow city-level scaling
Each new city or restaurant partner had no lightweight digital presence. Expansion required full app infrastructure activation, creating a bottleneck on growth speed.
My mandate: Build Pathao Food Web -
food.pathao.com - from zero. A fully functional web food ordering platform that serves as a new organic acquisition channel, supports digital payments, and enables city expansion independently of the mobile app release cycle.
02 - Problem Statement
Three compounding problems, one platform to solve them
Core problem
"Pathao Food had a dominant app presence and zero web presence. In Bangladesh's digital economy, that meant an entire acquisition channel - organic search - was completely abandoned to competitors."
Problem 1 - No SEO surface area
Every restaurant on Pathao, every cuisine, every city had no web URL, no title tag, no structured data, no indexable page. A search for "Burger King delivery Dhaka" or "north end coffee order online" returned Foodpanda, not Pathao. This was revenue being actively surrendered to competitors with an existing web presence.
Problem 2 - App-only ordering excluded web users
A significant segment of users - particularly in corporate and office environments, or users arriving from desktop search - had no way to order Pathao Food without downloading the app first. The friction of an app install before a first order is a documented conversion killer, particularly for new or infrequent users.
Problem 3 - City expansion was bottlenecked
Activating Pathao Food in a new city required full app-side configuration. There was no lightweight mechanism to establish a digital footprint - a restaurant list, a location page, a searchable presence - for a new geography before the full infrastructure was ready. The web platform needed to decouple digital presence from app rollout speed.
User impact
High-intent users lost at discovery
Users searching for specific restaurants or cuisines in Bangladesh had no reason to find Pathao. First touch went to Foodpanda or direct restaurant websites. Pathao entered the funnel only after a user had already made a decision - if at all.
Business impact
CAC with no organic offset
Without organic acquisition, every new user carried a full paid CAC. The web platform represented a structural CAC reduction opportunity - once ranked, organic users cost nothing to acquire. This was a compounding asset that didn't exist at all.
03 - Market Opportunity
Why the timing was right
Bangladesh's internet penetration had grown substantially by 2023, with mobile and desktop web usage both rising in urban centres. The food delivery market was maturing - users were more comfortable with online ordering and digital payments than they had been two years prior. This created a structural window: the demand was there for a web ordering experience, but no Bangladeshi food delivery platform had built a genuinely strong SEO-first web product.
Competitive landscape
| Platform |
Web ordering |
SEO-optimised pages |
Digital payments (web) |
City expansion tools |
| Foodpanda Bangladesh |
✓ Yes |
~ Partial |
✓ Yes |
~ Limited |
| Shohoz Food |
~ Limited |
✗ No |
~ Partial |
✗ No |
| HungryNaki |
✓ Yes |
~ Basic |
✓ Yes |
✗ No |
| Pathao Food Web (built) |
✓ Yes |
✓ Full SEO architecture |
✓ Pay Later, bKash, cards |
✓ Dynamic city config |
Key restaurant partners already on the platform
Pathao Food's restaurant network included major chains and beloved local brands - all of which had searchable demand on Google that Pathao was not capturing:
KFC Bangladesh
Burger King
Chillox
North End Coffee
Panshi
Khichuri Bhai
7 Dayz
Barcode
Peyala
YCD
Every one of these restaurants had users searching their names on Google. Pathao's app didn't intercept any of that intent. The web platform was the mechanism to capture it.
04 - Product Strategy
Four principles that shaped every decision
Principle 1 - SEO-first, not web-first
The temptation with a web platform is to replicate the app experience in a browser. That would have been a mistake. The primary job of the web platform was organic discovery and acquisition - getting Pathao into search results for restaurant names, cuisines, and locations across Bangladesh. Every architectural decision - URL structures, page types, metadata, structured data - was made to maximise indexability and keyword coverage first, ordering experience second.
Principle 2 - App as the deep-link destination, not a competitor
The web platform was not designed to replace the app. It was designed to intercept organic traffic at discovery and convert users into the Pathao ecosystem - either ordering on web or installing the app. This shaped the entire UX: prominent app-download CTAs, QR codes to the Play Store and App Store, and a web ordering flow that was complete enough to convert but built to drive app adoption as the primary ongoing channel.
Principle 3 - Dynamic city configuration as the scaling mechanism
Rather than hardcoding city-level content, the platform was architected around dynamic city configuration. Adding a new city to the web platform required a single configuration change - not a new deployment or engineering sprint. This decoupled the web platform's geographic reach from the engineering release cycle, enabling city expansion at a speed the app could never match.
Principle 4 - Digital payments as a conversion requirement, not a feature
Web ordering without digital payments creates a broken experience - a user who orders on web but has to pay cash on delivery defeats the point. Digital payment support (Pay Later/BNPL, bKash, cards) was a launch requirement, not a Phase 2 addition. Getting this right at launch was non-negotiable for conversion.
Scope constraint accepted: Pickup order support on web was explicitly excluded from the initial launch. Pickup on web required Digital Payment, Pathao Pay, and BNPL prerequisites that would significantly extend the timeline. Web was launched as delivery-only, with pickup as a follow-on phase once the payment infrastructure matured.
05 - Platform Architecture
How the platform was structured
The web platform was built across three distinct layers - public-facing discovery, ordering infrastructure, and operational tooling. Each layer had different stakeholders, different performance requirements, and different SEO implications.
Homepage (food.pathao.com): Location entry point, value proposition, app download CTAs, partner restaurant logos, payment options, merchant onboarding CTA, "How it works" flow. Optimised for brand + category search terms.
City pages (/dhaka, /chittagong, /kathmandu etc.): Dynamically generated per configured city. Restaurant listings by area and cuisine. City-specific title tags and meta. Targeted for "food delivery [city]" and "restaurants [city]" searches.
Restaurant pages (/restaurants/[slug]): Dedicated SEO page per restaurant partner. Captures branded search (e.g. "KFC delivery Dhaka", "North End Coffee order online"). Includes menu preview, delivery info, and direct order CTA. Every new restaurant partner automatically gets a searchable URL.
Location detection: "Locate me" (GPS) and manual address entry. Saved addresses surfaced on login. Location sets restaurant availability scope.
Cart and checkout: Full item-level add/remove/quantity. Promo code application. Delivery fee shown in bill breakdown. Order confirmation with estimated delivery time.
Payment gateway: Pathao Pay Later (BNPL), bKash integration, card payments. Pre-payment required for digital payment methods. Payment failure returns to checkout with clear error state.
Order tracking: Post-order status screen. Foodman tracking view. Real-time status updates.
Dynamic city configuration: Internal ops dashboard toggle to activate/deactivate web ordering per city. No code deployment required. Enables new city activation in minutes.
Restaurant web page management: Automatic page creation on restaurant onboarding. Slug generation from restaurant name. City-level grouping for taxonomy SEO.
Merchant onboarding CTA: Prominent "Join as a Restaurant Partner" pathway surfaced on homepage and restaurant listing pages - turning the SEO surface into a B2B acquisition channel as well as B2C.
Page type taxonomy
Page type 1
Homepage
Brand and category entry point. Single page, high link authority. Targets: "food delivery Bangladesh", "Pathao Food", "order food online Dhaka".
Page type 2
City / Area pages
One per active city. Dynamically generated. Targets: "food delivery Dhaka", "restaurants Chittagong delivery", "online food order Kathmandu".
Page type 3
Restaurant pages
One per restaurant partner. Auto-generated on partner onboarding. Targets: "[Restaurant Name] delivery", "[Restaurant Name] order online", "[Cuisine] delivery [area]".
06 - SEO System Design
Building the organic acquisition engine
SEO was not a post-launch optimisation task - it was a pre-launch architecture requirement. Every structural decision about URLs, metadata, page content, and internal linking was made before a line of UI code was written.
| SEO element |
Decision made |
Rationale |
| URL structure |
food.pathao.com/restaurants/[restaurant-slug] |
Clean, readable URLs with restaurant name as slug maximise branded search match. Subdomain keeps Food SEO separate from Pathao's main domain authority pool. |
| Title tags |
Unique per page: "Order [Restaurant] Online - Pathao Food" / "Best Food Delivery in [City] - Pathao Food" |
Keyword-first format matches the top search intents. "Order [X] online" matches transactional queries; "best food delivery [city]" matches navigational queries. |
| Meta descriptions |
Action-oriented: "Order from [Restaurant] and get delivery in under an hour. Fast food delivery in [City] with Pathao Food." |
Meta descriptions don't affect rank directly but control click-through rate. Action verbs ("order", "get delivery") trigger transactional intent matching. |
| Open Graph tags |
Full OG suite per page: og:title, og:description, og:image, og:url |
Social sharing from WhatsApp and Facebook (dominant platforms in Bangladesh) generates link previews. Rich previews increase share click-through significantly. |
| Structured data |
Restaurant schema (name, cuisine, address, delivery hours, image) on restaurant pages |
Enables Google rich results - restaurant cards in search with star ratings, delivery info, and menu highlights. Significantly increases SERP real estate vs. plain blue links. |
| Internal linking |
Homepage → city pages → restaurant pages. Cuisine-type cross-links between restaurant pages. |
Deep link distribution ensures Google crawls and indexes restaurant pages, not just the homepage. Cuisine cross-links build topical authority clusters. |
| Image optimisation |
WebP format with descriptive alt text on all restaurant and feature images. IPX image proxy for responsive sizing. |
WebP delivers 25–34% smaller file sizes vs JPEG - critical for Core Web Vitals on Bangladesh's mixed network conditions. Alt text contributes to image search indexing. |
| robots.txt + sitemap |
Allow all crawlers. XML sitemap auto-generated including all city and restaurant pages. |
Auto-generating the sitemap ensured every new restaurant page was submitted to Google Search Console automatically on creation, without manual intervention. |
The compounding effect: Each new restaurant partner added to Pathao Food Web auto-generated a new indexed URL targeting that restaurant's branded search terms. With hundreds of restaurant partners, this created a long-tail keyword coverage that grew automatically as the partner network grew - no additional SEO work required per restaurant.
07 - Ordering Experience
The web ordering flow: built for conversion, designed for app transition
The ordering flow had two simultaneous jobs: complete enough to convert first-time web users into placed orders, and clear enough to drive app downloads for ongoing usage. Every screen had an app download prompt without disrupting the ordering path for web-first users.
1
Discovery - Homepage or Restaurant Page
User arrives from Google search ("KFC delivery Dhaka"), social share, or direct navigation. Homepage shows location entry ("Locate me" or manual address) with app download as primary CTA. Restaurant page shows restaurant details, menu preview, and direct "Order Now" CTA. App download QR codes available throughout - no friction to convert to app if preferred.
2
Location Entry
GPS-based "Locate me" for one-tap location detection. Manual address input for precision. Saved addresses surfaced for logged-in users (via Pathao account). Location determines available restaurants and delivery zones. No location = no restaurant list - this is intentional and surfaces a clear CTA to set location.
3
Restaurant Browse & Menu
Restaurant listing sorted by relevance to user location. Promotions and partner offers surfaced prominently. Menu page shows full item list, images, prices, and customisation options (size, add-ons). Breadcrumb navigation for SEO and user orientation. "Add to cart" maintains session across browse - no cart loss on back navigation.
4
Cart & Checkout
Cart summary with item-level edit/remove. Promo code input. Delivery fee displayed in bill breakdown. Delivery address confirmation. Payment method selection: Pay Later (BNPL), bKash, card. Order review before placement. COD available where digital payment is not required - web ordering maintains parity with app payment options where infrastructure allows.
5
Payment & Order Confirmation
For digital payments: user redirected to payment gateway. On success, order placed and confirmation screen shown with order ID, estimated delivery time, and Foodman details. On payment failure, user returned to checkout with clear error message - no order created, no duplicate charge risk. Order confirmation includes prominent app download prompt ("Track your order in the app").
6
Order Tracking
Web-based order status view showing Placed → Accepted → On the Way → Delivered states. Foodman location and contact info displayed. Deep-link to app tracking for richer real-time view. Order history accessible for logged-in users with re-order functionality - maintains the session value of a web account.
Key UX decisions
App download as companion, not gate - users can complete a full order on web without downloading the app. App download is prominently offered at every step but never blocks ordering. This maximises both web conversions and app installs.
QR codes for frictionless app transition - QR codes on the restaurants listing page link directly to the Play Store and App Store. A user browsing on desktop can scan with their phone and land directly in the app - bypassing the store search step entirely.
Restaurant partner onboarding CTA embedded in the UX - "Are you a Restaurant Owner? Join as a Restaurant Partner" is surfaced on the homepage and listing pages. The web platform serves as a B2B acquisition surface for new restaurant partners at zero marginal cost.
Helpline number in header - 09678100800 displayed prominently. In a market where trust in online ordering is still building, a visible helpline number reduces purchase anxiety, particularly for first-time web orderers.
08 - Payment Architecture
Digital payments as a first-class launch requirement
Bangladesh's digital payment ecosystem was maturing rapidly through 2023–24. bKash had reached near-universal adoption in urban Bangladesh. Pathao Pay Later (BNPL) was already available in the app. Card penetration was rising among the urban professional segment. Integrating all three on web was non-negotiable for parity with competitors and for conversion rate on digital-payment-preferring users.
Pay Later / BNPL
Pathao's proprietary buy-now-pay-later
Leverages Pathao's existing user credit relationship. Approved users order now, pay in the billing cycle. Removes payment as a conversion blocker for users who prefer to settle monthly. High-intent, high-LTV user segment.
bKash
Bangladesh's dominant MFS platform
Near-universal adoption among urban Bangladeshi users. bKash payment on web mirrors the in-app experience. Critically important for users who don't hold cards but routinely pay digitally via mobile financial services.
Cards
Debit and credit card gateway
Covers the urban professional and corporate segment. Desktop web ordering + card payment is the dominant pattern for office-hour orders placed from work computers - a significant web-specific use case not served by the app.
Payment failure design: On payment failure, the order is not placed and the user is returned to checkout with a specific error message. No duplicate charge, no ambiguous order state. This was explicitly designed to prevent the trust-destroying pattern of "money taken but order unclear" - particularly important for first-time digital payers.
09 - City Expansion System
Decoupling web presence from app release cycles
One of the most strategically important capabilities of the web platform was what I called dynamic city configuration - the ability to activate a new city's web presence without a code deployment or engineering sprint.
Key insight
Before the web platform, activating Pathao Food in a new city required coordinating app releases, backend configuration, and ops readiness simultaneously.
The web platform's dynamic city config meant a new city could have a searchable, indexable web presence - with restaurant listings, SEO pages, and an ordering surface - activated in minutes by the ops team, independent of any engineering work.
How dynamic city configuration worked
1
City added to configuration dashboard
Ops or product team adds a new city (name, slug, lat/lng bounds, delivery zones) in the internal ops dashboard. No code change, no deployment required.
2
City page auto-generated
food.pathao.com/[city-slug] is automatically created with the city's restaurant list, dynamically generated title tags and meta descriptions, and a sitemap entry. Google can start indexing within 24–48 hours of activation.
3
Restaurant pages generated per partner
Each restaurant activated for the city automatically gets a URL, a page with menu/info/ordering CTA, and an entry in the sitemap. Partner count grows the SEO surface area automatically.
4
Organic traffic begins flowing
Once indexed, searches for "food delivery [city]" and "[restaurant name] [city]" start surfacing Pathao Food results. The city has an organic acquisition channel before the app rollout even completes - creating lead time for user acquisition.
Result: City expansion setup time reduced by 60% compared to app-only rollout. The web platform became the vanguard of geographic expansion - establishing digital presence and beginning organic acquisition weeks before app infrastructure was fully operational in a new city.
10 - Success Metrics
How success was defined and measured
North Star
Organic impressions growth
+60%
Achieved post-launch · Google Search Console
Expansion
City launch time reduction
−60%
vs. app-only city activation
Acquisition
New channel established
Organic
Web as a 0-cost acquisition channel vs. paid-only before
Conversion
Digital payment options live
3 methods
Pay Later · bKash · Cards at launch
SEO coverage
Indexed pages at launch
100%
Every restaurant partner auto-gets a URL and sitemap entry
Platform
B2B surface created
Web → Partner
Merchant onboarding CTA on homepage and listing pages
Measurement framework
Google Search Console - primary source for impressions, clicks, average position, and keyword coverage. Tracked weekly with particular attention to restaurant-branded and city-level queries.
Web order volume - tracked separately from app order volume to isolate web-native conversion rate and identify web-specific user behaviour patterns (time-of-day, device type, payment method preferences).
App install attribution from web - UTM-tagged app download links and QR codes allowed attribution of app installs sourced from the web platform. This measured the web-to-app conversion funnel contribution.
City activation speed - time from "decision to launch city on web" to "first indexed pages live" tracked against the pre-web baseline to validate the 60% setup time reduction.
11 - Risks & Mitigations
What could go wrong and how we designed around it
High Risk
Web cannibalises app adoption
If web ordering was too frictionless, users might never download the app - reducing the long-term LTV benefit of app-native engagement. Mitigated by positioning app download as primary CTA throughout, and reserving some features (rich order tracking, reorder, loyalty points) as app-exclusive incentives.
High Risk
Payment failure erodes trust
Bangladesh's web payment trust was fragile in 2023. A single "money taken, order unclear" incident would damage the entire web channel. Mitigated by explicit order-not-created-on-payment-failure logic, clear error messaging at every failure state, and a visible helpline number for immediate escalation.
Medium Risk
SEO pages rank slowly or not at all
New domains and subdomains can take 3–6 months to build search authority. Mitigated by ensuring the sitemap was submitted to Search Console on launch day, internal linking was properly configured to distribute authority to restaurant pages, and structured data was implemented for rich result eligibility from day one.
Medium Risk
Inconsistent restaurant data quality
Restaurant pages would only be useful for SEO if the data (name, cuisine, address, operating hours) was accurate and complete. Mitigated by making restaurant page creation contingent on a minimum data completeness threshold, with an ops-side QA step before pages were published.
Medium Risk
Core Web Vitals failure on slow networks
Bangladesh has mixed network quality. Slow page load directly hurts both SEO ranking and conversion. Mitigated by WebP image format via IPX proxy, lazy loading for below-fold content, and a performance budget set during engineering review - not as a post-launch cleanup item.
Low Risk
Ops misuse of city config toggle
Dynamic city config gave non-technical ops users the ability to create live web pages. Mitigated by a required data validation step (minimum fields: city name, slug, at least one active restaurant) before a city could be activated, preventing empty or broken city pages from going live.
12 - Lessons & Reflections
What building food.pathao.com taught me
01
SEO is a product decision, not a marketing task
The most consequential SEO choices for Pathao Food Web were made before the first line of UI was written: URL structure, page taxonomy, dynamic sitemap generation, structured data schema. These were engineering architecture decisions. Treating SEO as a post-launch content task would have built the wrong product. The 60% organic impression lift was a direct result of SEO being a PM-level requirement, not a marketing department request.
02
The right 0→1 question is "what job can only this platform do?"
Early in the project, there was pressure to replicate the full app experience on web. The right question was different: what can the web do that the app cannot? The answer was organic search interception and city-level geographic scalability without engineering dependency. Anchoring the product around those two capabilities - rather than "web version of the app" - shaped everything from the architecture to the metrics.
03
Dynamic configuration is worth the upfront investment
Building the city configuration dashboard was slower than hardcoding the first few cities. But the compounding return - 60% faster city expansion, zero engineering involvement for ops-side geographic activation - justified the investment many times over. The right infrastructure decision often looks like over-engineering at launch and looks like obvious architecture six months later.
04
Trust signals are conversion features, not decoration
The helpline number in the header, the partner logos (KFC, Burger King, Chillox), the payment method icons - these weren't brand decoration. In a market where web ordering trust was still establishing itself, every trust signal was a measurable conversion lever. The partner logos signalled platform legitimacy. The helpline signalled accountability. Both reduced the perceived risk of a first-time digital food order.
05
A new channel is only as good as its handoff to the existing one
The web platform's long-term value to Pathao wasn't just web orders - it was app installs attributed to organic web discovery. Getting the web-to-app transition right (QR codes, deep links, app-exclusive feature incentives) was as important as the ordering flow itself. A 0→1 platform succeeds when it strengthens the existing ecosystem, not when it competes with it.