Why We Co-Build, Not Dev-House

TL;DR: Co-building means sitting alongside a domain expert and shaping the product together in real-time. Not taking briefs, not handing off specs. We share the risk, we share the upside, and we stay in the codebase long after launch.

At Carro, we built everything in-house. Over a dozen systems across a decade. The thing that made it work wasn't just having good engineers - it was that the people building the software were close to the people running the operations. When something didn't work, we knew about it quickly and could fix it the same week.

That experience shaped how I think about building software for any industry. The best products don't come from someone handing you a brief and coming back in three months to check on progress. They come from sitting in the same room, constantly finding the best resolution to problems together.

That's what co-building means to us at First To Fly. And it's fundamentally different from how most software gets made.

What Co-Building Actually Looks Like

We look for partners with very deep industry knowledge. People who've spent years - sometimes decades - in their domain and understand the problems intimately. Then we sit alongside them and build how they imagine the solution should be.

There's no brief. There's no requirements document that gets thrown over a wall. It's a constant conversation. They know the domain. We know systems - how to structure workflows, how to build CRM, scheduling, inventory, fulfilment. We've spent a decade experimenting with all of these at Carro. So the conversation is productive from day one.

When we disagree on how something should work - and we do - we hash it out. Sometimes they want to do things the way they've always done them. Sometimes we see a better approach. We're always happy to experiment. That's the benefit of working together rather than one side handing instructions to the other.

Why Not Just Hire an Agency?

I've written about why agencies fail at building products in more detail, but the short version is this: agencies take a brief, deliver a build, and move on. The incentive is to ship what was specified as efficiently as possible.

Co-building is different in a few specific ways.

We don't just take the brief. When a partner says they need something, we push back, ask why, and explore whether there's a better way. An agency's job is to deliver what you asked for. Our job is to make sure we're building the right thing.

We share the risk. We invest into the build. The structure varies by arrangement, but the principle is the same - if the product doesn't work, we all feel it. That changes behaviour in ways that sound subtle but are actually massive. You stop padding timelines. You stop gold-plating features nobody will use. You focus on what actually matters.

We don't disappear after launch. Shipping code is maybe 20% of the work. The other 80% is getting people to actually use it - change management, SOPs, training, embedding the tool into daily workflows. We learned this the hard way at Carro, where we built a beautiful workshop management system that nobody used for three months because nobody changed the procedures. An agency's scope ends at deployment. For us, that's where the real work starts.

The Systems Knowledge Transfers

Here's what I think makes this model work. Businesses across different industries have more in common than people realise. Sales, CRM, scheduling, inventory, fulfilment, procurement - these are operational patterns that show up everywhere. The specifics vary, but the structural problems are similar.

We spent a decade at Carro building and rebuilding these systems. We know what works and what doesn't. We know where adoption breaks. We know which shortcuts create technical debt and which ones are smart trade-offs. That knowledge transfers across industries.

What we don't have - and what we need the partner for - is the domain nuance. The industry-specific edge cases, the regulations, the unspoken rules, the way customers in that specific market expect things to work. That's why it has to be a partnership. We bring the systems thinking. They bring the domain expertise. Neither side can build a great product alone.

Who This Is For

If you want a fixed-price deliverable with a clean handoff, hire an agency. Seriously. They're fine for that.

But if you're an industry expert sitting on a software idea - someone who's been running operations in your domain for years and knows exactly what needs to exist but hasn't had the tools or the team to build it - that's who we're looking for.

We started First To Fly because we believe the best industry software gets built by people who've lived the problem. Not by people who've read a brief about it. In automotive and dealership-related systems, we're already confident we're the best in Southeast Asia. We want to extend that to other industries where our operational knowledge about systems and workflows can make a real difference.

The co-build model isn't for everyone. It requires a partner who's willing to be deeply involved - not just available for a weekly status call, but actively shaping the product alongside us. If that sounds like you, let's talk.

Let's talk.