Manifest

The problem

The business ran procurement, inventory, and sales analysis across 25+ interlinked spreadsheets — one for inventory, one for sales history, one for inbound shipments, one for outbound orders, one for margin tiers, and more.

Every sheet fed the next by hand. A missed formula, a stale tab, or a renamed column could silently break a procurement decision for the whole company, and no one would notice until stock ran out or a lot expired on the shelf. There was no single source of truth, no audit trail, and no way to see risk — a stockout, an aging lot, a dead SKU — until someone happened to be looking at the right tab at the right time.

Reconciling the sheets against the accounting system took a standing chunk of a person's week, every week, and the answer was still only as fresh as the last manual update.

What I built

A centralized platform, rolled out module by module

I designed and built a Flask/PostgreSQL application to replace the spreadsheet ecosystem incrementally, without taking the business offline. Each module went live independently and ran in parallel against the legacy spreadsheets until its output was verified, before the spreadsheet was retired.

Three independent source feeds consolidate into one database; every downstream module reads from — and writes back to — the same tables.

System modules

Five modules, one database

The analytics engine

Priority-ordered risk classification

The core of the procurement module is a single ranking function. Every SKU is evaluated against a fixed, priority-ordered list of conditions — the first condition it matches wins — so that a dead-stock item that is also technically "low stock" is never mis-ranked above genuine reorder risk.

# evaluated top-to-bottom; first match wins
def classify_risk(sku):
    if sku.on_hand == 0:
        if sku.tier == "A" and sku.velocity_6mo > 5:
            return "STOCKOUT — BUY IMMEDIATELY"
        if sku.tier in ("A", "B"):
            return "STOCKOUT — HIGH PRIORITY"
        if sku.velocity_6mo > 5:
            return "STOCKOUT — REORDER NOW"
        if sku.velocity_6mo == 0:
            return "DEAD STOCK — NO DEMAND"
        return "STOCKOUT"

    if sku.days_to_expiration <= 30:
        return "AGING — CRITICAL"
    if sku.days_to_expiration <= 90:
        return "AGING — URGENT"
    if sku.days_to_expiration <= 180:
        return "AGING — WATCH"

    if sku.tier in ("A", "B") and sku.months_of_stock <= 3:
        return "LOW STOCK — PRIORITY ITEM"
    if sku.months_of_stock > 12:
        return "OVERSTOCKED"

    return "OK"

Two rolling velocity windows — a 6-month baseline and a 3-month trend — drive the reorder math, so a SKU that is slowing down gets flagged before it becomes dead capital, not after. The full, runnable version of this module is in code-samples/ alongside this write-up.

How I worked

Ship the module, validate against the old system, then retire it

1. 01

   Interviewed the people who actually used each spreadsheet before writing schema — the business rules living in a column header or a conditional format were often more important than the data itself.

2. 02

   Built one module at a time against the real database, running it side-by-side with the spreadsheet it replaced until the numbers matched.

3. 03

   Treated the accounting system, not the spreadsheets, as the source of truth for anything financial — spreadsheets were reference only, never authoritative.

4. 04

   Retired each spreadsheet only after its replacement module had run in production long enough to earn trust.

Try it