The Good Part

Introduction

In appliance delivery, success isn’t something the customer notices, but rather the absence of failure. A duplicate record, a misassigned driver, a timestamp out of sync with reality: each one is a missed window or a second trip out. The Good Part’s operations had outgrown their backend, and the cracks were starting to show. Over the course of this software development project, we delivered:

• Back-end development in Java 17
• Database modeling in PostgreSQL
• Test-driven development in a Dockerized environment
• API development and deployment integration

Challenge

The Good Part came to Redwerk with a backend that had quietly fallen behind their operations. As order volume grew, minor frictions in the internal system became daily slowdowns for dispatchers, warehouse staff, and managers.

Duplicate client records had been piling up, creating inconsistencies across orders and forcing the team to clean things up by hand. Dispatchers couldn’t see in real time which drivers were already occupied, which made route planning slower and less accurate. Warehouses and subsidiaries weren’t formally linked in the data model, so logistics coordination relied on memory and side-channel communication.

On top of that, timestamps weren’t always accurate, order statuses had to be flipped manually after deliveries, and there was no clean way to validate or preview an order before pushing it through the system. Each of these issues was small on its own. However, together they meant more manual work, slower turnaround, and less trust in the data. The team needed a focused engagement to fix the highest-impact pain points quickly without rebuilding the whole system or disrupting day-to-day operations.

Solution

We took on a tight, targeted scope and delivered seven backend improvements on a tight schedule. The codebase is written in Java 17, with a functional style built around the Stream API. Our development team matched that, no exceptions, so the new code reads like the rest of the system instead of standing out as someone else’s.

Every feature shipped with its own unit and integration tests to uphold the client’s high Test-Driven Development standards. Tests run inside a Docker environment that spins up a real PostgreSQL instance, so we’re validating against the actual database engine the system runs on, not a mock. Deployments go out through a GitHub Actions Build–Push–Deploy pipeline, with staging and live as separate targets, which keeps releases fast and predictable.

Here’s what we delivered:

• Duplicate client management: Built automatic detection of duplicate client records, clear labeling in the UI, and a resolution workflow that lets staff merge or dismiss duplicates in a few clicks. No more weekly clean-up batches.
• Warehouse management: Introduced a proper warehouse entity and modeled the relationships between warehouses and subsidiaries, so logistics coordination has a real structure behind it rather than relying on tribal knowledge.
• Driver availability for dispatch: Added real-time indicators showing which drivers are already occupied during route planning. Dispatchers can now build routes without flipping back and forth between screens or having to guess.
• Order lifecycle automation: Completed deliveries now update their status automatically, removing a manual step that previously bottlenecked end-of-day reporting.
• Timestamp accuracy fixes: Hunted down and fixed the timestamp bugs that were making order tracking unreliable.
• Preview Orders API endpoint: Added a backend endpoint that lets the team review and validate order data before it’s committed, so errors get caught before they become customer-facing problems.
• Code integration and pull request support: Worked inside the client’s existing repo and review process, so every change was merged cleanly without extra integration overhead on their side.

All features shipped fully tested and slotted into the running system.