Paltuu.pk.

In 2024, if you wanted to adopt a cat in Karachi, here is what you did. You joined three or four Facebook groups. You scrolled. Someone had posted four blurry photos and a phone number, sometimes a location, rarely an age, almost never a vaccination history. You commented "interested". So did sixty other people. If you were fast enough, or if your profile looked respectable enough, someone replied to your comment with a WhatsApp number. Then the conversation moved off the platform entirely and whatever happened next happened between two strangers with no record of any of it.

That system worked, in the sense that animals did find homes through it. Thousands did. It is also the reason the rescue community in this country is exhausted, suspicious, and full of people who have been burned.

We spent the first six weeks of the engagement not designing anything. We talked to pet owners, rescue volunteers and vets across Karachi and Lahore — including, because it is the useful group, people whose adoptions had failed.

Six weeks is a long time to bill a pre-revenue startup for conversations, and we were asked more than once whether it was necessary. It was. The founders arrived with six verticals and a hunch. What came out was four problems, stated precisely enough to build against, and a reason to believe each one.

Read those in order and the shape of the next two years is already in them. Two are about not being able to verify a stranger. One is about a stale, scattered index. One is about care you need at eleven at night. One is about not being able to buy food you can trust. Nobody in those conversations asked for a pet adoption website.

The founders arrived describing a discovery problem: people cannot find pets to adopt, so build a place where the pets are. That is a real problem and it is not the expensive one.

What the interviews said, repeatedly, was that this is a trust problem wearing a discovery problem's clothes. Supply exists. Demand exists. What does not exist is any mechanism by which a rescue can believe an adopter, an adopter can believe a rescue, and either of them can check afterwards what actually happened. Every serious feature in the first version of Paltuu came out of that reframe — verification, applications that create a record, moderation before publication, the deliberately slowed-down adoption flow.

It also determined what the brand had to do, which we did not know yet but which is chapter 06.

The other thing worth saying about that right-hand column is that we did not act on all of it. Problems three and four — care on demand, and a commerce channel — are real, were named in the first six weeks, and were then deliberately left alone for over a year. They became Pet Care and Paltuu Bazaar. Knowing what to build is the easy half; the case study from here is mostly about the order.

The pitch we were handed covered adoption, vet appointments, grooming, boarding, pet food delivery, and pet insurance. It is a good five-year company. It is a catastrophic first release, for a reason that has nothing to do with engineering capacity.

Every one of those verticals is a two-sided marketplace with its own supply side. Vet booking needs vets. Grooming needs groomers. Boarding needs boarders. Launching all of them at once means launching six empty marketplaces simultaneously, each of which looks abandoned, each of which makes the others look less credible. A user who taps "Find a groomer" and sees nothing does not come back to try adoption.

So the first deliverable of the engagement was not code. It was a document that said what we were building, what we were explicitly not building, and what had to be true before each next thing got started.

The hardest recommendation in the scoping phase was to launch with no revenue model at all.

Every option that monetises the adoption itself makes the platform worse at its only job. A listing fee prices out exactly the small rescues whose listings give the marketplace its liquidity. An adoption fee turns a rehoming into a transaction, which is the precise thing the rescue community is afraid of and the precise thing that makes "free to good home" dangerous. Taking a cut of the donation means the platform now has a financial interest in adoptions completing, which is a horrifying incentive to have in a system whose job is sometimes to stop an adoption.

And all of them lose to the competition on price, because the competition is a Facebook group and it is free.

We said: launch free, get the supply side, get the demand side, prove the thing works, and come back to us when you have an audience and no revenue. That is a real risk and we said so in the document. It is also what happened, on roughly the timeline we described, and chapter 09 is the conversation it produced.

A marketplace is two products sharing a database. Get one of them wrong and the other one has nothing to do. On Paltuu the two sides needed opposite things, and the temptation — which we spent real time resisting — is to design one flow and let both sides use it.

The person posting an animal is a rescue volunteer with a phone, no laptop, no patience, and forty animals. They are currently able to list an animal in about forty seconds: open the group, upload photos, type two lines, post.

If our form takes four minutes, we lose. Not because the volunteer is lazy — because they have thirty-nine more animals and a vet appointment. Every field we add is a field that has to justify itself against the risk of the listing never being created at all.

So the required set is photos, species, age bracket, city, and one paragraph. That is it. Everything else — breed, vaccination status, temperament, good with children, good with other animals, neutered, litter-trained, medical history — is optional, and can be filled in later from the listing itself, from a phone, in the gaps between other work. The listing goes live without them; it just performs better with them, and we tell the poster that.

Partner rescues get bulk tools on top: multiple listings in one sitting, saved defaults for their organisation, and a dashboard of everything they currently have open with its application count.

On the adopter side, we did the opposite, and this is the single most important design decision in the product.

A listing is not a buy button. There is no instant "claim this pet". Tapping through opens an application, which asks the questions a good rescue would ask you in person — what is your address, how old is the youngest child in the house, what other animals live there, is there a secure outdoor area, where will the animal sleep, and how many hours a day would it be left alone.

Those are not generic form fields. Every one of them came out of the discovery interviews as a reason a placement had failed: a dog rehomed into a house with a toddler nobody mentioned, a cat that got out because nothing was secured, an animal alone for eleven hours a day because the adopter worked a double shift and had not thought about it until the day it started crying.

Two things happen. The people who were never going to be good homes fall out at question three, which saves the rescue an hour. And the ones who complete it have now spent ten minutes thinking concretely about a fifteen-year commitment, which is ten minutes more than the Facebook flow ever asked for.

Then it becomes a record. The person who listed the animal opens one screen and sees every applicant side by side — the same fields in the same order, each one expandable, each one approved or rejected with a button. Not sixty comments saying "interested" and a WhatsApp thread they have to reconstruct from memory. They can compare, they can decline, and both parties can refer back to it afterwards.

That screen is the product. Everything else on the adoption side exists to fill it in.

The application itself is three steps. The first is who you are — name, city, the actual address the animal would live at. The last is the one that matters: how long the animal would be left alone each day, anything else the rescue should know, and a commitment you have to tick to submit — that you will provide a safe home, cover veterinary costs, never abandon the pet, and allow follow-up visits if the rescue asks for them.

None of that is legally enforceable and we never claimed it was. What it does is make somebody read the sentence and press the button, which is a meaningfully different act from typing "interested" under a photograph.

Trust badges are easy to add and easy to make meaningless. We spent a disproportionate amount of the design phase on what the platform is actually claiming when it marks something verified, because the moment that badge is decorative, the entire trust argument collapses and Paltuu is a prettier Facebook group.

Two separate things are being verified and they are labelled differently. A verified rescue partner is an organisation that has been checked by a human, has a real address and real intake, and has an ongoing relationship with the platform. A reviewed listing is any listing that has passed human moderation before publication — which is all of them, because nothing goes live unreviewed.

The moderation queue is not automated and we advised against automating it. Every new listing is looked at by a person before the public sees it, checking for the specific patterns the discovery interviews surfaced: breeder stock disguised as rescue, the same animal relisted repeatedly, prices in a listing that claims to be an adoption, images lifted from elsewhere on the internet.

Almost all of this traffic is mobile. A large share of it is on hardware that is several years old and on data that the user is conscious of spending. Meanwhile the product is a photo gallery — the median session is scrolling dozens of images of animals, because that is the entire point.

Those two facts fight each other, and most of the engineering decisions in the first build come out of that fight.

A rescue volunteer's phone produces a six-megabyte photograph. Twenty of those on a listing grid is a hundred and twenty megabytes, which is not a slow page — it is a page that never finishes, on a connection where the user gave up at second four.

So images are processed on upload rather than served as sent: re-encoded to modern formats, generated at several sizes, stripped of metadata, and delivered from a CDN with the right size picked per viewport. Uploads are compressed client-side before they ever leave the phone, which matters as much for the rescue on a metered connection as it does for the adopter. Grids are lazy-loaded with reserved space so the layout does not jump while a volunteer is scrolling with one thumb.

The result is a listing grid that costs a fraction of what the raw photos would, on the same page, at the same visual quality.

Search in Pakistan is transliterated, code-switched and inconsistently spelled, and a search box that only understands correct English is a search box that returns nothing to a third of its users.

People type paltu, paaltuu and paltoo. They type billi and kutta as often as cat and dog. They type persian cat, persain cat and persion cat. They type the same breed six ways. The platform handles all of it — the search layer normalises transliterations, accepts Urdu and English terms for the same thing, and tolerates the misspellings that actually occur rather than the ones a dictionary predicts.

This is unglamorous work and it is the difference between a search box that people use twice and one they use every visit.

The shape of the platform is the decision we would defend hardest, and it is the reason everything in chapters 10 and 11 could be added without a rewrite.

Paltuu reads to a user as five independent products. Discover & Browse. Adopt & Rescue. Lost & Found. Marketplace. Pet Care & Vet. Each one has its own browse surface, its own act surface, and its own manage surface, and each one is reachable directly from the homepage without passing through any of the others. Somebody who only ever uses Lost & Found never has to know the rest exists.

None of those five, however, owns identity. Not one of them decides who a user is, whether they are verified, what they are allowed to do, what they get notified about, or whether they are banned. That lives in a single layer underneath all five — accounts, trust and operations — along with the role-scoped panels for rescues, vets, shops and vendors.

The payoff is that a verification decision or a ban is made once and propagates everywhere at once, instead of five times in five places with three of them out of date. It is also why adding a sixth pillar is a normal piece of work rather than a migration: Marketplace was added to a platform that already knew how to say who someone was.

Inside the browse pillar, the URL structure and the page templates were designed around one observation: nobody searches for a pet adoption platform. They search for "cat adoption in Karachi", "puppy for adoption Lahore", "kitten adoption near me". The demand side of this marketplace does not arrive at a homepage. It arrives on a deep page, from Google, already knowing what it wants.

So city and species combinations generate real, individually indexable, genuinely useful pages — server-rendered, fast, with live listings on them. Not doorway pages with a swapped city name. Actual pages that answer the query the person typed.

That is not an SEO task performed after launch by a different vendor. It is the shape of the application, and doing it afterwards means rebuilding the routing. Most companies discover this at the point where that has become too expensive.

Adoption is an infrequent event. Someone adopts a cat, and then — if the product has done its job — they do not need it again for a decade. That is a brutal retention profile. A platform whose entire value is delivered once is a platform that has to buy every user twice.

Lost & Found came out of the discovery interviews as an aside. Multiple people described the same panic: an animal gets out, and the owner's only option is to post in the same Facebook groups and hope the right person is scrolling in the next hour.

We put it in v1 anyway, against a scope we had just spent six weeks tightening, on the argument that it is the same data model as a listing — animal, photos, city, contact — pointed the other way, and that it gives the platform a reason to exist in weeks where nobody is adopting.

It worked. Lost & Found is a recurring reason for pet owners in a city to open the site, and it brings in exactly the audience the adoption side wants: people who already own animals and care about them enough to help a stranger find one.

The platform was working before it looked like anything. What the brand had to do was make it credible to somebody who had never heard of it, in under two seconds, on a phone.

Pet brands globally converge on the same look — a rounded sans-serif, a soft mint or teal, a paw print, and stock photography of a golden retriever on a lawn that does not exist in this country. It is pleasant and it is completely interchangeable, and in this market it reads as foreign. Foreign reads as "not for me", and in the worst case it reads as a template site, which is the same visual category as the scams the rescue community is already braced for.

So the identity was built to look like it came from here. Not in a decorative way — no truck art pastiche, no borrowed motifs used as garnish — but in the way it handles language, colour, and humour.

Paltuu comes from paltu — the everyday Urdu word for a pet or a tame animal. It is the word people already use, which is the best possible starting point for a consumer brand.

It is also spelled four different ways by four different people, and rather than treat that as a problem we treated it as a distribution channel. Paltu, paaltuu, paltoo and Paltuu all resolve. The search understands them, the content targets them, and the brand guidelines explicitly instruct the team not to correct people who spell it differently. A name people can misspell and still find is worth more than a name people spell correctly and never search for.

The wordmark folds a paw into the double-U. It is a good joke at poster size and it stops being legible below about twenty-four pixels, which is a real size on a real phone — a tab icon, a notification, an avatar.

So the guidelines do not just show the mark; they say where it fails and what replaces it. Below 24px it becomes a maroon square carrying the paw alone, never a shrunken lockup. It sets in white or maroon-on-white, never greyscale, and never over a busy photograph. Those are three sentences that stop a brand from slowly degrading in the hands of whoever is making the next social post.

Montserrat, and nothing else, anywhere in the product. Not a display face plus a body face — one family, four weights, each with an assigned job: Regular for body copy and form labels, Medium for navigation and buttons, Semibold for card titles and prices, Extrabold for screen headers.

A single family with named roles is worth more to a team like this than a more expressive pairing would be. There is no decision to get wrong at three in the morning, nothing to license twice, and no weight drift across five different panels built by different people at different times.

This is the part of the system we are proudest of, and it only makes sense next to the architecture in chapter 04.

The platform has five kinds of user, and they are not variations on each other — an adopter browsing listings, a vet running a clinic panel, a shelter admin working through applicants, a shop admin managing storefront inventory, and a platform admin approving and moderating all of it. Several people hold more than one of those roles.

So colour is not decoration here, and it is not a mood. It is a role. Maroon is the guest and adopter surface, the default the public sees. Purple is the vet panel. Blue is the rescue organisation. Amber is the shop. Teal is platform administration. You can tell which of five products you are standing in from the corner of your eye, before reading a single word — and a rescue volunteer who also runs a shop never has to wonder which one they just clicked into.

That is a brand decision doing structural work. It is also the one part of this system that would have been impossible to design before the architecture existed, which is why it was made second.

The argument for a mascot was not that mascots are charming. It was that this product's hardest surfaces are its empty ones.

A young marketplace is full of dead ends. No listings in your city yet. No results for that breed. Your application is pending. Nothing in Lost & Found today. Page not found. Those are the exact moments a new platform loses a user permanently, and they are almost always handled with a grey box and an apology.

A character turns a dead end into someone telling you something. "No huskies in Multan right now — I'll shout when there are" is a completely different experience from "0 results", and it is the same information.

The safe version of this brief is a cute, ethnically unplaceable cartoon cat. We argued hard against it, and this was the point where the client had to take a real risk on our judgement.

A generic cat is decoration. Nobody screenshots decoration. Nobody sends decoration to their group chat. The entire value of a mascot to a company with no marketing budget is whether it travels on its own, and specificity is the only thing that makes anything travel.

So Paw-rvez is a Punjabi cat, with a name that is a pun on a real name, a personality that is recognisably from somewhere, and a way of speaking that lands instantly with the audience and would be meaningless anywhere else. That is the trade. He does not translate — and he was never supposed to, because the market is Pakistan.

A mascot delivered as one illustration is a mascot that gets used twice and then quietly abandoned, because the team has no way to make a new one and no budget to commission every state. So Paw-rvez was delivered the way a typeface is delivered — as a system with rules.

The outcome is the part that is hard to plan for and easy to recognise. Within months, people were referring to the platform by the cat. Not "I saw it on Paltuu" — the cat. He is on the 404 page, in the onboarding, in the notifications, in people's WhatsApp sticker trays, and in the group chats of people who have never adopted anything.

If you want one line to take from this case study about what branding is for: a warm colour palette made the platform look credible, and a Punjabi cat made it get shared. Those are different jobs and you need both.

Marketplaces do not have a growth problem, they have a chicken-and-egg problem, and the answer is almost always to solve the supply side manually and unglamorously before touching demand.

Our sales side worked the rescue and shelter community city by city, alongside the founders. Not a campaign — conversations. Onboarding each organisation, migrating the listings they already had scattered across Facebook and WhatsApp into the platform, and in several cases sitting with a volunteer while they posted their first animal so that any friction in the flow got found by us rather than by them.

Eight rescue partners is not a large number and that is the point. Eight organisations with real, continuous intake generate more listings, more reliably, than a thousand casual signups. They are also the trust layer — a new adopter does not know Paltuu, but they know the rescue whose name is on the listing.

The city and species pages did what they had been built two years earlier to do. Somebody in Lahore types "kitten adoption Lahore" and lands on a page with actual kittens in Lahore on it, not a homepage with a search box.

The content layer was built to the same logic — not brand blogging, but the specific things pet owners in this country search at two in the morning. Ticks and fleas in this climate. Winter care that distinguishes a Murree cold snap from a Karachi one. Grooming a double-coated dog in forty degrees. Those articles rank, they bring in people who own animals, and a meaningful share of those people end up in Lost & Found or Bazaar or, eventually, adopting a second animal.

And Lost & Found kept bringing the city back every week regardless of any of it.

Two things about the shape of that curve, both of which matter more than the endpoint.

There is no spike in it. There was no paid acquisition to spike — every user on that line arrived from search, from a rescue partner, or from one person sending another a link. Growth that looks like this is slower to start and very hard to lose.

And adoptions run well behind signups for the first half of the year before closing the gap. That is not a conversion problem being fixed. It is roughly how long it took the first rescues to trust the platform enough to list in volume — the audience was there months before the supply was. Trust has a lead time, and the gap between those two lines is what it costs.

First pet adoption platform in Pakistan, then the largest. Which is the point in a company's life where the interesting problem starts.

They came back with thousands of users, a national profile, eight partner organisations depending on them, genuine goodwill in the community, and no revenue whatsoever.

This is a good problem and it does not feel like one. The founders were carrying costs, the platform was growing, and the obvious moves were all available and all bad. So the first half of this engagement was spent ruling things out, in writing, with reasons — because a founder under revenue pressure will otherwise try all of them in sequence and damage the thing that is working.

Everybody's instinct with an engaged audience is to ask what you can sell to those people. That framing produces advertising and subscriptions, and both of them tax attention.

The better question was what those people have to do next. And the answer was sitting in the adoption data. Every completed adoption is a person who, within roughly the same week, must buy food, a litter tray or leash, a collar, a carrier, a bed, and a first round of vet supplies. They are going to spend that money regardless. Paltuu had created the moment and was handing it to somebody else for free, eight hundred and forty-two times.

The audience was not the asset. The moment was. That is a completely different product, and it is why the recommendation was commerce rather than ads.

The default move here is a Shopify store on shop.paltuu.pk, live in three weeks. We advised against it and the client backed the judgement. It is worth setting out why, because "we built it custom" is usually a bad answer and this is one of the cases where it is not.

The entire argument for this store, from the previous chapter, is that it knows things. It knows this user adopted a three-month-old kitten eleven days ago. It knows they have a Persian, which means grooming products. It knows the rescue they adopted from and the city they are in.

A hosted storefront cannot see any of that. It is a separate application with a separate database and a separate user table. You can synchronise some of it, eventually, with an integration layer that costs more to build and maintain than the storefront did — and you still end up with a redirect to a second site with a second login and a second cart, which is where a meaningful share of the buyers stop.

The one differentiator this store has over every general marketplace in the country is context. Choosing an architecture that discards the context to save three weeks is choosing to launch a worse business faster.

Cash on delivery is the dominant payment method in Pakistani e-commerce, and platforms built elsewhere treat it as an edge case bolted on at the end. Here it is the default path and it changes the whole system.

An order that will be paid in cash on a doorstep in nine days is not a paid order. It has to be modelled as a promise: it can be refused at the door, it generates a return-to-origin journey, the money arrives later from the courier rather than from the customer, and reconciling what was collected against what was ordered is a daily operational task, not a webhook. Fraud looks different. Confirmation calls before dispatch are normal practice, not a red flag.

Building that properly into the order model from day one is straightforward. Retrofitting it onto a platform that assumes payment precedes fulfilment is a permanent tax on every operational process the client runs.

Pet food and litter are volume categories with thin margins. A hosted platform takes a monthly fee plus a percentage of every order, forever, in a currency that is not the one the revenue is in. Against local margins on a bag of cat food, that percentage is not a rounding error — it is a meaningful share of the contribution, permanently, and it grows precisely as the business succeeds.

The custom build is a larger cost once. It stops being the more expensive option surprisingly quickly, and the client owns the asset at the end of it rather than renting it.

Paltuu now sells cat food, dog food, litter and training pads, grooming supplies, toys, collars, beds and accessories, delivered nationwide. The platform that could not make money is now a shop with a self-renewing audience attached to the front of it — and the adoption side, which still makes nothing directly, is the most valuable customer acquisition channel the shop has.

Adoption is an event. The relationship it starts lasts fifteen years, and every single moment of those fifteen years was happening on Instagram.

That is a strange thing to look at as a company. Paltuu is the reason a few thousand animals are in the homes they are in, and it had no presence in any of those homes after the handover. The founders wanted to fix it and, unusually, did not have a specific product in mind — they had a feeling that the community they had built deserved somewhere of its own.

What we built is a social network in which the animal, not the owner, is the thing with a profile.

This is the decision the whole app hangs on. Not a person's account with a pets field on it — every animal is its own profile, with its own name, species, breed, gender, age and bio, and its own grid of photographs. Lino is a Persian cat, one year and three months old, described by his owner as a professional yapper and treat enthusiast, and he has a page. His owner posts to the feed under their own name; the page belongs to the cat.

It reframes everything downstream. You follow animals. And for anything adopted through the platform, the profile has a beginning — the original Paltuu listing, the day it was posted, and then everything that happened afterwards. A rescue can open the page of a cat they placed two years ago and see how it went. That is the loop the company has been missing since chapter 01, and it is the emotional core of the product.

Everything above is nice. This is the part that could not be done on the website.

When an animal goes missing, the owner files a Lost & Found report, and every user within range of where it was lost gets a push notification with the animal's photograph, within seconds. Not a page they have to find. Not a post that has to be shared enough times to reach the right neighbourhood. A photograph on the lock screen of the person walking past the alley the cat is actually in.

That is a fundamentally different product from a listings page, it only works with a native app and a real local user base, and Paltuu is one of the very few organisations in the country in a position to build it — because it spent two years accumulating exactly the users it requires.

The adoption platform moderates a few hundred listings by hand. A social app is a different scale and a different risk profile, and this needed answering before launch rather than after the first incident.

So the app ships with reporting on every surface, a moderation queue that the same team already knows how to operate, blocking and muting, and community rules written in the brand's own voice rather than borrowed from a template. The animal-welfare edge cases — content that is actually a sale, cruelty, animals being advertised for breeding under the cover of a profile — have specific handling, because those are the ones that matter here and a generic policy does not cover them.

The thing worth noticing in the feed is not a feature. It is the language. "Mishti supervising the mohalla from the chatt again." #DesiCat. #CatsOfPaltuu. Nobody wrote a content strategy that produced that — it is what the community already sounds like, and the app is the first place it has been able to sound like that. Chapter 06 is the reason it does.

The apps are built, submitted, and launching on the App Store and Google Play in September 2026.

Paltuu describes itself now as Pakistan's first pet super app. That phrase would have been a fantasy in the room where we cut the scope down to adoption listings in three cities, and it is true because of that decision rather than in spite of it. Each product was built at the point where the one before it had earned it: the brand once the platform worked, the shop once there was an audience with a buying moment, the app once there was a community large enough that a location-based alert would actually reach someone.

We still run all three. The people who wrote the original scope document are the people on the roadmap now, which is the part we would point at if you are deciding whether to work with us. Nothing here was delivered and abandoned. There was no handover to a maintenance vendor, no rebuild by the next agency, no second system written because the first one could not be extended.

The vet care that got cut in chapter 02 is no longer cut. It is one of the five pillars now, with its own clinic registration and its own panel — built, as everything here was, at the point where the platform underneath it could carry it rather than at the point somebody first asked.