TL;DR: After a decade building systems at Carro across 6 countries, the biggest lessons: get close to operations before you build anything, plan for change management from day one, design for the workflow not the data model, and optimise for iteration speed over initial perfection.
I co-founded Carro in 2015, and over the next decade we grew it into Southeast Asia's largest automotive marketplace - 4,000+ employees, operations across Singapore, Indonesia, Thailand, Malaysia, Japan, and Taiwan, more than 10,000 cars transacted monthly at peak. Along the way, we built over a dozen internal systems: CRM, fleet management, inspection apps, dispatch, inventory, credit management, leasing, auction platforms, workshop management, expense tracking. Some of them were excellent. Some were expensive mistakes. And looking back, I can see the patterns clearly.
The Closer You Are to the Ground, the Better the Software
When we were small, we didn't have the bandwidth to embed engineers with operations. So we built from the office - talking to stakeholders, reading requirements docs, designing what we thought made sense. The result was software that was technically sound but ivory tower. It wasn't grounded in how people actually worked.
Take our CRM. We built proper call routing, conversation logging, the whole thing. But ops kept using their personal phones to call and message customers directly because it was just more convenient. Which meant conversations weren't recorded, we couldn't do quality checks, and when someone was out sick or quit, all that customer context walked out the door with them. A customer would call back and nobody knew what had been discussed or promised. It created huge gaps in service levels.
The tussle was constant. Operations wanted to do things the way they'd always done them. We wanted them to follow the system. And honestly, we were both right and both wrong. We needed ops to use the system so we'd have data flowing through - skip a step and you lose actionable information upstream and downstream. But humans are humans. They want to finish their work with the least effort possible and go home to their lives. They're not going to take extra steps just because an engineer in a different building thinks the data model needs it.
Over time we learned that you can't just embed engineers everywhere - it's not realistic at scale. What worked was getting better at understanding context through other means. Proper interviewing, observation, small talks, building real relationships with the people on the ground. The systems built by teams who were closer to operations were always better. Not because of any magic, but because they understood the shortcuts people would take and designed around them instead of against them.
Building Is 20%, Change Management Is 80%
We built a beautiful workshop management system. The workshop team didn't use it for three months. Not because it was bad - because nobody changed the SOPs. The morning standup still used the whiteboard. The parts ordering still went through the same WhatsApp group. The system existed in parallel to the actual workflow, which meant it didn't really exist at all.
We eventually got adoption, but only after we rewrote the SOPs, retrained the team leads, and physically removed the whiteboard. The software was ready months before the organisation was.
In Southeast Asia, this is even more critical. Labour is relatively affordable, which means automation is always a choice, not an inevitability. If the person on the ground doesn't see how the tool benefits them personally, they'll work around it. Every time. I've learned to think of it this way: if it's not in the SOP, it's not behaviour. You can't deploy new software as a by-the-way.
Start With the Workflow, Not the Data Model
Engineers love designing data models. I know because I used to be one. But some of our worst technical debt came from systems where we designed an elegant data model first and then tried to fit the business process into it. The real world doesn't care about your normalisation. It cares about: what does the user need to do next, and how fast can they do it?
Our best systems started with someone literally drawing the workflow on a whiteboard - every step, every decision point, every exception. Then we built software that matched it exactly. The data model fell out naturally. Design for the workflow first, and the architecture follows.
You Will Rebuild Everything at Least Once
Every system we built at Carro went through at least one major rewrite. Not because the first version was bad, but because the business changed. We expanded to a new country and the tax rules were different. We added a new vehicle category and the inspection flow needed new steps. We hit a scale threshold and the original architecture couldn't handle the throughput.
I used to see this as failure. Now I see it as inevitable. The first version of anything is a prototype - even if you don't call it that. So the real question isn't whether you'll rebuild. It's whether your architecture makes rebuilding cheap.
The Hardest Problems Aren't Technical
The hardest problem at Carro was never the code. It was aligning 4,000 people across six countries around shared processes while allowing for local variation. It was convincing a country GM that the global system was better than their local spreadsheet. It was managing the political dynamics of which team's requirements got priority.
Software is a people problem disguised as a technical one. The engineers who understood this built the systems that lasted. The ones who didn't built impressive prototypes that nobody used.
What I'd Do Differently
If I were starting Carro today with everything I know, I'd start vertical and stay vertical - we wasted years customising generic tools. I'd embed engineers in operations for weeks before they write anything. I'd ship in weeks, not quarters, because our best systems shipped fast and iterated while our worst ones had long planning cycles and launched to crickets. And I'd build for change management from the start - SOPs, training, adoption plans, all part of the engineering spec, not an afterthought.
But the biggest difference would be AI. What took us teams of 15 engineers and 12 months, I now see teams of 4 ship in 6 weeks. The economics of building industry software have fundamentally changed. (I wrote about this here.)
Everything I learned at Carro - the hard way, over a decade - is now the foundation of how we build at First To Fly. We pair that operator experience with AI-native development to build industry software at a fraction of the time and cost. The difference isn't just speed. It's that we've made the mistakes already. We know what to ask before we build, where adoption will break, which shortcuts create technical debt and which ones are smart trade-offs.
That's not something you can hire for. It's something you have to live through.
Lessons learned
- Get close to operations before you build - the best systems came from teams who understood how people actually worked, not how they should work
- Building is 20%, change management is 80% - if it's not in the SOP, it's not behaviour
- Design for the workflow first, not the data model - the architecture follows naturally
- Every system will be rebuilt at least once - optimise for iteration speed, not initial perfection
- The hardest problems are people problems: alignment, adoption, politics - not code
- In Southeast Asia, automation is always a choice - if the user doesn't see personal benefit, they'll work around it
