Up The Locals - A Directory Where Verified Actually Means Something

The Problem Statement

Finding a tradie in Australia is a mess. The big directories are lead-generation businesses wearing a directory costume: you search, you get a form, the form sells your details to three or four operators, and you spend the next week fielding calls. The businesses hate it too - they’re paying per lead for enquiries that were never really theirs.

The listings themselves are worse. Half are scraped, out of date, or belong to someone who stopped trading two years ago. And nearly every platform blurs two completely different questions into one number: is this a real, contactable business and is this business any good. A “trust score” that mixes identity checks with star ratings tells you nothing useful about either.

The Solution

Up The Locals keeps those two questions strictly apart.

Verification is binary. A business is verified or it isn’t. It becomes verified when at least one contact channel - email, phone, or domain - is actually confirmed. There is no score, no level, no tiering. Because scraped channels can be wrong, an unconfirmed channel never revokes verification; it just shows publicly as “not yet confirmed”, which is honest about what is and isn’t known.

Reputation is separate. A plain 0-5 star average from published consumer reviews, weighted toward reviews attached to real completed jobs rather than five-star spam. Verification must never imply review quality, and review quality must never imply verified identity.

Contact is direct. Customers call or message the business. No middleman skimming the introduction, and no lead fees charged to the customer.

What’s Actually Built

There are three distinct products sharing one platform:

• The public registry - search by service, category, suburb, postcode, business name or ABN, with category and suburb landing pages, structured data, sitemaps, llms.txt, and aggressive public caching.
• The owner dashboard - claim a listing by confirming a channel, then manage business details, media, service tags, leads, reviews, team access, and billing.
• Admin - listing review and import, category and tag management, workspaces, enterprise provisioning, review moderation, email templates, and visual email workflows that can run in report-only mode before you arm them.

Things That Turned Out to Be Hard

Verification state sounds trivial until you have scraped data. The rule that unconfirmed channels don’t invalidate a verified business exists because early imports produced listings where a real, confirmed phone number sat next to a wrong scraped email - and letting the bad email drag the business back to unverified punished the wrong party. All of that logic now lives behind a single evaluateVerification() function, which is the only place allowed to decide.

The release process got similarly opinionated. Production releases require a clean tested main, an immutable annotated tag, and release notes, and the build verifies that the adapter-generated Worker config and every hashed asset reference match what’s actually in dist/client before anything ships. A deployment ledger links each release to its source commit, its Cloudflare deployment IDs, and its outcome.

The Stack

• Astro on Cloudflare Workers, using the adapter-generated static-assets binding.
• Turso / libSQL for the main and events databases, accessed through Drizzle.
• Cloudflare KV for sessions and cache metadata, R2 for business media and documents.
• Better Auth for magic-link, passkey, Google and Facebook sign-in.
• Plunk + React Email for transactional mail, Twilio for phone verification.
• Stripe for subscriptions and enterprise billing, Turnstile to keep the enquiry forms clean.
• Tailwind CSS 4, Vitest for unit and integration tests, in a Turborepo + pnpm monorepo.