A merged pull request shouldn't be newsworthy. But when the author is a qualified customs broker, not a software engineer, it tells us something important about how collaboration is evolving.

Last week, Gondola's co-founder Adam Botica - a qualified customs broker with no formal development background - had a pull request merged into our codebase. It contained improvements to our consolidation form: removing AU customs sections, updating MAWB placeholders, enforcing uppercase flight numbers, and refining button styling.

But that's just one example of something broader that's happening at Gondola. The keyword here isn't "AI" or "disruption." It's collaboration. We've always needed close collaboration between domain experts and engineers. What's changing is how we do that collaboration and how we communicate the desired output.

‍

Four Ways Collaboration Is Changing

1. The Lovable Prototypes

Adam has been building prototypes using Lovable - working implementations that aren't production-ready, but are good enough to be usable and to communicate intent.

For our engineering team, these prototypes were key to understanding problems in the freight forwarding domain. Instead of spending weeks learning the intricacies of customs regulations, international shipping requirements, and consolidation workflows, they could see working examples.

The prototypes reduced friction. They let the engineer get into a completely unknown domain much faster because the domain expert could speak the same language.

This is collaboration through working software rather than through documentation.

2. The Direct Implementation

Adam's consolidation form PR was straightforward: he understood exactly what needed to change - wrong placeholders, unnecessary fields, formatting issues - and used AI to implement those changes directly.

The engineering team reviewed it, tidied it up, and merged it. Not because it was perfect production code, but because it was a solid first draft from someone who knew the domain intimately.

This is the most visible change: domain experts can now draft working implementations rather than writing specification documents.

3. The Discovery Framework

The team generated code that allowed Adam to explore and validate assumptions about the customs integration himself.

This meant Adam could experiment with edge cases, try different approaches, fail quickly, and validate workflows - all without waiting for engineering time. It wasn't testing in the traditional sense of verifying implementation; it was discovery, planning, and rapid iteration to understand what would actually work.

Meanwhile, José - our lead engineer - and the engineering team could focus on delivering what they already knew how to build well.

This is about parallelising work that used to be sequential. The domain expert can explore the problem space whilst the engineers focus on solid implementation of known requirements.

4. The Intercom Integration

Adam coded an integration connecting Gondola to Intercom (a customer platform) using AI, then handed it to our engineering team to review and implement properly.

This changed the nature of the collaboration. Instead of the team trying to interpret written requirements about how Gondola should interact with Intercom, they could see a working implementation. He could ask specific questions about specific code. The conversation became more precise, more efficient.

The domain expert and the engineer were speaking the same language - code.

‍

Collaboration Has Always Been the Challenge

As Adam notes: "It has always needed that and will continue to, but we are changing how we do that and communicate the desired output."

The challenge in building software has never been purely technical. It's been about collaboration between people who understand the problem (domain experts, product owners, customers) and people who understand implementation (engineers).

Traditional collaboration looked like this:

1. Domain expert explains the problem
2. Product person writes requirements
3. Engineer interprets requirements and asks clarifying questions
4. Engineer builds something
5. Domain expert reviews and requests changes
6. Repeat steps 3-5 several times

Each handoff is an opportunity for misunderstanding. Each translation from domain language to technical language loses fidelity.

What's changing at Gondola is that domain experts can now participate directly in steps they couldn't before. They can prototype. They can implement straightforward changes. They can build tests for their own assumptions.

This doesn't eliminate the collaboration - it makes it more direct.

‍

How This Changes Team Dynamics

We're not radically reorganising at Gondola. We're adjusting how we work together.

Domain experts can prototype their ideas. When Adam understands how a customs workflow should work, he can build a working example. This makes collaboration more effective.

Engineers focus on review, refinement, and architecture. Rather than starting from scratch, engineers ensure code is robust, scalable, and maintainable.

Collaboration happens through code. The conversation between our engineering team and Adam didn't happen primarily in Jira tickets. It happened through prototypes, working code, and collaborative refinement.

Work can be parallelised differently. Adam can test customs integration assumptions whilst the engineering team focuses on implementation. The domain expert explores the problem space; the engineers build robust solutions.

‍

What This Means for Hiring and Team Building

This shift has implications for how we think about building teams.

Domain expertise with basic coding ability is valuable. Someone who deeply understands freight forwarding and can prototype working solutions is powerful for collaboration.

Engineering candidates need strong collaboration skills. The ability to work with non-traditional contributors, review code constructively, and mentor people learning to code becomes more important.

Code review becomes a core skill. When more people contribute code at varying skill levels, engineers who excel at review and maintaining standards become more valuable.

Engineer ramp time should significantly reduce. This might be the most tangible benefit. When José originally needed to understand customs workflows, he had Adam's lovable prototypes to learn from. New engineers won't spend months in meetings trying to understand freight forwarding concepts - they'll have working code examples that demonstrate how the domain actually works. The domain knowledge barrier, traditionally one of the biggest bottlenecks in onboarding engineers to complex industries like logistics, becomes much lower when domain experts can express their knowledge in code.

‍

A Customs Broker's Code

When Adam merged his PR, the team's reaction wasn't about AI capability. It was about a new way of working together.

He didn't become a software engineer. He became a domain expert who can contribute to the codebase in ways that make collaboration more effective - through prototypes, through working code, through implementations that engineers can refine.

The engineering team didn't become redundant. They became engineers who can build on solid starting points from someone who knows the domain deeply, focusing their expertise where it matters most.

That's valuable collaboration. It has limitations. And it's changing how we work.

We don't have all the answers yet. But we're learning, collaborating, and building together in new ways.

And that collaboration - that's the keyword here.

‍