Trade-In Warehouse Management System

Summary

• Scope: Designed and built an end-to-end warehouse management system for trade-in operations, used by third-party logistics partners and our client's head office.
• Constraint: No dedicated engineering resource. Initial proposal was to run operations on a spreadsheet.
• My role: Reframed the problem, designed the system, and built it end-to-end using no-code tools (Airtable plus Budibase), without writing application code.
• Outcome: Processed tens of thousands of products for our biggest client and remained in production for years after launch.

Context

We were onboarding our biggest client to date: a sustainability-focused children's clothing brand whose entire proposition rested on garments being worn by multiple children. Trade-in wasn't a feature for them; it was an evolutionary step in their business model.

Their warehouse, picking, packing, and returns were all run by third-party logistics partners. To enable trade-in, those partners needed a way to receive items, log condition and status, and trigger credit issuance back to the customer. None of which their existing systems supported.

The first proposal in the room was a shared spreadsheet. It would have worked for a week. It would have collapsed under volume, lost data, broken audit trails, and pushed manual reconciliation work onto our client's head office every single day.

I pushed back.

Approach

1. Reframed the problem from "shared file" to "system"

A spreadsheet treats each line as an event. The reality was multi-entity: a single trade-in order could contain multiple items, each with its own condition, status, and shipping lifecycle, and each tied back to a customer credit. That needed proper data modelling: primary keys, one-to-many relationships, and state transitions, not a flat list.

I scoped what a real system needed to do, then looked for the cheapest viable way to build it.

2. Chose the build path: no-code, but engineered

We had no dev capacity to spare. Rather than wait, I designed and built the system using:

• Airtable as the relational database, modelling items, orders, customers, and shipments with proper relationships and state logic.
• Budibase (open-source low-code) as the frontend, giving warehouse staff search, lookup, status updates, and tracking visibility.
• Webhooks from shipping providers, wiring live inbound and outbound shipping statuses directly into the data layer rather than relying on manual updates.

The result was a robust web app with real database integrity behind it. I didn't write application code, but I did the system design, the data architecture, and the build.

3. Designed the operational handoff, not just the tool

The system generated a daily export to the client's head office, giving them everything they needed to issue trade-in credit to customers without having to ask us. That output also fed downstream into their photography, cleaning, and relisting workflows, meaning the WMS sat upstream of their entire resale operation.

4. Built with the warehouse teams, not just for them

The portal's primary users were warehouse staff. Early on I set up a feedback loop with them, working through the client's ops team, so what we shipped was shaped by what receiving stations actually needed rather than what looked sensible from a Notion doc. That meant continuously iterating after launch: adding fields when new edge cases surfaced, simplifying screens when usage patterns showed a feature wasn't earning its place, and cutting things that looked useful in design but added friction in practice.

Outcome

• Launched on time for client onboarding.
• Processed tens of thousands of products through the trade-in flow.
• Unblocked the client's full resale operation, not just the trade-in step.

What I took from it

A reminder that PM impact isn't gated by engineering availability. When the team is small and the constraint is real, the answer is sometimes to get your hands dirty, using whatever tools the problem actually warrants to deliver a product that actually brings value.