Why Forwarding Pro exists because of Elematec — our first client, and co-author

Every platform that ends up serving many customers was, at some point, a single system built for exactly one. The interesting question is what happened in between — because the gap between “a tool we built for one client” and “a product anyone can adopt” is where most software quietly dies.

Forwarding Pro didn’t die in that gap. It was built across it, with one company on the other side: Elematec.

Who Elematec is, and why it matters that they were first

Elematec Corporation is an electronics-materials trading house with roughly 75 years of history, around 70 bases in Japan and overseas, and over a billion dollars in revenue. It moves electronic components, materials, and finished assemblies — the unglamorous, high-precision parts inside smartphones, cars, appliances, and medical equipment — across a genuinely global network, including significant operations in China.

That profile matters, because it means Elematec is not a forgiving first user. A trading company operating at that scale has real forwarding complexity: multi-leg international shipments, layered cost structures, customs and HS-code classification, insurance, and the constant reconciliation of quotes against what actually got billed. If a forwarding system can hold up under Elematec’s operations, the requirements it surfaces are the real ones — not a simplified demo’s idea of them.

So when we signed a co-development agreement with Elematec in February 2024, we weren’t just acquiring a customer. We were acquiring a teacher with a hard curriculum.

What “co-developed” actually means here

It’s an overused word, so it’s worth being concrete. The foundation of what is now Forwarding Pro — the working modules, not a wishlist — came directly out of Elematec’s real operational requirements:

• Quote comparison. Putting forwarder quotes side by side in a structured way, so the cheapest-looking line isn’t quietly the most expensive once everything is loaded in.
• Booking management. Turning an accepted quote into a tracked booking without re-keying it into three systems.
• Expense aggregation and analysis. Rolling shipment costs up so a trading company can actually see where its freight spend goes — by lane, by period, by counterparty.
• Insurance handling. Making cargo insurance part of the workflow rather than a separate, forgotten step.
• HS-code classification. Identifying and managing the tariff codes that decide what a shipment costs to clear — a function that has to keep pace with international tariff revisions, which means it can never be “finished.”

None of these were invented in a vacuum and then sold to Elematec. They were built because Elematec needed them to work, tested against shipments that actually had to clear customs and arrive. That is the difference between a feature and a requirement: a requirement has consequences if you get it wrong.

The harder, more interesting decision: from bespoke to shared

Here’s where the story gets genuinely instructive, and where most client-success blogs would stop being honest.

The system we first built for Elematec was a dedicated environment — a single-tenant build, theirs alone. That is the natural shape of a co-development: you build the thing the one client in front of you needs. But a single-tenant system has a ceiling. Every other forwarder who could benefit would need their own build from scratch, and Elematec’s own system would slowly drift away from the improvements everyone else’s needs would generate.

So we made a deliberate architectural decision: migrate that dedicated environment onto Forwarding Pro — a multi-tenant SaaS platform where many customers share a common, continuously improving codebase, while still allowing each one’s specific customisations to live on top of it.

For the pioneer client, that is a subtle and slightly counterintuitive trade. Elematec gives up the exclusivity of a system built only for them. In exchange, they get something more valuable over time: a platform that keeps getting better because other companies’ requirements now flow into it too — with continuous security hardening and new standard features they receive without a fresh development project each time. The HS-code function, for instance, becomes a standard module that we maintain against changing tariff schedules on everyone’s behalf, rather than a custom feature Elematec has to commission updates for.

The genuinely respectable thing about Elematec here is that they understood this. Moving from “the system we co-built is ours” to “the foundation we co-built becomes the thing everyone stands on” requires a certain confidence. It is the difference between owning a custom tool and authoring an industry standard.

Why this is the right way to build infrastructure

There’s a broader point about how forwarding software — and arguably most B2B infrastructure — should come into existence.

You can build it speculatively: imagine the generic customer, design for the average, and hope real operations resemble your assumptions. Most enterprise software is built this way, and most of it is quietly disappointing for exactly that reason — it solves the problems its designers imagined rather than the ones operators actually have.

Or you can do what we did: build the real thing for one demanding, real operator first, let their operations stress-test every assumption, and only then generalise the parts that proved load-bearing into a shared platform. The first approach gives you a product that demos well. The second gives you a product that survives contact with how trade actually works. Forwarding Pro exists because of the second path, and Elematec is the reason it does.

That is also why we are comfortable putting Elematec’s name on this. This isn’t a logo on a customer wall. It’s an acknowledgement that the foundation of a product now offered to the wider market was co-authored by a client willing to do the hard, specific work of getting it right — and then generous enough to let it become shared infrastructure.

If you run forwarding operations and you’ve been quietly tolerating spreadsheets, re-keying, and freight spend you can’t fully see, Forwarding Pro was built — literally — for operations like yours. Let’s show you the foundation.

Related reading

• Digitrad Forwarding / Forwarding Pro — the platform overview and module set.
• The eBL ↔ stablecoin atomic swap — how the forwarding and settlement layers connect.
• Why Standage acts as your importer of record — the operational philosophy behind the platform.

最初の顧客が教えてくれたこと ― エレマテックと共に作った Forwarding Pro

多くの顧客に使われるようになったプラットフォームは、どれもある時点では「たった一社のために作られた単一のシステム」でした。面白い問いは、その「間」に何が起きたか、です ― 「一社のために作ったツール」と「誰もが採用できるプロダクト」の間の隔たりこそ、たいていのソフトウェアが静かに死んでいく場所だからです。

Forwarding Pro は、その隔たりで死にませんでした。隔たりをまたいで作られたのです ― 対岸に一社を置いて。その一社が エレマテック です。

エレマテックとは何者か、そして「最初だった」ことがなぜ重要か

エレマテック株式会社は、約75年の歴史、国内外に約70拠点、売上10億ドル超を持つエレクトロニクス商社です。電子部品・材料・完成アセンブリ ― スマートフォン、自動車、家電、医療機器の内部にある、地味で高精度な部品たち ― を、中国での大規模なオペレーションを含む真にグローバルなネットワークで動かしています。

このプロフィールが重要なのは、エレマテックが「甘い最初のユーザー」ではないことを意味するからです。その規模で動く商社には、現実のフォワーディング複雑性があります ― 複数レッグの国際輸送、積み重なるコスト構造、通関とHSコード分類、保険、そして見積と実際の請求の絶え間ない突合。フォワーディング・システムがエレマテックのオペレーションに耐えられるなら、そこで浮かび上がる要件は「本物」です ― 簡略化されたデモが想像する要件ではなく。

ですから、2024年2月にエレマテックと共同開発契約を締結したとき、私たちは単に顧客を得たのではありません。難しいカリキュラムを持つ「教師」を得たのです。

ここでの「共同開発」が実際に意味すること

使い古された言葉なので、具体的に語る価値があります。いま Forwarding Pro となっているものの基盤 ― 願望リストではなく、動くモジュール群 ― は、エレマテックの現実の業務要件から直接生まれました：

• 見積比較。フォワーダー各社の見積を構造的に横並びにする ― 一番安く見える行が、すべて積み上げると実は一番高い、という事態を防ぐために。
• ブッキング管理。承認した見積を、3つのシステムに打ち直すことなく、追跡可能なブッキングへ変換する。
• 経費集計・分析。輸送コストを積み上げ、商社が自社の運賃支出の行き先を実際に見られるようにする ― 航路別、期間別、取引先別に。
• 保険処理。貨物保険を、別個の忘れられがちな工程ではなく、ワークフローの一部にする。
• HSコード分類。輸送物の通関コストを決める関税コードを特定・管理する ― 国際的な関税分類の改定に追随し続ける必要があり、ゆえに「完成」することが決してない機能。

これらは真空の中で発明されてからエレマテックに売られたのではありません。エレマテックがそれを機能させる必要があったから作られ、実際に通関し到着しなければならない輸送に対してテストされました。それが「機能（フィーチャー）」と「要件（リクワイアメント）」の違いです ― 要件は、間違えれば帰結が生じます。

より難しく、より面白い決断 ― 専用から共有へ

ここからが本当に示唆に富む部分であり、たいていの「顧客成功事例」ブログが正直であることをやめる地点です。

私たちが最初にエレマテックのために作ったシステムは、専用環境でした ― 彼らだけのシングルテナント構築です。それは共同開発の自然な形です ― 目の前の一社が必要とするものを作る。しかしシングルテナントのシステムには天井があります。恩恵を受けられる他のフォワーダーは皆それぞれゼロから構築が必要になり、エレマテック自身のシステムも、他社の要件が生むはずの改善から少しずつ取り残されていきます。

そこで私たちは、意図的なアーキテクチャ上の決断をしました ― その専用環境を Forwarding Pro へ移行する。多くの顧客が共通の、継続的に改善されるコードベースを共有しつつ、各社固有のカスタマイズはその上に載せられる、マルチテナント型 SaaS プラットフォームへ。

パイオニア顧客にとって、これは微妙で、少し直感に反するトレードです。エレマテックは「自分たちだけのために作られたシステム」という排他性を手放します。その代わりに、時間とともにより価値あるものを得ます ― 他社の要件もそこへ流れ込むからこそ良くなり続けるプラットフォーム。継続的なセキュリティ強化と、その都度新たな開発プロジェクトを起こさずに受け取れる新しい標準機能。たとえばHSコード機能は、エレマテックが更新を都度発注しなければならないカスタム機能ではなく、変わりゆく関税表に対して私たちが全員のために保守する標準モジュールになります。

ここでエレマテックの本当に立派なところは、彼らがこれを理解していたことです。「共に作ったシステムは我々のもの」から「共に作った基盤が、皆が立つ土台になる」へ移ることには、ある種の自信が要ります。それは、カスタムツールを所有することと、業界標準を著すことの違いです。

なぜこれが、インフラの正しい作り方なのか

フォワーディング・ソフトウェア ― そして、おそらくほとんどのB2Bインフラ ― がどう生まれるべきか、についてのより広い論点があります。

投機的に作ることもできます ― 一般的な顧客を想像し、平均値に向けて設計し、現実のオペレーションが自分の仮定に似ていることを祈る。多くのエンタープライズソフトはこの作り方で、その多くがまさにその理由で静かに期待外れに終わります ― 設計者が想像した問題を解き、オペレーターが実際に抱える問題を解かないからです。

あるいは、私たちがやったようにすることもできます ― まず一社の、要求の厳しい現実のオペレーターのために本物を作り、彼らの業務にあらゆる仮定をストレステストさせ、そのうえで「荷重を支えた」と証明された部分だけを共有プラットフォームへ一般化する。前者はデモ映えするプロダクトを生みます。後者は、貿易が実際にどう動くかとの接触に耐えるプロダクトを生みます。Forwarding Pro が存在するのは後者の道のおかげであり、その理由がエレマテックです。

だからこそ私たちは、エレマテックの名をここに出すことに躊躇がありません。これは顧客ロゴの壁に貼る一枚ではありません。より広い市場に提供されるプロダクトの基盤が、それを正しく仕上げるという難しく具体的な仕事をいとわなかった一社の顧客によって共に著され ― そしてそれが共有インフラになることを許す度量があった、という事実への謝意です。

フォワーディング業務を回していて、スプレッドシート、打ち直し、そして完全には見えない運賃支出を黙って我慢してきた方へ。Forwarding Pro は ― 文字どおり ― あなたのようなオペレーションのために作られました。その基盤をお見せします。

関連記事

• Digitrad Forwarding / Forwarding Pro ― プラットフォーム概要とモジュール群。
• eBL ⇄ ステーブルコイン アトミック・スワップ ― フォワーディング層と決済層がどうつながるか。
• なぜSTANDAGEが輸入者（Importer of Record）になるのか ― プラットフォームの背後にある運用哲学。