A pet care platform, for the operations team behind the dogs.

Most products that promise “multi-tenant later” end up rewriting from scratch when later arrives. Tenancy is rarely a feature you can add — it touches identity, data, storage, configuration, billing, and reporting all at once. The cheapest way to keep the option open is to design the seams in from day one.

Soul Konect’s business tables have a nullable tenant_id from the first migration. Media storage keys are shaped tenants/{tenant_key}/... even though only one tenant exists today. Brand identity stays in configuration, not domain logic. Queue payloads will carry tenant context the day they need to. When the second daycare onboards, the work is a column flip and a tenant fixture — not a quarter of refactoring. The product stays single-tenant in behaviour and multi-tenant in shape.

Soul Konect was built in named, contracted milestones. Milestone 1 (auth, parent register/login, pet profile CRUD). Milestone 2 (pet onboarding details, vaccinations, vet info, care profile). Milestone 3 (booking and check-in/check-out). Milestone 4 (invoicing). Milestone 5 (payments). Each milestone had a written scope inside PROJECT_RULES.md and a list of things explicitly NOT to build yet. The next milestone didn’t start until the previous one was tested, reviewed, and stable.

The list of forbidden work — Razorpay live integration, payment webhooks, separate admin mobile app, video transcoding, push delivery, advanced offline sync, ratings, recipe comments — is as load-bearing as the work itself. Scope creep is the failure mode of every product that ships late. Written scope is the cheapest insurance against it, and a written rulebook gives every contributor (including AI coding agents) the same picture of where the boundary is.

The lazy path when adding admin-on-mobile is to spin up a second Expo project — admin app for staff, parent app for owners. Two codebases. Two App Store listings. Two release cadences. Two design systems that drift apart by month three.

Soul Konect rejected that path. The current active milestone is explicit: “one mobile app with role-based experiences instead of a separate admin mobile codebase.” Parents and admins share the same Expo Router, the same component library, the same release pipeline. Role-based routing decides which screens render. Half the surface area, full the value, and the design system stays consistent because there is only one of it.

The Laravel API is organized into nine domain modules: Identity and Access, Owners and Pets, Documents and Vaccines, Meet and Greet, Bookings and Capacity, Check-in/Check-out, Payments and Invoices, Notifications, and Admin Reporting. Each module has its own controllers, FormRequests, services, models, policies, and tests. Controllers are deliberately thin — validation in FormRequests, business logic in services, persistence in models, authorization in policies.

Everything that doesn’t have to be synchronous goes through a Redis-backed Laravel queue: push notifications, invoice generation, payment webhook reconciliation, document processing, operational reminders. The result is a request lifecycle that stays predictable for the user and a side-effect lifecycle that’s restartable when something fails. The dispatcher is the same whether the side effect is a notification or an invoice.

Vaccine certificates, consent forms, and pet incident records are not generic file uploads. They’re regulated records that need access control closer to financial data than to user avatars. A single overshare here costs trust in a way a missed booking never would.

Soul Konect routes media through a three-service architecture: MediaUploadService handles the upload contract and validation, MediaPathService computes tenant-shaped storage paths (tenants/{tenant_key}/pets/{pet_id}/...), and MediaAccessService issues signed Cloudflare R2 URLs scoped to authenticated, authorized requests. The implementation enforces tenant isolation at the storage layer even before the database row-level scope catches it. The default state is safe: a developer cannot expose another tenant’s documents without explicitly forging both an auth context and a tenant key.