The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Instructor, equipment and time slot together decide how many people a class can take. Members buy packages, so each reservation draws a credit off a balance, while cancellations and no-shows post to it differently. An invoice arises at the sale; usage is read from the calendar.
Visit the site →A studio hour has a hard ceiling: one instructor, a limited set of equipment, one slot on the clock. Members, though, do not buy an hour. They buy a package of classes.
At Pilatesco those two facts lived in different places. The calendar knew which hours were taken, a notebook held who had credits left, and whether a cancelled class gave its credit back was argued in messages. The system had to make a booking mean something to the balance.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
Instructor, equipment and time slot together set how many places an hour has; private sessions and group classes each open under their own rule.
Booking a class draws one credit off the member's package; the balance lives on the member record instead of a separate ledger.
A cancellation, a no-show and an attended class each post to the balance differently, and the rule decides which returns a credit.
An invoice arises when a package is sold; the usage plays out across weeks of calendar. Both sit on the same member record.
| Challenge | Result |
|---|---|
| How many people fit an hour depends on instructor, equipment and the slot together | A full hour shows as full, with capacity derived from instructor and equipment |
| Members buy packages, but the remaining credits are tracked off-calendar in a notebook | Remaining credits sit on the member record rather than in a notebook |
| Whether a cancelled class returns its credit gets settled over messages, not by a rule | Cancellations and no-shows post to the balance by rule, not by negotiation |
| Private sessions and group classes share one calendar while obeying different capacity rules | Private sessions and group classes share the calendar, each opening at its own capacity |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
