.png)
Introduction
Modern software often promises speed, scale, and automation, but in inland maritime operations, the real challenge is building technology that works in high-stakes, real-world conditions.
At OpenTug, engineering is about deeply understanding barge operations, respecting the consequences of bad data, and designing systems that help operators make better decisions under pressure. That philosophy is shaped by our engineering leadership.
In this Q&A, we sit down with OpenTug’s Director of Engineering to talk about how the team builds BargeOS, why domain expertise is non-negotiable, and what it really means to deliver “quality” software in maritime operations. From early days riding cranes and embedding with operators, to building invoice and email intelligence that saves customers hours a day, this conversation offers a candid look at how OpenTug engineers for the river, not the whiteboard.
What’s your current role at OpenTug, and what does that mean in practice day-to-day?
Director of Engineering. I co-own technical strategy with our CTO and lead engineering execution—shaping priorities, guiding architecture decisions, and staying hands-on where it matters.
What parts of BargeOS / OpenTug do you directly own or lead?
I structure our engineering team around five core modules, each with its own lead. I keep eyes on all five while staying hands-on with Invoice Intelligence where I still lead backend development. The respective engineering leads own their domains and my role is removing blockers and stepping in where needed.
What’s your path to this seat? What did you do before OpenTug that shaped how you lead engineering today?
I've been in software development for over 20 years. I co-founded a company in the shipping industry focused on terminal operations where I was CTO. That gave me deep industry knowledge and the experience to lead a team of engineers.
OpenTug was a chance to tackle another challenge in the industry from the barge side of things. The terminal experience translates; it's the same industry, different angle. One thing that's stayed consistent: knowing the domain matters. You can't build great software for an industry you don't understand. That's why I spent time in the field early in my career—riding in cranes, embedding with operations teams—and it's why I push for engineers here to really learn barge operations, not just write code.
And leading a team through an acquisition taught me to focus on what actually matters because not everything is urgent, and not every problem is worth solving right now.
What’s a formative experience in your career that still influences how you build products?
I've been building software specifically for the shipping industry for over ten years. Early on, I made it a point to get into the field, embedding myself with operations teams, and watching how people actually work in these environments. You can't build good software from a desk if you don't understand what it's like on the ground.
That experience shaped how I lead today. I push for engineers to understand the domain, not just the code. Code quality matters, but if you don't understand the problem you're solving, you'll build the wrong thing, or the right thing in the wrong way. Domain expertise isn't optional. It's how you build products that actually work for people.
Why OpenTug? What about this mission pulled you in?
The maritime industry moves more than 80% of global trade, but operationally it's still running on phone calls, excel sheets, whiteboards, and gut instinct. That gap between how critical it is and how underserved it is by technology is exactly what pulled me in. OpenTug is building near real-time visibility into barge operations in a way no one else is. The data we're capturing doesn't exist anywhere else, and that's a foundation you can build a lot on.
What did we decide NOT to do that a typical software company might have done? Why?
Two things come to mind. First, we put engineers in customer conversations. A lot of companies shield engineers from customers. They get requirements filtered through product managers or specs. We don't do that. When you hear a customer explain their problem in their own words, you build differently.
Second, there's no 'that's not my job' mentality. At a lot of companies, roles are rigid. Engineers only code, PMs only write specs, and support handles customer issues. Here, if something needs doing, you do it. An engineer might jump on a support call. A lead might write documentation. It's all about getting the right outcome regardless of job descriptions.
Both of these come from being small and scrappy, but we've kept them intentionally. They're part of why we move fast and stay close to the problem.
What’s an example of a “small” customer pain we treated like a big deal and why?
Extracting data from emails. Between statement of fact events, traffic reports, and third-party updates, customers were manually reading emails and typing that information into their system. It sounds small: just data entry. But when you're doing it dozens of times a day, it eats hours. And it's error-prone.
We treated it like a big deal because small pains add up. If something costs a dispatcher time and focus, fifty times a day, that's friction we should remove. That's why we built BargeOS Autopilot—what seemed like a 'small' problem was actually one of the biggest drains on their day. Fixing it gave them hours back.
We try not to dismiss requests just because they seem small. Those are often the things that make customers feel heard, and the things that actually change their daily experience.
Engineering tradeoffs are constant. What tradeoffs do we make differently because we’re building for maritime operations?
A few come to mind. First, data accuracy over real-time. In a lot of software, speed wins. The mindset is, show the user something fast, even if it's not perfect. In maritime, wrong data leads to wrong decisions.
Second, connectivity. Barges operate in areas with limited cell service and internet. You can't assume everyone has perfect connectivity all the time. That affects how we think about syncing data, handling offline scenarios, and making sure critical information gets through.
Third, simplicity. Our users are busy and they're managing a lot at once, often under pressure. We try to keep the interface clean and focused rather than packing in every feature. The goal is a tool that helps them, not one that adds to their cognitive load.
In our world, what does “quality” actually mean beyond just ‘no bugs’?
For us, quality means: did we actually make their operation better? A feature can be bug-free and still be low quality if it doesn't fit how they work. So we ask—does this save them time? Does it reduce errors? Can they use it without us hand-holding them? The real test isn't 'does it work,' it's 'do they use it, and did it help?
How do we test for real operational reality — messy data, pressure, edge cases, changing conditions?
We try to cover as many scenarios as we can. Our test coverage is strong, and we build validation around known edge cases but honestly, barge operations are messy. Every customer has slightly different workflows, different data sources, and different ways things can go sideways. You can't anticipate everything in a test suite.
That's where staying close to customers matters. They see the edge cases we'd never think of like weird email format, the schedule change at 5am, the exception that only happens twice a year. When they flag something, we learn from it and build it into our testing. It's a feedback loop: real operational reality teaches us what to test for.
What does our engineering effort unlock for a customer on an average busy work day?
Two big things. First, time back. We automate the tedious stuff such as parsing emails and filling in voyage data. Work that used to take hours of manual entry just happens, and that's hours back every day.
Second, faster decisions. Barge operations involve a lot of variables: contracts, weather, where vessels are right now, what's coming next. Before, that information lived in different places. Someone had to pull it all together in their head or on a whiteboard. We put it in one place. So when something changes, like a weather delay or scheduling conflict, they're not scrambling to gather information. They can just decide and act.
On a busy day, that's the difference between reacting and actually running your operation.
What’s a feature or workflow you’re proud of because of the outcome it enables, not the tech behind it?
BargeOS Autopilot. I built the first version, then passed it to one of our lead engineers who together with his team has taken it further than I imagined. But what I'm proud of isn't the code—it's what it enables.
Barge operations run on email. Voyage updates, events, schedules, confirmations, and it all comes in as unstructured text. Someone who used to spend two hours a day reading emails and typing data now gets that time back. They can actually manage their operation instead of doing data entry.
That tool was a big reason we landed one of our largest customers, and it's since evolved into invoice data ingestion that prospects are asking for. It started as a scrappy v1 and turned into a core differentiator.
How would you describe OpenTug engineering culture to someone you’re recruiting but using a story, not adjectives?
Here's a typical scene: we're scoping a new feature, and there are three different opinions in the room about how to build it. People speak up. Someone says 'that won't scale,' someone else says 'we're over-engineering it,' someone's worried about the customer workflow. It's not heated, it's a good conversation, but people have strong ideas and they share them.
We usually figure it out by the end of the meeting, sometimes a follow-up. Not because someone pulls rank, but because we talk it through until the best idea wins. And once we decide, everyone commits, even if they initially saw it differently.
The thing I'd tell a recruit is: if you have opinions and want them heard, you'll like it here. But you have to be willing to be wrong, and you have to commit when the team decides. Ego doesn't survive long on this team.
What’s something you’re proud of about how this team works together?
I'm proud of how we respond to feedback. A few months ago we got some tough input from a customer about a feature that needed work. The team didn't get defensive, they dug into the specifics and made real changes. The follow-up showed a huge improvement. That's what I want in a team—the ability to hear hard feedback and act on it without ego.
If you fast-forward 12–24 months, what do you want customers to be able to do that they can’t do today?
I want customers making decisions with the help of AI insights. Right now we give them visibility into contracts, weather, and voyage status, all in one place. The next step is the system actively helping them: flagging problems before they happen, recommending actions, optimizing routes or schedules.
I also want to give customers more time back. We've done it with email ingestion and voyage events. We're doing it now with invoices. I want to keep finding the manual work that eats up their day and just... make it disappear.
The big picture: in two years, a barge operator or charterer of any size should be able to run their entire operation on OpenTug, and it should feel effortless.
What’s the long-term engineering vision you’re steering toward and why does it matter for the industry?
The long-term vision is making OpenTug the platform for inland maritime, serving everyone from major chartered to smaller owner-operators.
A few things make that work. First, we have to deeply understand barge operations. You can't build the right product if you don't understand the real workflows. That's why I push for engineers to be in customer conversations.
Second, we're leaning into AI on both sides: inside the product to help customers make faster, smarter decisions, and in how we build, so a small team can move fast.
This matters because barges are underserved by software. If we get this right, we become the platform that brings modern operations to the whole inland maritime ecosystem.
What do you hope OpenTug is known for five years from now?
I want OpenTug to be the operating system for inland maritime, the default platform that barge operators, shippers, and terminals all run on. Beyond tracking, an intelligence layer with predictive logistics, fleet optimization, the data infrastructure the whole industry relies on. Five years from now, if you're moving cargo on inland waterways in the US, OpenTug should be how you do it. And ideally we're starting to look at what that means globally.
Conclusion
At OpenTug, engineering starts with a simple question: does this actually make someone’s day easier? Every decision from how we handle data to how close engineers stay to customers, flows from that.
The result is software built for real barge operation. Tools that reduce manual work, improve decision-making, and give operators confidence in the data they rely on every day.
If you’re running inland maritime operations and want to see how BargeOS can remove friction from your workflows, or if you’re an engineer who wants to build software that truly matters, we’d love to talk.
Learn more about BargeOS or get in touch with the OpenTug team today.
.png)
