T—P

Bolzano · Italy

← Writing

Case Study · 21 March 2025 · 8 min read

Behind Praxis-Link: Building a SaaS

I want to write honestly about what building Praxis-Link actually felt like — not the polished version. The parts that were harder than expected, the decisions that turned out to be wrong, and what I'd do differently if I started again today.

Why I built it

I was working inside an automotive agency — not as a consultant, but as an actual employee. The first week I was there, I counted five different tools that had to be checked every morning: WhatsApp for appointment messages, a shared Excel file for client records, a folder on a shared drive for compliance documents, a third-party SMS tool for campaigns, and a paper calendar on the wall.

None of them talked to each other. Every morning, someone had to manually reconcile between them. I kept thinking: this is not a people problem. This is a systems problem. So I started building.

What I underestimated

The compliance layer. Italian automotive agencies have specific regulatory requirements around driver's license verification before test drives. I knew this going in but underestimated how much edge-case handling it would require. A photo taken in low light. A license from a non-EU country. A client who uploads the wrong document.

The OCR pipeline — which extracts data directly from the license image — took about three times longer to get right than I expected. Not because the technology was hard, but because the data was inconsistent in ways I hadn't anticipated. This is the pattern I see in most real-world automation projects: the integration is easy, the edge cases are what cost you.

The booking system change

The original version of the booking system required staff to manually confirm each appointment. I thought this was a feature — it gave the agency control. It turned out to be a bug. Staff were so busy that confirmations took 24-48 hours, which meant clients booked elsewhere.

I rebuilt it as fully self-service: the client picks a slot from live availability, uploads their documents, and receives automatic confirmation. No staff intervention unless there's a problem. Booking volume increased in the first week. This is the clearest example I have of why you need to watch how people actually use a system before you decide it's working.

What I'd do differently

I'd talk to the staff earlier. I had a clear picture of what the agency manager wanted, but the people using the system day-to-day had different priorities entirely. The manager wanted analytics. The front desk staff wanted fewer clicks. These are not the same product.

I'd also have charged for it from day one. The first version was free, which meant there was no formal feedback loop, no stakes, and no clear definition of success. Pricing forces clarity on both sides.

Next

Multilingual Design Systems

Design

← Back to site© 2025 Tashi Paris