Building Maxmove: A Look Inside Our Engineering Stack

Why We're Writing This

Maxmove is building a next-generation logistics operating system — AI-powered, multi-modal, and built for both on-demand delivery and enterprise transport management. That ambition demands serious engineering choices. This post shares what we build with, and more importantly, why.

Architecture

Our codebase follows domain-driven design principles inside a single monorepo. We chose this structure because logistics is a deeply interconnected domain — orders, dispatch, payments, vehicles, and communication all depend on each other. A monorepo lets us evolve these boundaries together rather than fighting coordination overhead across scattered repositories.

The monorepo is managed with Bun workspaces and Turborepo, giving us atomic commits across the full stack and a single CI pipeline that catches breakage before it ships.

Languages

• TypeScript — powers our API, web frontends, mobile apps, and shared packages. We get end-to-end type safety from the database layer to the UI, which drastically reduces the class of bugs that make it to production.
• Go — runs our backend microservices. TypeScript alone couldn't give us the concurrency model we needed for real-time dispatch and high-throughput event processing, so we chose Go where raw performance matters most.
• Protocol Buffers — the contract language between services. Code generation keeps our TypeScript and Go clients in sync automatically, so API drift simply doesn't happen.

Frontend

For web we use Next.js with React. For mobile we build with React Native and Expo, leveraging the new architecture with bridgeless mode and Turbo Modules — the same technical direction Tesla chose for its robotaxi app. This matters because it lets us write native code where performance is critical (maps, animations, location tracking) while sharing the vast majority of business logic across iOS and Android.

Backend

Our API runs on Bun — chosen for its fast startup, low memory footprint, and native TypeScript execution. It handles authentication and routes requests to our Go microservices, which own the core business domains. We chose Go here because dispatch and order matching are concurrency-heavy problems where goroutines and channels outperform anything in the Node.js ecosystem.

PostgreSQL is our primary database — battle-tested, extensible, and more than capable of handling the geospatial queries that logistics demands. For spatial indexing we use Uber's H3 hexagonal grid system, which lets us efficiently match drivers to orders, define service areas, and compute proximity at scale.

Logistics is inherently real-time — customers expect live tracking, drivers need instant job notifications, and dispatchers want to see everything as it happens. We use WebSockets extensively to push updates to every client the moment something changes. Under the hood, an event-driven architecture powered by NATS and JetStream ties it all together. When an order is created, a payment succeeds, or a driver accepts a job, events propagate through the system instantly — with durable storage and delivery guarantees so nothing gets lost.

What's Ahead

We're looking ahead to solving the biggest technical challenges in moving goods — and putting the logistics world on its head.

• AI-agentic dispatch — We're building intelligent dispatch that goes beyond static rule engines. Using machine learning and LLMs, we're working toward end-to-end matchmaking that understands context, predicts demand, and optimizes across the entire network — laying the digital infrastructure for a future where autonomous vehicles deliver without human coordination.
• Blockchain-verified proof of delivery — For high-value and cross-border shipments, "delivered" isn't enough. We're building tamper-proof evidence chains that give every party in the logistics chain cryptographic certainty about what happened, when, and where.
• Multi-modal transport — Today we orchestrate road deliveries. Tomorrow we're adding air freight — and preparing for the transport methods that follow: autonomous robots and drones that will reshape how goods move through cities.

How We Work

We're a small team based at the Cologne Innodom — or remote. We work in tight, autonomous groups, heavily leveraging agentic AI tooling to move fast with fewer people. One mandatory meeting per week, and only when there's something worth discussing. The rest of the time: deep work, minimal distractions, maximum output.

If that sounds like the kind of environment where you do your best work, check out our careers page or reach out directly at max@maxmove.com.