Before you buy shop software, ask three questions. Who uses this every day, and are they on the same version I am buying? How many other vendors will I still need to run the front counter? And can I watch someone build a ticket live, take a call on it, send the estimate by text and collect payment without leaving the screen? Any vendor should be able to answer all three in ten minutes. Here is why those three matter, told through how Pista started: a shop owner who still runs South Florida repair shops built it because the front counter was spread across too many vendors.
Why does it matter who uses the software every day?
Because the daily user is the one who finds the problems. If the people who built the software also run a shop on it, the bugs land on their invoices first. If the daily users are a support team and a demo account, you will be the one finding the problems, on a Saturday morning, with a customer at the counter.
That is how it started. The founder runs repair shops in South Florida. Those shops used to run the front counter on a stack of vendors, each with its own login. One system for the repair order. Another for the phones. Another for the website and booking. Another for review requests. Another for texting customers and taking payments. None of them talked to each other.
A customer calls about a ticket. The writer puts them on hold, opens a second window to find the RO, then opens a third to see whether the estimate text ever went out. Another customer is standing at the counter. Three cars on the lifts, four in the lot, and the writer is clicking between tabs instead of talking to people.
The founder tried the big shop systems. They were fine at the ticket. They still needed the rest of the stack. So the founder started building the missing pieces inside the shops, with techs and writers using each piece the same week it was written.
What does 'built inside a working shop' actually mean?
It means the first user of every feature was a service writer with a line of customers. If the AI service writer took too long to build a ticket from a VIN and a sentence, the writer went back to typing it by hand, and the founder heard about it before lunch. If the phone system dropped a call, or the AI receptionist booked an appointment on the wrong day, the shop lost a customer, not a test case.
Each new piece replaced a vendor the shops were paying for, and it had to be at least as good as what it replaced. If it was not, the writers went back to the old vendor and the founder had to fix it. That is a slower way to build software. It is also the only way to know a feature holds up when the phone is ringing.
What did a working shop need first?
The ticket, because nothing happens in a shop without a ticket. After that, the pieces came roughly in the order of the founder's own headaches.
| Order | What got built | The Saturday problem it fixed |
|---|---|---|
| 1 | AI service writer | Writers typing every line by hand while customers waited |
| 2 | Phone system inside the ticket, with an AI receptionist | Callers on hold while the writer hunted for the RO in another window |
| 3 | Shop website with online booking | Booking requests landing in an inbox nobody checked during the rush |
| 4 | Review requests | Happy customers driving off without anyone asking for the review |
| 5 | Two-way texting with text-to-pay | Estimates and payment links going out from a separate app with no ticket attached |
Later came the pieces that make the ticket itself faster: MOTOR labor times, PartsTech parts ordering, Carfax history and digital inspections with photos. Then the back office: time clock, inventory and purchase orders. Same rule every time. If a writer would not use it on a busy morning, it was not done.
Why does it matter that the founder still runs shops on it?
When a new version rolls out, it goes to the founder's shops first. If a report is wrong, it is wrong in the founder's own numbers. If a tax line is off, it is off on a real invoice a real customer is about to pay. The founder's writers are not shy about saying so.
It also keeps the product honest about what a shop needs. A shop does not need forty reports. It needs a few numbers it trusts: gross margin on the week, what each writer sold, and what is still waiting on parts. The founder checks that margin screen every morning, on real shops, before any new version reaches anyone else. Your shop's number will be your own. The point is that the person building the software looks at the same screen you will.
How do you run the three questions on any vendor?
Ask the first question and listen for a shop, not a department. Who uses this every day, and are they on the version I am buying? A good answer is a working shop you can see. A weak answer is a customer count or a testimonial page. Neither tells you whether the people who built it feel it when it breaks.
Ask the second question and make them count. How many other vendors will I still need? Go down the list together: phone, website, booking, reviews, texting, payments, parts, inspections, accounting. Keeping a vendor or two you like is fine. Just know the count before you sign, because every extra login is a window your writer opens while a customer waits.
Then ask to see the ticket. Not the dashboard. The ticket. Watch someone build one from a VIN and a sentence, take a call on it, send the estimate by text and collect payment. Time it. Count the windows. That is what your Saturday morning looks like on that software.
Run the same test on Pista. Book a live demo and ask to see a ticket built on the call. Every plan starts with 30 days free, so your own writers can put it through a real Saturday before you decide.
What to do this week
- Count your vendors and logins. Write down every system the front counter touches on a busy day.
- Time one repair order from first call to paid invoice. Note every window the writer opens.
- Pick your worst hour of the week and picture it on one screen. That is the bar any new software has to clear.
- Ask every vendor you talk to the three questions, then ask to watch a ticket built live, not a slide deck.