From Spreadsheets to a Portfolio Command Center

Project tracking started in spreadsheets and grew into a working prototype that ran as a single file on one computer, storing the entire portfolio in that browser's local storage. Its own manual advised keeping backups because browser privacy tools could erase everything. Nothing synced between people.

We rebuilt the concept as a real multi-tenant web application on a managed Postgres database, with invitation-only access, per-tenant isolation enforced at the database level, and an explicit rule that the browser stores nothing but the session.

The portfolio became durable, shared, and auditable instead of living on one machine.

A project carried labor, material, and other cost as single figures that were overwritten as work progressed. You could see that thirty thousand dollars of labor had happened, but never what it was, when, or from whom.

We replaced the typed totals with an itemized ledger where every entry carries a vendor, a date, a description, and the source document, rolling up into the same project and property totals.

Spending became traceable to its source instead of being a number with no history behind it.

Contractor quotes came in against upcoming work, one got approved, and from that moment the amount was committed spend. But approval only changed a badge, and somebody had to retype the number into the cost ledger, or forget to.

We moved the rule into the database. Approving a quote creates the committed cost entry, editing an approved quote keeps it in sync, un-approving removes it, and deleting the quote cascades. The same triggers promote an approved upcoming project into an active one.

Business rules hold no matter which path writes the data, because they live below the application rather than inside one screen.

Every contractor quote and vendor invoice landed as a PDF or a photo that somebody had to read and re-key, which is slow and is where transcription errors enter a financial record.

We built AI extraction for both. Quotes yield amount, dates, contractor, and scope; invoices yield total, vendor, date, number, and a spending category. Extracted business names are matched to existing contractors and vendors at save time so duplicates are not created, and the extraction is hardened against instructions hidden inside uploaded documents.

Documents become structured records on upload, with the numbers already in the ledger.

The forecast originally added cash needs on top of recorded costs, so any project with cash needs showed a negative variance even when it was perfectly on budget.

We corrected the financial model and moved the authoritative calculation into database views, with the client-side arithmetic kept deliberately in lockstep and money rounded to cents rather than accumulating floating-point error.

Budget, forecast, variance, and cash needs now mean one thing each, computed in one place.