Dog walking & pet care · Folkestone
A dog-walking website with a full pet-care portal behind it: four service pages a search engine can read on the first response, and a booking system where the rules about which dog can do what are written down instead of remembered.
Surface
Public site + private portal
Area served
Folkestone and east Kent
Roles in the portal
Customer · walker · owner · admin
Status
Live at justwalkingthedogs.co.uk
The brief
Just Walking The Dogs is a local business doing four distinct jobs — walking, one-to-one training, feeding visits and a pet taxi — across five towns and villages. The website had to make each of those findable on its own terms. Behind it, the work of actually running the round needed somewhere to live that was not a phone and a notebook.
A visitor who wants a phone number should not download a booking calendar to get it. The public pages are the only thing in the initial bundle; everything behind sign-in — the portal and the Firebase SDK that comes with it — sits behind lazy route boundaries.
The business names four services. Each one got its own route, its own questions and its own structured data, rather than four anchors on a single homepage that ranks for nothing in particular.
The business already worked this way — some dogs need a meet and greet first, some are solo-walk only, some have no off-lead permission. That was a set of rules held in someone's head. The build turned it into an eligibility engine the booking form has to obey.
Before this build, a new request was a database row visible only inside the portal: the owner found out by happening to look, and the customer got no confirmation at all. Booking email now goes out from the Worker.
What was built
The two halves share a domain, a palette and a deployment, and almost nothing else. The front is public, indexed and built to be read cold. The back is signed-in, closed to search, and built to be used every day.
Public
A homepage and a page each for dog walking, dog training, pet feeding and the pet taxi, plus privacy and terms. All of them are in the site’s own sitemap and return index, follow.
Behind sign-in
Bookings, dogs, customers, availability, community, training, settings and the admin screens. Every one is blocked in robots.txt and served noindex, nofollow by the Worker, because they hold real people and real animals.
The journeys
Someone searching, the owner, a client and a walker all want something different from the same system. Each gets a first screen built around their own next step.
Dog walking, dog training, pet feeding and pet taxi each get their own route, their own FAQs and their own structured data. The Worker writes the title, description, canonical and schema into the very first response, so a crawler does not have to run the app to understand what the page is about.
The three portal screens above are the delivered interface running against fabricated records. See the data-protection note below.
The idea the build turns on
A dog-walking business runs on judgements that are easy to hold in your head and expensive to get wrong. This one has not met that dog yet. That one cannot go off lead. That one is solo walks only until the training has happened. Every booking form on the internet ignores all of it.
Here those judgements are fields on the dog’s record — a walk tier, a training tier, taxi and house-sitting eligibility, off-lead permission and an explicit list of approved services — and a single rules function decides, for every dog and every service, whether a booking is even offered. When it says no it gives the reason, in the words the owner would use.
The customer's booking form, the owner's booking screen and this matrix all call the same function. There is no second copy of the policy to fall out of step.
“Meet & Greet required first”, “Off lead permission required”, “Not on this pet's approved service list”. A closed door with a reason on it is a prompt, not a dead end.
Every dog against every service, so the owner can see at a glance who is waiting on a meet and greet or a training clearance.
Visual proof · the public site
The illustration and the sketched paw prints carry the warmth. Everything underneath them is a hard 2px ink border and a flat offset shadow, so the page still reads as structure rather than mood.
What is this, is it available where I live, and how do I start. The FAQ block under each one is written for the questions people actually ask a local dog walker, and it is the same copy the page’s structured data carries.
Most of the traffic to a local pet-care site is someone standing up, one-handed, deciding whether to call. Tap targets stay at 48px, the call button sits in the header bar on every page, and the enquiry form is the last thing on the page rather than a modal fighting for attention.
Visual proof · behind sign-in
Dogs and their notes, bookings and recurring series, customers and their onboarding state, business hours and blocked dates, a community feed for walk updates and announcements, a training library, and an audit log of every change. It is the difference between a website that advertises the business and one that runs alongside it.
Requests, confirmations, recurring series and a calendar, filtered by service, status or date.
Health, behaviour, recall, lead manners, triggers, vet and emergency contacts — on the record, not in a message thread.
Announcements, offers and per-customer walk updates in channels, so a photo from the field has somewhere to go.
Who declined that booking, who moved that dog to Training First, and when. Append-only, admin only.
Why it looks like this
The public site is loud on purpose: a heavy serif at display size, thick ink outlines and flat drop shadows that make every card look like something you could peel off the page. The portal keeps the same beige, ink and orange but softens every edge — warm off-white cards, generous radii, low shadows — because it is a screen someone looks at every morning, not once before they call.
Wordmark, hero and every section heading
Body copy, forms, navigation and portal data
#F4ECE1 ground · #1D1E21 line and type · #FF7648 action
#edf3e7 and #FFD1C2 — section shifts and status, never decoration
Ground
#F4ECE1
Ink
#1D1E21
Action
#FF7648
Sage
#edf3e7
Peach
#FFD1C2
How it is built
React 19 with React Router and Tailwind v4, built by Vite and served by a Worker through the ASSETS binding with a single-page-application fallback, so a hard load of /privacy resolves.
The Worker uses HTMLRewriter to set the title, description, Open Graph tags and canonical per public route, append ProfessionalService and Service JSON-LD, and prepend a no-JavaScript summary. The app stays client-rendered; a crawler no longer has to run it.
All sixteen portal paths are Disallow-ed in robots.txt and served with X-Robots-Tag: noindex, nofollow by the Worker. They hold customer and animal records and have no business being indexed.
Auth, Firestore and Storage carry the portal. None of it is in the initial download — the module that imports Firebase is only ever reached through a lazy import from the marketing routes.
Cloudflare Email Sending, deliberately on the notifications subdomain rather than the apex: onboarding the apex would have handed Cloudflare SPF and DKIM for a domain that already carries the business's Google Workspace mail.
The request carries only a Firebase ID token and a booking id. The Worker reads that booking back out of Firestore using the caller's own token, so the security rules decide what it is allowed to see, and the email is composed from the database — never from the request body.
Scope
A build this size is mostly decisions about what not to make. These are the four worth naming, because each one is a thing a reader might otherwise assume is there.
Walks are quoted after a conversation about the dog, so publishing a price list would have created the wrong first question. Prices live on the services the owner manages inside the portal.
The portal takes bookings, not money. Billing is a link the owner controls, and the advanced training programme checks out externally. Adding a payment processor would have pulled PCI scope into a build that did not need it yet.
The public enquiry form composes the message in the visitor's own email client. It is the honest current state of that flow, not a silent failure, and it is the next thing worth wiring up.
There is no review surface and no GPS tracking anywhere in the build. Neither was scoped, so neither is implied.
Trust is part of the work.
There is no traffic, ranking, enquiry, booking or revenue figure anywhere on this page, and no quote from the owner. None has been measured or given, so none is published. Everything above is something you can see on the live site or in the delivered build.
Every portal screenshot is fabricated data on the real interface, captured from a scratch copy that has no route to the live database. No number, name, dog or booking on those screens is real, and none of them should ever be quoted as if it were.
Most small service businesses run on judgements nobody has written down. Getting them into the system is usually the difference between a website that looks nice and one that saves the owner an hour a day.
