We built trade software for 25 years.
Then we started over.

I have worked in international trade for more than 25 years. For most of that time, the software has not kept up with the job.

The problem started after September 11, when the border got stricter and every new requirement came with new data. It has not let up since. ISF. Prior Notice. Partner government agencies with hundreds of new reporting elements. ACE modernization. The end of de minimis. Now tariff changes that stack five headings deep and move by proclamation. Each one tests brokers and importers a little harder, and each one adds cost to the carriers sitting in line at the port.

We tried the usual answer. We put customs analysts and software engineers on it, and we made real progress. But every change meant undoing and redoing something, and the system grew into something it was never meant to be. The bloat became the bottleneck. Our own software was the thing slowing us down.

So we started over.

Security first, then AI, then screens

This is not a matter of handing the problem to a chatbot. We built a new system from the ground up in a fixed order. Data security first. Then AI where it does real work. Then the software people use every day. That order matters. It is why a rule change no longer waits for a release.

Take tariff stacking. When CBP publishes a notice, TradeManager reads it and drafts the rule, the configuration, and the test cases. Someone with trade knowledge reviews it. A second person publishes it. Nothing gets deployed, and every earlier calculation is flagged for another look.

The same approach runs customer data intake. The wizard reads a customer's file, proposes the mapping, and lets the person who knows the data correct it. No developer in the room, no waiting for the next release.

What we set out to fix

• Get a regulatory change into production in days instead of months.
• Take a customer's data in over minutes instead of days.
• Cut what it costs to keep trade software running.
• Give larger customers full control of their data, in their own environment, instead of a shared service.
• Raise a brokerage's entry throughput without hiring or changing its filing system.
• Cut carrier delays at the border by getting the data right before the truck arrives.
• Keep products current at scale as the rules change.
• Get bug fixes out fast, and catch them before a user has to report them.
• Train people with real documentation and worked examples.

What we have not done yet

Carrier integration, a public API, and reading scanned documents are on the roadmap and not in the product. We would rather tell you that here than have you find out at the border.

Ron Barone
Founder, RBD Studios Inc.