iVet Platform

A veterinary care provider was running day-to-day operations across eight separate internal tools — booking, staffing, pricing and reporting each living somewhere different, with no single source of truth between them. The brief was not to modernise one of those tools but to replace all of them with one platform, and to do it inside a fixed six-month window so the business could move on to franchise expansion.

Three constraints pulled against each other. The scope was broad — eight tools' worth of domain logic, including the pricing and cost calculations the business ran on. The deadline was fixed rather than negotiable. And the result had to be genuinely multi-tenant from day one, because the point of the rebuild was to make franchise expansion possible; a system that assumed a single clinic would have had to be rebuilt again a year later.

The reporting requirement raised the stakes on the data model. Margin reporting had previously been assembled by hand across tools, which meant it was slow and periodically wrong. Producing it automatically and in real time meant the cost and pricing data had to be correct and consistent at the source, not reconciled afterwards.

I scoped and built the platform solo, using agentic development as the lever that made the timeline viable — carrying the repetitive breadth of the buildout so the effort could go into the domain logic and the architecture that had to be right.

The stack was chosen for how little of it there was: Next.js 15 on the App Router for the application, and Supabase for database, auth and storage. One coherent surface, no service mesh to operate, and no infrastructure work competing with the deadline.

Consultations are embedded directly through the Whereby API rather than handing patients off to a third-party link, with custom interactive waiting rooms built around the call so the telehealth flow belongs to the product.

Tenant isolation is enforced with PostgreSQL Row-Level Security, in the database rather than in application code. Every query is constrained by tenant at the point of access, so a clinic cannot read another's records even if application code is wrong. This is the decision that makes franchise expansion a configuration change rather than a rewrite: adding a clinic does not touch the isolation model.

The modules — booking, staff management, pricing — were built against one shared schema rather than as separate applications sharing a login. That is what makes the automated margin reporting possible: cost and pricing data has a single definition, so reporting reads from the same source the operational modules write to, and there is no reconciliation step to get wrong.

Eight legacy tools collapsed into a single source of truth, delivered to production inside the six-month window. Operational silos and the manual friction between them were eliminated, and real-time margin reporting — previously assembled by hand — became automatic. The platform gave the business the technical foundation it needed for franchise expansion.