Lune x Gryn: Product Consolidation

Background

Lune built tools for logistics service providers (LSPs), freight forwarders and carriers who needed to calculate and report emissions across their operations. Gryn built tools for shippers, the companies whose goods were actually being moved. In 2026, the two companies merged to create an end-to-end supply chain emissions platform.

On the surface, the products did similar things. Underneath, they disagreed about something fundamental.

The real problem

Lune's product treated the calculation as the atomic unit. Every action in the product was anchored to a calculation: you ran one, you reported on it, you managed it.

Gryn's product treated the shipment as the atomic unit. A shipment might have a calculation attached or it might not, but it existed regardless. The shipment was the thing.

Neither model was wrong. They reflected the different realities of their respective user types. But they couldn't coexist in the same interface without a decision being made about which was most useful in the new context, or whether a third model could serve both.

There was also a third wrinkle: Lune supported hypothetical calculations, projections used during tender creation and simulations to estimate future emissions before a contract was signed. Gryn had nothing equivalent. Any unified model had to account for this without surfacing it to users for whom it was irrelevant.

Research

Before any design work, I focused on getting the domain model right. That meant interviews with customer success teams from both sides, documentation of user types and their core workflows, and a detailed feature-by-feature analysis of what each product did and for whom.

The CS interviews were particularly useful. They surfaced the real-world edge cases that the product documentation didn't capture. Where did the two products talk to each other in practice? Where were customers already doing workarounds?

Finding a shared model

The resolution came from stepping back from both products' existing models and asking what was actually true at the domain level. A shipment could exist without a calculation. A calculation always belonged to a shipment. Hypothetical calculations were a special case of the calculation concept, scoped to a context (tendering) rather than a user type.

This gave us a model that was genuinely neutral: shipment-first, with calculations as an associated object, and hypothetical calculations surfaced only in the tendering context. The model served both without compromise. LSP workflows still centred on calculations where that was appropriate, and shippers saw shipments with calculations attached where they needed them.

Design

With the domain model agreed, the design work followed. The unified interface surfaced shipments as the primary object, with calculations accessible contextually. LSP-specific views (tendering, batch imports, operational reporting) were scoped so that shipper users never encountered concepts that weren't relevant to them, and vice versa.

Key surfaces: import batch management, the unified shipment table, and the analytics dashboard, each designed to serve both user types from the same underlying data without either experience feeling compromised.