RoverCT is not a website project. It is the software around the business.

The operating problem

Advanced CT imaging has always lived where the machine lives. A veterinary practice that wants a scan refers the case out to an emergency hospital or a radiology clinic, loses the client for that visit, and waits on someone else’s schedule for the result.

RoverCT changes where the machine is. A Claris V scanner arrives in the practice’s parking lot for a half day or a full day, and the practice offers advanced imaging without buying, housing, staffing or maintaining a machine.

That is a good idea with an operational problem attached. The business only works if the right practices can find it, understand an unfamiliar service, register, book a day that a vehicle can actually reach, get records back, and be invoiced correctly — repeatedly, without the founder holding it together by memory and phone.

Why a website alone would not solve it

The obvious first purchase is a website. It would not have worked.

Every hard part of RoverCT happens after someone decides they are interested: which counties can be served on which day, whether a practice is registered, what happened on the last visit, what the practice owes, and which requests are urgent enough to break the schedule. A brochure site with a contact form hands all of that back to a person with a phone.

The build is therefore a business operating system with a public site attached, rather than a website with software bolted beside it.

What Goldstone is building

One system covering acquisition through payment: the public site, practice registration, the portal practices work in, request-based scheduling, county service-area logic, practice records and notes, invoicing, a payment workflow, urgent-request routing, and the operator dashboard the day is run from.

The database was designed for multiple organizations from the first commit — not because RoverCT has franchisees today, but because retrofitting isolation into a single-operator system later is a rebuild rather than a feature.

Architecture decisions that keep the options open

Three choices were made early, each cheap at the time and expensive to add afterward.

Multi-organization from the first commit. Every tenant-scoped table carries an organization, and isolation is enforced in the database rather than by remembering to filter a query. That is what makes a second operator a configuration change instead of a migration.

Never a diagnostic viewer. The system receives, archives, routes and tracks studies and reports. It does not display images for interpretation, because a validated diagnostic viewer is a regulated product and radiologists already read on their own. Knowing what not to build is most of what kept this project deliverable.

The scheduling model follows the vehicle. Availability is decided by which counties a vehicle can reach on a given day, rather than by a generic calendar, because a schedule that looks full and crosses the region twice loses a day’s work.

What this demonstrates for other mobile businesses

A mobile veterinary CT service is not a roofing company, a restoration contractor or a mobile grooming franchise, and the workflows are genuinely different. What transfers is the shape of the problem: a service that travels, capacity limited by vehicles and geography, customers who need to book and be billed, records that must outlive whoever answered the phone, and an owner who becomes the bottleneck the moment the second vehicle arrives.

Goldstone architected around that model once. The same foundation — identity, organizations, permissions, scheduling, records, billing, reporting — is what the next mobile operating system starts from.