SpecialtyBay OS
Shop software built around multi-day jobs, parts sourcing and claims, not quick-turn work.
- Category
- Repair shop operations
- Model
- Vertical SaaS
- Core platform
- ALIA Constraint Engine
- Status
- PLANNED
01 Problem
Specialty repair shops run jobs that live in the building for days or weeks, wait on backordered parts and settle through insurance or warranty claims. Generic shop software assumes quick-turn work, so these shops fall back to whiteboards, spreadsheets and memory.
The cost is lost bay capacity, parts that arrive after the customer gave up, and claims money left uncollected.
02 Specification
This is the specification we are building toward. The status column shows what exists today.
- Multi-day job managementPLANNED
Jobs are modeled around long dwell times, with every unit’s stage visible from intake to delivery.
PLANNED - Parts sourcing and backorder trackingPLANNED
Every ordered part is tracked to its job with backorder status, so nothing waits in a bay for a part nobody chased.
PLANNED - Insurance and warranty claim workflowsPLANNED
Claims are managed as first-class work with their own documentation, deadlines and follow-up states.
PLANNED - Bay and lift schedulingPLANNED
Bays and lifts are scheduled as the scarce resources they are, so long jobs stop silently blocking capacity.
PLANNED - Diagnostic history per unitPLANNED
Every unit carries its full diagnostic and repair history, so returning work starts from knowledge instead of zero.
PLANNED - Customer communication with photo documentationPLANNED
Customers get status updates with photographs, which cuts phone calls and disputes at pickup.
PLANNED - Deposit and progress billingPLANNED
Long jobs bill in stages, with deposits and progress payments instead of one invoice months after intake.
PLANNED - Technician assignment by specialtyPLANNED
Work routes to the technician whose specialty matches it instead of whoever happens to be free.
PLANNED
Updated as capabilities ship. BUILT means working and validated; nothing gets that label early.
03 System
- 01Intake and diagnosis
- 02Parts and claims
- 03Bay scheduling
- 04Repair execution
- 05Delivery and billing
04 Engineering
Domain model
SpecialtyBay is built around an explicit domain model of long-dwell repair work: units, bays, claims, parts and their states are first-class objects, not customizations bolted onto a quick-turn template. Differences between verticals are expressed in the model itself instead of in per-customer configuration.
Scheduling core
Bay and lift scheduling runs on the ALIA Constraint Engine, treating bays, lifts and technician specialties as the finite resources they are, so a weeks-long job stops silently starving the rest of the shop.
Deployment and integration
The product is cloud-delivered with an offline-tolerant shop-floor mode. It meets the accounting and parts systems shops already run rather than demanding their replacement.
05 Why this is hard
The genuine problem is modeling workflows that are genuinely different per vertical without collapsing into configuration soup. Marine, powersports and heavy truck share the shape of long-dwell work but differ in claims, parts and compliance, and every generic platform that tried to absorb those differences through settings became unusable. The engineering work is a domain model rich enough to hold the differences and strict enough to stay coherent.
06 Design constraints
- Built for weeks-long jobs, not quick turns
- Claims are first-class work, not attachments
- Usable at the counter and in the bay
- Meets existing accounting and parts systems
- Vertical differences live in the model, not in settings
07 Design partner program
Design partner program.
We are looking for a small number of design and pilot partners. A partner gets the problem solved for their operation first, direct influence on the specification above, and pilot pricing. In exchange we get reality: real constraints, real data, real operators. No external partner is engaged on this product yet.