PetVerse — A Pet-First Platform

A pet adoption platform I'm building from the ground up — starting as an SEO-driven adoption hub, growing into a multi-vendor marketplace, and headed toward a pet-first social network. A Turborepo monorepo with a public Next.js site and a set of Node services sharing one Postgres database.

Overview

PetVerse is a long-running personal project that I’m building deliberately, phase by phase. The vision is a blend of Airbnb (trust), Instagram (engagement), and Amazon (scalability) — but tailored for pets: connecting paws with hearts.

It starts as an adoption and content hub, scales into a marketplace where shelters, food shops, vets and groomers each operate under one roof, and ultimately becomes a social network where adopted pets get their own profiles.

Adopting a pet is an emotional decision, so the design brief is as much about trust and warmth as it is about performance and SEO. That tension — building something that feels humane while being architected to scale — is what makes it interesting to work on.

Where it is now

I want to be honest about this: it’s a work in progress, not a finished product. The public-facing Phase 1 site is live and functional, and the backend foundation is in place. Later phases are designed and specified in detail but not yet built.

What’s real today:

A public Next.js 16 site (apps/web) — browse adoptable pets, read care content, take a matchmaker quiz, and sign in.
Better Auth backend (auth-service) — cookie sessions, Google OAuth, all served from a Node/Express service that the frontends talk to.
A vendor service (vendor-service) — pet and vendor management via Express + Prisma.
Two dashboards (admin-dashboard, vendor-dashboard) — a super-admin panel and a vendor/shelter management panel, both Vite + React.
A shared Prisma schema in packages/db, one Postgres database, and a compose file that runs Postgres + Redis locally.

How it’s put together

A Turborepo + pnpm monorepo. Five apps and a set of shared packages under the @repo/* namespace. One repo, clean boundaries, fast builds.
Next.js 16 (App Router) with server-side rendering for the public site — adoption listings and a blog have to rank on Google, so SEO drives the rendering choice.
Express + Node services on the backend, each owning one domain. Phase 1 ships as a modular monolith with separate runtimes — shared Postgres, HTTP between services, no distributed-transaction tax — rather than pretending to be microservices before the scale justifies them.
PostgreSQL + Prisma as the data layer, chosen deliberately over document stores for the relational core (User ↔ Vendor ↔ Pet ↔ Application) and multi-row transactions.
A design system in Tailwind v4 with CSS-variable tokens, shared across all three frontends through @repo/ui.

The roadmap

Phase 1 · Adoption hub        — live now
Phase 2 · Multi-vendor
  marketplace + dashboards     — designed, being built
Phase 3 · Pet social network   — specified, not started

Phases are additive — each one stays live while the next is built.

Phase 1 — Adoption & content hub (current)

The public half. SSR pet listings, an adoption flow, a matchmaker quiz, and SEO-optimised care content. Performance and discoverability are the point.

Phase 2 — Multi-vendor marketplace

Opens the platform to shelters, shops, vets and groomers, each self-onboarding behind a verification gate. Two dashboards split the work: a super-admin panel for approvals and moderation, and a vendor panel for running a business.

Two ideas here are worth calling out because they shape everything:

One identity, many roles. A person who’s a customer, a shelter admin and a shop admin has a single login; the role context is chosen per session, not per account.
Trust-based moderation. Instead of “every listing needs an admin’s rubber stamp,” each vendor carries a trustLevel that decides whether their listings auto-publish or queue for review. Admins handle exceptions and abuse, not the steady state — the only approach that scales past a handful of uploads.

The engagement loop: feeds, pet profiles, badges and gamification, and a media pipeline for video that stays out of the way of the uploader.

Things worth remembering

Distributed systems are a cost, not a feature. It’s tempting to reach for Kafka and per-service databases on day one. I didn’t — the same path Shopify, Notion and Stripe took, migrating one bounded context at a time only when a service actually starts dominating DB load. Phase 1 is HTTP between services over a shared database; Kafka and Redis queues enter only when there’s a problem they genuinely solve.

The data model chose PostgreSQL for me. Before I’d built anything, connected entities (a user, a vendor, their pets, applications, orders) all pointed to foreign keys, joins and ACID transactions. Postgres handles years of that mix — and gives me JSONB and PostGIS when the flexible or geo parts need it.

Design system up front saves real time across three apps. One Tailwind token set and a shared component package means the public site and both dashboards stay visually consistent without three parallel styling efforts.

Honesty about scope keeps momentum. The project is explicit about what’s deferred — payments wiring, real-time messaging, i18n, native apps. Knowing what’s deliberately out of scope is what keeps each phase shipable instead of endlessly expanding.

This is a living project — I’m building it in public, one phase at a time.