Shipping Software Developer

About GoodGoods

GoodGoods is a Rotterdam-based B2B logistics intermediary. We pool shipping volume from multiple webshops to negotiate better rates with carriers including PostNL, DHL, DPD, bpost, CIRRO/GOFO, and Dragonfly. We manage purchase rates, sales rates, and surcharges across carriers and countries, acting as a broker between our merchants and the underlying carrier network.

The project

We are building our own shipping orchestration platform: a system that sits between external partners (Sendcloud, Deliverymatch, Zineps, WMS platforms such as Picqer and LyraWMS) and the carriers/brokers we work with. Partners call our platform with shipment details (destination country, weight, dimensions, cutoff time); our platform d ---------- , based on our own contracts and rate tables, which carrier and service level offers the best price/quality match, and returns the final shipping label. End customers only ever see GoodGoods — the underlying carrier or broker is never exposed.

This is a from-scratch build. The end-state architecture is mapped out (see the attached plan), but the first deliverable is a tightly scoped MVP: one carrier, one partner integration, and a rule-based rate engine, running fully end to end. The full data model is designed up front so later phases (multiple carriers, brokers, an admin UI, self-service partner onboarding, automated invoice reconciliation) can be added without a rebuild.

What you'll build (MVP scope)

In scope

Full Supabase (Postgres) schema for the end-state platform (partners, merchants, carriers, brokers, carrier methods, purchase/sales rates, contracts, shipment requests, rate decisions, shipments, tracking events, carrier invoices, audit log), even though only part of it will be populated at MVP stage.
One carrier adapter built to a uniform interface: createLabel, cancelLabel, getTracking, getServiceCapabilities.
A rule-based rate engine (v1): filters on country/weight/dimensions and picks the lowest allowed sales price within the active contract, built as an isolated, testable module.
A partner-facing REST API (POST /v1/rates/quote, POST /v1/shipments, GET /v1/shipments/{id}, cancel, tracking) with API-key authentication scoped per merchant.
Label generation/normalisation (PDF/ZPL) returned under GoodGoods' own reference and tracking number.
Basic tracking ingestion from the carrier (webhook or polling), normalised into a shared status set.
Append-only audit logging and idempotency keys from day one; all monetary values stored as integer cents.

Explicitly out of scope for the MVP

Broker sub-routing layer (the adapter contract is designed to support it later).
Internal admin UI for contracts/rates — managed via Supabase Studio / seed scripts for now.
Automated invoice reconciliation — existing spreadsheet-based workflows continue in parallel.
Self-service partner onboarding — new API keys are issued manually.
Integration with the existing customer portal (separate Next.js/Supabase app, currently in beta).
Responsibilities
Design and implement the Postgres schema in Supabase, including Row Level Security for partner/merchant isolation.
Build the first carrier adapter end to end against a real (sandbox) carrier API.
Build the rule-based rate engine as a separately testable module, with unit tests.
Build and document the partner-facing API (Next.js on Vercel) with authentication and per-merchant scoping.
Set up tracking ingestion and status normalisation.
Set up audit logging and idempotency handling from the first commit.
Work with the GoodGoods team to validate rate logic against real contract data (rate cards, surcharges, minimum volumes).
Use Claude Code as day-to-day build support, and keep the codebase in a state where it can be picked up by future developers.
What we're looking for

Must-have

Strong experience with TypeScript/Next.js in production, ideally on Vercel.
Solid Postgres experience, comfortable designing a normalised schema from a written spec.
Experience with Supabase (or willingness to ramp up quickly — Postgres + Edge Functions + RLS).
Experience building and securing external-facing REST APIs (auth, scoping, idempotency).
Comfortable integrating with third-party/carrier APIs (labels, tracking, webhooks).
Able to work independently from a written architecture document and ask sharp clarifying questions.

Nice-to-have

Prior experience in logistics, e-commerce, or shipping/carrier integrations (PostNL, DHL, DPD, bpost, or similar).
Experience with rule engines or pricing/rating logic.
Experience with Claude Code or similar AI-assisted development workflows.
Dutch language skills (useful for reading existing carrier contracts, not required for the codebase).
How we'll work together
Start from the attached architecture plan and MVP scope; first milestone is a working end-to-end flow (request ? decision ? label) for one carrier and one partner.
Short async check-ins on progress; ad hoc calls with the GoodGoods pricing/operations team (Rowan, Azhar) to validate rate logic.
Codebase and schema decisions documented as we go, so the platform can grow into later phases (more carriers, brokers, admin UI, invoice reconciliation, customer portal integration) without rework.