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.
