NiravProof of work
← All projects

Internal Tools

Case 04 / 10

Operating platform, 0→1

Built the company's operating infrastructure from scratch — a multi-module platform replacing a spreadsheet stack and six figures of annual SaaS spend.

Crave Robotics · 2026 · Sole product owner and builder

  • Replaced spreadsheets and $100K+/year of SaaS with one owned platform.
  • Seven operational domains, from dispatch to FDA recall traceability.
  • Used daily by field technicians and leadership, not just me — open for any department to pull what it needs.
  • Sole product owner, engineer, and operator.
$100K+ annual SaaS spend consolidated

The numbers

  • $100,000+
    Annual SaaS spend consolidated
  • 7
    Operational domains covered
  • Google Sheets + point SaaS
    Prior system
  • React
  • Vite
  • TypeScript
  • Node.js
  • Express
  • Drizzle ORM
  • PostgreSQL
  • Railway

Explore the platform

Interactive — synthetic data

Click through the sidebar — each module is a real screen from the platform, populated with synthetic data.

app.craverobotics.com/
Fleet status

Dashboard

25Total machines
21Online
3Issues
1Offline

Fleet uptime, 7D

MonTueWedThuFriSatSun

Fleet by region

  • LA-West
    8
  • LA-Central
    6
  • LA-East
    7
  • East SG Valley
    4

Needs attention

  • OfflineCR-009-24-11-000036h since last ping
  • PLC AlertCR-017-25-02-00025PLC fault code 12
  • Temp AlertCR-033-25-05-00019Freezer temp +4°F

A representative screenshot of the real platform, not a live connection to it. Machine names, locations, and every number in every module are synthetic.

How it fits together

  1. 1Telemetry and transactional data
  2. 2Domain modules
  3. 3Scheduled jobs
  4. 4Alerting
  5. 5Executive reporting
Read the full case study Hide the case study

The problem

Company operations ran on Google Sheets and a patchwork of SaaS subscriptions. No single source of truth, manual reporting, no way to enforce process, and every new operational requirement meant another spreadsheet or another subscription.

Why it mattered

A physical fleet business generates operational data continuously — telemetry, inventory movements, expiration dates, service events. Running that on spreadsheets does not just cost time; it makes whole categories of work impossible. Lot-code traceability, recall execution, and velocity-driven forecasting are not spreadsheet problems.

What I built

A multi-module internal platform. The modules, and what each one actually does:

  • Machine detail — per-unit state, telemetry, service history
  • Dispatching — the routing system described in Autonomous technician dispatch
  • Restocking — pick lists and execution tracking
  • Inventory — transfer logs, lot-code tracking, waste, expiration management, FDA/USDA recall traceability, and a full audit trail across every inventory movement
  • Menu optimizationlocation-level assortment
  • Demand planning12-month forecasts, seasonality, and reorder cadence
  • Product settings — vendor records, lead times, nutritional information, allergens
  • Executive reporting — operating metrics for leadership and board materials

I also moved the platform off a prototyping environment onto production hosting, which meant working through lockfile, monorepo, and Node runtime issues that had nothing to do with the product and everything to do with it staying up.

It isn’t a tool I use alone. Field technicians run their day through the dispatch and restocking modules, leadership pulls executive reporting directly instead of asking me for a number, and it’s open for any department to check whatever it needs — inventory, demand, machine status — without a spreadsheet request in between.

The clearest illustration of what the platform bought is a recall. On the old stack, tracing an affected lot across machines meant reconciling several spreadsheets by hand under time pressure. On the platform it is a query.

What I learned

Being both the operator and the builder collapsed the requirements loop — I was the user filing the bug, at least at first. Once field technicians and leadership started relying on it daily, the risk shifted to designing an interface only I found intuitive. The modules that generalized well were the ones where I forced myself to define the process before writing the interface.

What I would do next

Role-based permissions as the team grows. Test coverage on the scheduled jobs, which are the highest-consequence and least-covered surface in the system.

Described without confidential information. The demo and any figures inside it use synthetic data.