One back office for three storefronts

The challenge

Tru-Scapes sells outdoor lighting through more than one storefront: its B2B trade portal and separate WooCommerce stores for other product lines. Each store had its own orders, its own product records and its own stock figures. Staff worked across several admin screens, and the CRM held a different view of the same customers.

When one business runs on several systems, the cost shows up as re-keyed orders, stock that is wrong somewhere, and nobody being sure which number to trust.

The requirement

• One system where staff see orders, products, customers and inventory from every store.
• Changes made centrally, such as a stock update or an order status, sent back to the store they belong to.
• Customer and deal data kept in step with HubSpot.
• Role-based access for internal staff.
• A foundation that later phases can build on for fulfilment, shipping and accounting.

This is our second system for Tru-Scapes, after the B2B store.

The solution

We are building the Command Center as a central back office. It imports orders, products, categories and customers from each configured store on a schedule and holds them in a single database. Each order keeps a record of the channel it came from.

Staff manage the catalogue, including variants, categories and images, and update inventory in one place. When a product goes out of stock, or an order’s status changes, the change is pushed out to the originating store.

HubSpot is connected in both directions: contacts are imported, and contacts and deals are pushed back, with a status view and a manual sync for when someone needs it now.

Customer records can be filtered, opened in detail and exported to Excel.

Architecture

The backend is a layered Spring Boot application on PostgreSQL, with the schema managed by versioned Flyway migrations. It exposes a documented REST API to a React frontend.

Synchronisation runs per store on its own schedule: an initial import when a source is first connected, then orders every few minutes and the catalogue daily. Outbound updates are triggered by events that fire only after the database transaction has committed, so a store is never told about a change that was rolled back. Every inventory change is written to an event log.

Authentication uses short-lived access tokens with refresh tokens held in the database, and role checks are enforced in the API.

Technology

Java 21, Spring Boot, PostgreSQL, Flyway, React, TypeScript, Tailwind CSS, TanStack Query, and the HubSpot and WooCommerce APIs.

Outcome

The project is in active development. The first phase is in place: catalogue, customers, orders, multi-store synchronisation and the HubSpot connection. Fulfilment and shipping are the next phase.