Every year, three or four times a year, someone in this industry asks me the same question: why the hell did you build all of that yourself when you could have just paid Limo Anywhere?
It's a fair question. I've written it out enough times that I figured I'd put the answer in one place. So here it is.
The short version
Because the products for sale were built for a different operator than the one I was becoming, and the closer I got to the ceiling of what those products could do, the more I could see that no amount of add-ons or custom development was going to fix the underlying shape.
So I stopped fighting the shape and I started drawing my own.
The long version is a decade-long story with more embarrassing moments than victories. Here's the honest version.
Where it started (one brand, one phone number)
I started with one brand: Unlimited Charters. Party buses, charter buses, limos, weddings, corporate shuttles, the whole passenger-transportation stack. Started small. One phone number. Spreadsheets for pricing. Emailed contracts. Manual invoicing.
Grew. Added vehicles. Added drivers. Added affiliate partners in cities I didn't want to buy vehicles in myself. Added a second phone number for the after-hours line. Added a booking form on the website. Added a payment processor. Added a proper CRM to replace the spreadsheet.
The CRM at the time was SuiteCRM — open-source, self-hosted, deeply customizable. Not designed for limo operators, but I could bend it. And I did — added custom modules for leads, quotes, vendors, vehicles, payments, cards. It got me a very long way. It's still running today, mostly, holding parts of the operation together while we migrate off it.
So far, so normal. This is the story every operator tells.
Where it broke (three brands, three phone numbers)
Second brand: Baltimore Trips. Same operation, different geographic focus. Different phone number, different logo, different customer expectations.
Third brand: Philly Charters. Same again.
Every off-the-shelf reservation system I looked at was built for the shape "one operator, one brand, one customer base." I was becoming "one operator, three brands (soon more), overlapping fleet, overlapping vendor network, shared 24/7 dispatch desk, distinct customer-facing sites."
Every path led back to the same conclusion: to make an off-the-shelf product do what I needed, I was going to have to run three separate instances of it, pay three separate license fees, do three separate customizations, and manually reconcile everything on the back end. That's not multi-brand. That's three businesses pretending not to know each other.
The moment you have two brands sharing one dispatch desk, off-the-shelf reservation software stops being infrastructure and starts being a tax.
The specific things that pushed me over
1. Vendor management at scale
By the time we had four brands, our affiliate/vendor network was in the hundreds. Not the built-in "here's a shared affiliate network of everyone" that Limo Anywhere gives you — I mean our network, curated over a decade, with specific commercial terms per vendor, per vehicle class, per city, per season. There is no reservation product on the market that models a vendor relationship the way we needed to. So we built our own vendor portal — vendors log in, see requests, quote, get dispatched, get paid — the whole surface.
2. Payments across brands
We settled on Fortis as the payment processor. But the way we needed to route payments — brand-specific merchant accounts, tokenized card vault so cards get charged the right merchant per brand, vendor payouts on the same rails — required control below the reservation-widget layer. That was the moment I stopped shopping and started writing.
3. SEO at multi-brand scale
This one surprises people. But every serious transportation operator eventually figures out that the customer's first search is local. "Party bus rental Nashville." "Charter bus quote Cleveland." "Wedding limo Philadelphia." Getting to page one for those queries across 40,000 US cities, in seven brands, with distinct local content per brand — that's not a plugin. That's an entire content pipeline. We built one. Half a million pages later, it's the reason organic traffic feeds all seven brands.
No reservation-software vendor is going to build that for you. It's not their category.
4. Dispatch as a shared resource
The single biggest operational advantage of running seven brands from one company is that we share a dispatch desk. One team of humans, 24/7, answering the phone as whichever brand the customer thinks they're calling. Our tools had to model that: when a call lands on the Baltimore Trips number, the dispatcher's screen needs to look like Baltimore Trips. When the next call lands on Philly Charters, the same dispatcher's screen needs to switch identity instantly. No off-the-shelf product does this. So we built the CRM's brand-switching flow ourselves.
5. The freight vertical
Then we added StretchXL Freight. Not passenger transportation — commercial freight, DOT-authorized, ~9,300 lanes, a completely different compliance surface. There is no reservation-software vendor in the world that ships passenger + freight in the same product. That was the moment I realized we weren't building a slightly-different limo product — we were building a general-purpose transportation operations stack. Different category entirely.
What I got wrong
Plenty. Being honest:
- Underestimated how long it would take. The first version of the custom CRM took nine months to reach useful. I thought it would take three.
- Kept SuiteCRM too long. By year two of extending it, we were fighting the framework more than benefiting from it. I should have replatformed a year sooner.
- Late to real dispatch tooling. For way too long, dispatch was "look at the CRM's list view, make a decision." Real dispatch software with vehicle assignment, driver run sheets, live trip status — that came in year six or seven. Should have been year three.
- Underinvested in monitoring. When you build your own stack, you also own the paging. It took a few production incidents before I properly invested in the "wake Ken up if X" plumbing.
- Waited too long to productize. By year eight I had operators asking to license my stack. I didn't take it seriously. That was leaving money on the table.
What I got right
- Built the vendor portal early. Every ceiling we've hit has been solved partly by more vendors, and the portal is the reason vendor onboarding is a day and not a month.
- Owned the payment processor integration. When Fortis changed their API, we changed our code. Anyone locked to a SaaS was waiting on their vendor.
- Kept the customer-facing sites separate and lightweight. Each brand site is static HTML (Hugo). Sub-second page loads. Google loves it. The CRM only touches the sites via a REST API for lead capture — the sites themselves have no DB, no PHP, no plugins to compromise.
- Kept a real 24/7 human dispatch desk. Software helps. But nothing has driven our review scores (4.7 stars across 1,200+ reviews) more than the fact that someone answers the phone. Every time. Instantly.
- Wrote everything down. Every incident, every gotcha, every "we already fixed this once" — captured in a memory system. When the same problem tries to come back, we know within seconds.
Why we're selling it now
Same reason Moses is selling BookItRides. Same reason WooCommerce started as a plugin for one store. Same reason Shopify started as one snowboard shop.
Once you've built the thing, running it costs almost nothing extra to run it for someone else too. And most operators don't want to spend ten years and seven brands worth of scars re-learning the same lessons. They want the finished product.
So we packaged it. Four tiers, from DIY software-only ($99/month) to full white-label ops with our 24/7 human desk answering your phone as your brand ($10K+/month). The exact stack we run on seven of our own brands, licensed for other operators.
What I'd tell my 2016 self
- Build the vendor portal first. Not the CRM. Not the dispatch. The vendor portal. Everything else scales off it.
- Static brand sites, not WordPress. WordPress at scale is a security tax you don't need. Every one of our modern brand sites is Hugo-generated static HTML.
- Human dispatch is a moat. Software gets copied in 14 months. A 24/7 human desk that has been trained on your specific vehicles for years does not.
- Write down every incident. The compound interest on institutional memory is enormous.
- Productize sooner. Your stack is more valuable to other operators than you think.
The stack you should have paid for is almost always the stack that doesn't exist yet. If yours is the first business trying to do what you're doing, you're going to have to build a lot of it. Budget for that up front.
Should you build or buy?
The honest answer is buy, unless:
- You already have three or more brands, or a clear plan to get there in 24 months.
- You need a vertical that no vendor serves (freight, DOT, government, specialized events).
- You are already carrying the operational overhead of running a bespoke tool because nothing off-the-shelf fits.
- You have engineering talent on staff or the budget to hire it.
If none of those apply — buy. Life is short. Pick BookItRides or Limo Anywhere or one of the other alternatives, wire up your Stripe, and go do the actual driving.
If some of those apply — you don't have to build. You can rent our stack. That's the whole reason we exist as a product now. Someone else already paid for the ten years of lessons.