Use case
Automotive Scheduling Software
A repair shop does not schedule technicians. It schedules bays, and a bay is occupied by a car that is waiting for a part nobody has ordered yet.
Tekmetric and Shopmonkey are the right answer for most independent shops, and Xtime is what you will be using anyway if you are a franchised dealer, because Cox Automotive sells it into the OEM programme. Those products cover scheduling as one part of shop management, which is the correct shape: in a repair shop, the schedule is downstream of the estimate.
If you are comparing them, this page is not trying to talk you out of it. It is about the specific reason shop scheduling resists generic appointment software, and what is left if you do decide to build.
Why generic appointment booking breaks here
Calendly-shaped software assumes a person with a calendar and a service with a duration. A repair shop violates both assumptions on the first job of the day.
One vehicle, from phone call to invoice
A customer books a slot for a noise
The complaint is not a service. Nobody knows the duration, the parts, or the price yet, so the booking is really a diagnostic appointment with an unknown tail.
Duration unknownDiagnosis produces an estimate
Now there is a real job with flat-rate hours from a labour guide, plus parts. This is the point where a generic booking tool has already lost, because the appointment it created bears no relation to the work that was found.
The real job appearsThe customer approves some of it
Partial approval is the norm. Declined work has to be recorded rather than deleted, because chasing it later is a genuine revenue line for a well-run shop.
Scope changesParts are ordered, and the bay is held
The vehicle occupies a lift while it waits. This is the constraint that matters and the one no calendar models: the resource is blocked by something that is not labour.
Where the schedule breaksThe work is done, checked, and invoiced
Technician hours are logged against flat-rate times, which is how the shop knows whether the job was profitable and how the technician gets paid.
Two clocks, not one
Steps two and four are the ones that rule out generic appointment software. The scheduled unit is a bay-day, and its length is decided after the booking is made.
Three consequences fall out of that, and they are what to test any product against. Capacity is measured in bays, not people. Flat-rate hours and clock hours are separate numbers that both have to be recorded. And a job's duration is a moving estimate rather than a fixed field.
The case for building one
Thin, but real in two situations.
You run several locations and want one queue across them, with the ability to move a job to the shop that has a free lift tomorrow. Multi-location capacity is where the mid-market products get rigid.
Or scheduling is a feature of something bigger you are already building: a fleet maintenance system, a mobile mechanic platform, a warranty administrator. Then you are not shopping for shop-management software, you are building a product that happens to contain a schedule.
What actually installs
pack-calendar gives you five calendar views, drag to reschedule, event invites, and working hours, on a
CalendarEvent model with startAt, endAt, an organiser, and attendee ids, scoped to an organisation.
starter-saas-workos underneath it gives you accounts, organisations, and roles.
Drag to reschedule is genuinely the interaction a service advisor needs, and working hours are already modelled. Everything that makes it automotive is not there.
Yours to build
- Bays as bookable resourcesThere is no Room or Resource model in the registry. A lift has to become a table before you can stop it being double-booked, and the no-overlap rule is a Postgres exclusion constraint you write as raw SQL rather than something Prisma generates.
- Vehicles and customers as separate thingsOne customer, several vehicles, and a service history that belongs to the VIN rather than the person. That relationship is the spine of a shop system and none of it ships.
- Estimates, approvals, and declined workThe estimate-to-authorisation flow, partial approval, and a record of what the customer said no to. This is most of the product.
- Parts, and the waiting they causeOrdering, arrival, and a job state that holds a bay while nothing is being worked on. Modelling 'occupied but idle' correctly is the difference between a schedule that reflects the shop and one the advisor ignores.
- Labour guide integrationFlat-rate times come from a third-party data provider such as MOTOR or Mitchell 1. Their data and their bill, not ours, and it is a licence you negotiate separately.
Nothing above is a small job. Read the list, then look again at Tekmetric's price.
The honest summary
Buy Tekmetric or Shopmonkey if you run a shop. The scheduling problem here is genuinely specialised, and the specialists have already solved the parts that take longest.
Build if the schedule is one component of a larger product you own, because then the calendar interface, the organisations, and the auth are a real head start and the automotive logic is the interesting part you wanted to write anyway. The install below shows what you would be starting from.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeQuestions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.