A logistics operator needed a warehouse management system that several clients could share, each with their own stock and their own view. I took it from the first discovery meeting to a hosted proof of concept in 10 days, covering about 90% of the specified features.
This post covers what made that pace possible, and what I would still not rush.
Start with the rules, not the screens
Discovery produced written business rules: how receiving works, how putaway is decided, how stock is picked and returned. Once those were agreed, the build was mostly a matter of turning rules into software. Skipping that step is how fast builds turn into rebuilds.
What was built
- Multi-client by design. Each client sees only their own stock, with a portal and an API of their own.
- The warehouse floor. Receiving, putaway rules, FIFO and FEFO stock rotation, pick routing and returns, with barcode scanning on phones.
- Built on Next.js, TypeScript and Prisma, with 67 screens, 92 API routes and a 37-model data schema.
- Tested as it grew: 196 unit tests and 17 end-to-end suites.
Speed came from agreeing the rules early and testing continuously, not from cutting corners.
Where AI fits next
A system like this is a good base for AI that does real work: reading supplier documents automatically, answering client stock questions, or flagging exceptions before they cost money. The structured data underneath is what makes that possible.
What I would tell anyone commissioning a build
- Insist on a working demo early. People react to software far better than to documents.
- Write down the rules first. Every day spent there saves several later.
- Treat tests as part of the deliverable. They are what let you change things safely.
If you have a process that lives in spreadsheets and needs to become software, or an existing system that needs senior hands, I am happy to talk it through.