All work

    Cloud POS

    Point of sale with a Python backend, running real transactions

    ReactFastAPIMongoDBPythonboto3TailwindRadix UI

    Role: Sole engineer — React frontend, FastAPI backend, MongoDB schema, deployment. · Updated 2026-09-01

    What's actually in it

    55
    Modules in graph
    madge dependency graph of the source repo
    38
    Dependency edges
    densest graph of the four — heavy primitive reuse
    FastAPI 0.110
    Backend
    uvicorn 0.25, pymongo 4.5, boto3, cryptography
    52
    Frontend deps
    production package.json dependencies

    The problem

    The operator was running the till on paper and reconciling at close. Stock counts drifted, expenses went unrecorded, and there was no way to answer 'what sold today' without counting receipts.

    What I built

    • 01Built the till interface first — product grid, live cart, and checkout — because if the point of sale is slow the rest of the system never gets used.
    • 02FastAPI + MongoDB backend, with boto3 for object storage and cryptography for credential handling.
    • 03Order history with full line-item detail, so a dispute is resolved from the record rather than from memory.
    • 04Expense tracking in the same system as revenue, so the dashboard KPIs are actual margin and not just gross takings.
    • 05Dashboard built on the real transaction stream — the numbers on screen are what the shop actually did.

    Building something in this shape? Book a 30-min scope call →

    Walkthroughs

    The developer POV video is the one worth your time — it walks the dependency graph, the route map, and the data layer rather than clicking through screens.

    Developer POV — architecture walkthroughThe React/FastAPI split, the MongoDB shape, and why the graph is dense.
    Product demoA sale from product grid to completed order.

    Engineering decisions

    UI primitives as the graph centre

    The most-imported modules are button, card, select, and input — not feature components. For a till used under time pressure, consistency of interaction beats bespoke screens, and it keeps the whole surface restyleable from one place.

    Python backend rather than serverless functions

    A till needs a persistent connection and predictable latency. FastAPI on a long-lived process avoids cold starts at the exact moment a customer is standing at the counter.

    Expenses in the same schema as sales

    Keeping cost entry in a separate tool is how margin reporting dies. Both write to the same store so the dashboard computes net without a reconciliation step.

    The product

    The till — product grid built for speed over browsing.
    Live cart with running total.
    Order history with full line-item detail.
    Dashboard KPIs computed from the real transaction stream.
    Product catalogue and pricing.
    Expenses in the same store as sales, so margin is computed not estimated.

    Want something built the way Cloud POS was?

    Bring the problem, not a spec. 30-minute call — I'll tell you what it actually takes to build, what I'd cut, and what it costs. No decks, no discovery phase invoice.

    Related builds