Keeping the thread
of a small practice.
Building a working path from the first enquiry to the next thing you promised to do.
Oceanheart Studio is practice software for independent therapists, coaches, bodyworkers and small teams. Rick Hallett is developing it alongside the wider Oceanheart offer: practical engineering shaped around the way people actually work.
Explore the fictional practice demo →The problem lives between the screens.
An enquiry arrives in an inbox. A name moves into a contact list, a time into a calendar and a promise into someone’s memory. Each tool can work perfectly while the overall process still depends on the practitioner remembering what happened elsewhere.
The initial product decision was to make that sequence coherent: enquiries, clients, services, bookings and tasks belong to the same practice and connect to one another. The interface follows the work through those transitions.
Start with one complete journey.
- Receive an enquiry. Bring a selected Gmail message into Studio and retain its connection to the enquiry.
- Establish the client relationship. Link the client record instead of repeatedly copying contact details.
- Arrange the work. Choose a service and book a time, with conflicts and optional practice hours checked on the server.
- Keep the commitment visible. Create a follow-up task and return to it in the practice workspace.
This journey provides a concrete way to evaluate the product. A useful screen must also leave the next step in a sensible state.
Design for the interruption.
A network response can disappear after a booking has been saved. A user can click twice. Another owner can edit the record while a form is open. These are ordinary working conditions.
Studio uses stable request receipts so a repeated command can return the original result. Revision checks detect stale edits. Related database changes happen together, so a failed conversion cannot leave half a workflow behind.
The same principle guided the payment prototype. Stripe test Checkout and signed webhook reconciliation were exercised on a fictional booking. Returning to the browser is separate from establishing that a payment succeeded; the provider’s verified state determines the result.
Let the practice choose its rules.
Weekly availability is optional. Owners can record their usual hours without immediately preventing exceptions. When enforcement is enabled, the whole appointment must fit the allowed interval in the practice’s saved time zone.
That distinction keeps a new feature from silently changing existing appointments or the way a practice already operates. Daylight-saving transitions, retries and concurrent settings changes are checked as part of the scheduling contract.
Give assistance a source and an owner.
The next layer begins with a small source library. Owners save a version, review it and explicitly approve it for retrieval. Cited answers return supported excerpts from selected sources, with links back to the relevant version and passage. Missing support produces an abstention.
An action is a separate decision. A task proposal shows its exact wording and due date before approval. Execution rechecks the owner, the source state and the proposal; a retry returns the same task. Rejecting the proposal creates nothing.
The first implementation deliberately limits the assistant’s reach. It makes the evidence and proposed effect inspectable before adding more kinds of assistance.
Prove the behaviour where it runs.
Focused tests cover tenant boundaries, stale state, duplicate requests and malformed source references. Independent review checks the implementation against those contracts. Hosted checks then exercise the deployed frontend and backend together.
By September 2026, hosted staging checks had demonstrated source save/edit/approve/archive, cited excerpts and revocation, explicit task approval and rejection, and a signed-webhook-confirmed test payment. Booking-hours enforcement had also been released and checked in production. These are delivery results; real-practitioner UAT will establish which parts help in daily use.
The next measure is usefulness.
The first UAT wave will follow the complete enquiry-to-follow-up journey. We want to learn where people hesitate, where the language does not match their practice and where they still need a workaround.
That feedback will shape the next release. The ambition is a maintained product with enough consistency to depend on and enough room to adapt when someone’s work changes.
Talk to Rick about trying Studio →