From Spreadsheets to a Portfolio Command Center
Concept to real multi-tenant software for a construction and real-estate portfolio
VSF Consulting Services manages construction and renovation projects across a portfolio of properties for its client organizations. That work lived in spreadsheets, then in a single-computer prototype that stored everything in one browser. We were brought in to take the concept the whole way: a secure multi-tenant application where properties, contractors, vendors, projects, schedules, quotes, and an itemized cost ledger all roll up into budget, forecast, and cash-needs reporting, with AI reading contractor quotes and invoices as they arrive.
- Custom Software Development
- Product Design
- AI Document Processing
- Multi-Tenant Architecture
- Database Design
Challenges & Solutions
What stood in the way, and how we cleared it.
The portfolio lived in spreadsheets, then in a single browser
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.
Costs were three numbers somebody typed
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.
Approving a quote and recording the cost were separate acts of memory
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.
Quotes and invoices arrive as documents, not data
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.
A forecast that quietly reported the wrong variance
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.
Our Strategy
A phased approach to delivering measurable results.
Turning the prototype into a specification
We took the working single-computer concept and specified what it needed to become: the operating model to preserve, the data model underneath it, and an explicit decision to start clean rather than migrate local browser data.
- Product specification
- Data model design
- Scope boundaries
- Financial model definition
Building the multi-tenant foundation
We built the database first: portfolios as tenants, invitation-based membership, roles, and row-level security on every table, with reporting views that compute financial roll-ups where the data lives.
- Postgres schema
- Row-level security policies
- Reporting views
- Invitation and membership system
Building the operating surfaces
We built the day-to-day application: properties, contractors and vendors, projects and upcoming work, a construction schedule with dependencies, quotes, and the itemized cost ledger.
- Portfolio and property management
- Project and schedule tracking
- Quotes and estimates
- Itemized cost ledger
Adding intelligence and reporting
We added AI document extraction for quotes and invoices, AI-generated construction schedules that fall back to a template rather than failing, and filterable reporting with saved views for budget, forecast, and cash needs.
- Quote and invoice extraction
- AI schedule generation
- Budget, forecast, and cash-needs reports
- Saved report views
Results
Measurable outcomes that speak for themselves.
Durable and shared
The portfolio lives in a managed database with per-tenant isolation instead of one browser's local storage.
Traceable spending
Every cost entry carries its vendor, date, description, and source document rather than being an overwritten total.
Rules that cannot be skipped
Quote approval, cost commitment, and project promotion are enforced in the database, so every write path obeys them.
Tech Stack
The technologies and tools powering this project.
