Skip to content
Gradmarc Adtech LLP

Case studyIllustrative write-up · no real client

From four tools to one order system

Orders, stock and dispatch notes in a single application, shaped around how a warehouse actually runs.

Client
None: illustrative
Industry
Manufacturing and distribution
Screens from
Ironleaf (concept)

01Challenge

The problem, as it was found

Orders arrived by email and chat, were tracked in a spreadsheet and re-keyed into a billing tool. Nobody could say with confidence where an order was.

  • Order status lived in several places, and the places disagreed
  • Stock was adjusted by hand after each dispatch
  • Dispatch notes were rebuilt from scratch for every shipment
  • Only two people understood how the tracking spreadsheet worked

Context

The business had grown past the point where a workbook could hold the operation together. Orders came through several channels, and each team kept its own view of the truth.

The warehouse team worked from shared desktops and phones, so the system had to be quick to use for people whose main job was not sitting at a computer.

02System

How it was put together

A web application with one order record at its centre, a thin API in front of the data, and role-based views for each team.

L1 · Views by role

Interface

  • Order desk
  • Warehouse view
  • Manager reports

L2 · Rules live here

API

  • Orders
  • Stock
  • Dispatch
  • Roles and auth

L3 · One source of truth

Data

  • Orders
  • Stock levels
  • Dispatch records
  • Audit log

L4 · Existing tools stay

Integration

  • Billing export
  • Read-only API

Path through the system

  1. 1Order received
  2. 2Stock reserved
  3. 3Dispatch note created
  4. 4Shipment confirmed
  5. 5Billing handoff

03What was built

The parts, in the order they shipped

  1. 01

    Order intake

    One place to record an order, whichever channel it came from, with the customer and items validated at entry.

  2. 02

    Status tracking

    A single status for each order that every team reads from, with a history of who changed it.

  3. 03

    Stock levels

    Stock that moves when orders are reserved and dispatched, instead of being corrected afterwards.

  4. 04

    Dispatch notes

    Notes generated from the order record, so they are consistent and no one retypes them.

  5. 05

    Billing handoff

    An export and API the billing tool reads from, replacing manual re-entry.

Ironleaf invoice INV-2026-0412 awaiting approval, with customer and GSTIN details, four line items with HSN codes, a CGST and SGST breakdown, an approval timeline and linked documents.
An invoice carries its tax breakdown, approval state and linked documents. Concept screen.
Ironleaf stock overview with value and reorder metrics, a stock table with bars against reorder levels, a stock movement chart and suggested purchase requests.
Inventory shows what to reorder and when, from the same records. Concept screen.

04Decisions

The choices that shaped it

  1. Decision 1

    One order record, many views

    Why

    Every team needed a different screen, but a second copy of an order would recreate the original problem.

    Trade-off

    Views had to be designed carefully so no team felt they were using someone else's tool.

  2. Decision 2

    Roles before features

    Why

    Deciding who may change an order, and when, shaped the data model more than any screen did.

    Trade-off

    It slowed the first release slightly and avoided rework later.

  3. Decision 3

    Billing stays in its own tool

    Why

    The billing system already worked and the finance team trusted it.

    Trade-off

    An integration to maintain, in return for no migration risk on the finance side.

05Technology

What it was built with

Drawn from our confirmed capability stack. Illustrative for this demo.
Frontend
Next.jsReactTypeScript
Backend
Node.jsExpress.jsREST APIs
Database
MySQL
Cloud and DevOps
DockerGitHub Actions

06Outcome

Centralized a fragmented workflow into one application.

  • Every team reads an order's status from the same record
  • Stock reflects dispatches without manual correction
  • The handover to billing no longer depends on re-typing

Demo case study. Outcomes are qualitative. No metrics, savings, revenue or user figures are claimed.

Start a projectCustom Software Development

More case studies

More case studies

Related services

Have something worth building?

Tell us what you want to build. A short brief is enough to start the conversation.

Start a projectAll case studies