VCtomic — Case Study

VCtomic — Portfolio intelligence and governed reporting for private markets

Industry

Venture capital, growth equity, and private equity

Product type

Multi-tenant portfolio reporting SaaS

Built by

Monthos

Live URL

Not published in the repository

At a glance

Problem

Investment firms chase portfolio company data across email and shared drives, with no governed sign-off cycle or reliable audit trail.

What we built

VCtomic — a web platform connecting investor organisations and portfolio companies around structured financials, documents, and an annual reporting workflow (Open → Submitted → Accepted).

Who it's for

General partners, operating partners, portfolio finance teams, and portfolio company CFOs at VC, growth equity, and PE firms.

Stack

React 18 · TypeScript · Vite · Tailwind CSS · Supabase (PostgreSQL, Auth, Storage) · Netlify

Scope / deployment

52-table Postgres schema with row-level security; 60 page components; 53 Playwright E2E specs; static SPA deployed to Netlify

Project impact

Monthos built the governed reporting layer between investment teams and their portfolio companies—structured financials, documents and sign-off in one place.

A governed cycle, not email chasing. Reporting periods move through Open → Submitted → Accepted with locks, mandatory reopen notes and post-acceptance edit logging.

Cross-portfolio analytics on demand. A report builder with filters, period comparison, charts and Excel export replaces hand-assembled roll-ups.

Security fit for financial data. Row-level security on all 52 tables, pre-provisioned access and CSP-restricted hosting—enforced in the database, not just the UI.

An auditable record of every change. Historical financial rows plus audit and post-acceptance edit logs answer "who changed what, and when".

Who this is for: venture capital, growth equity and private equity firms—general partners, operating partners, portfolio finance teams and portfolio company CFOs.The challengePrivate markets firms need more than a spreadsheet to manage portfolio reporting. The product documentation identifies several recurring pain points:

Operational drag — portfolio teams chase management accounts via email, store files in shared drives with inconsistent naming, and reconcile numbers manually for investment committee packs or lender reporting.

Weak audit trail — spreadsheet edits lack attribution; when a portfolio company restates EBITDA or debt balances, there is no reliable record of who changed what, or when.

Uneven portfolio behaviour — some companies submit early; others delay. Without a governed workflow, firms struggle to enforce a fair, documented process aligned to a firm-wide calendar.

Cross-portfolio analytics — investment teams need roll-ups across deals, time periods, and metrics — not one-off exports assembled by hand before each review.

VCtomic is designed as the governed reporting layer between an investment team and its portfolio companies: structured financials, documents, and sign-off in one place — without replacing the portfolio company's general ledger or ERP.Our approachMonthos built VCtomic as a production-grade, domain-rich SaaS application with security and business rules enforced at the database layer, not only in the UI.Guiding principles evident in the codebase:

Multi-tenant by design — investor organisations, partner organisations (portfolio companies), and deals form a clear hierarchy; each party sees only the data their role permits.

Governed workflow over ad hoc exchange — reporting periods move through explicit statuses (Open, Submitted, Accepted) with locks, mandatory reopen notes, and post-acceptance edit logging.

Database-first security — 100 row-level security policies across 52 tables, backed by ~100 Postgres functions; the React client talks directly to Supabase with no custom API layer in the repository.

Historical integrity — financial data is stored as dated rows tied to reporting periods rather than silent overwrites.

Test the workflows that matter — 53 Playwright end-to-end specs cover authentication, access control, deal modules, period workflow, reports, and super-administration.

What we deliveredOrganisation and access model

Concept

Description

Investor organisation

The GP / fund management entity — owns deals, billing, admin users, and reporting policy

Partner organisation

The portfolio company — enters financials and documents; submits reporting periods

Deal

A single investment relationship under monitoring, typed (property or private equity) with sector, currency, and country metadata

Reseller

A channel partner who introduces investor organisations and earns commission (managed by Super Admin)

Five primary user roles drive the application:

Role

Typical user

Core capabilities

Super Admin

Platform operator

Cross-tenant administration: investors, partners, resellers, reference data, platform revenue

Investor Admin

Partner lead, portco finance head

Manage deals and partners; accept or reopen submissions; run reports; edit accepted periods with audit logging

Investor User

Investment team, junior finance

View deals and reports; access scoped by deal permissions

Partner Admin

Portfolio company CFO

Enter financial data while periods are Open; submit for review; manage partner users

Partner User

FP&A, accounting support

Contribute to assigned deals; cannot submit periods independently

Additional access controls include per-deal grants (deal_access), portfolio-wide access flags (all_deals_access), pre-provisioned user login (check_valid_user RPC), and the ability to disable partner users at the account level.Deal managementEach deal links an investor organisation to a partner organisation and carries metadata used for reporting and filtering: legal entity name, deal type, sector and sub-sector, currency, country, province (for South African property deals), asset class (Development, Yield, or Trade), and active or archived status.Deal pages are organised into 20 dedicated modules beyond the deal overview:

Area

Modules

Documents

General attachments, deal summary, legal documents, shareholder register, management accounts, counter-indemnities

Financial

EBITDA (private equity path), net income and yield (property path), property valuation, effective interest valuation, effective shareholding, organisation NAV, cashflow

Debt

Bank debt, organisation debt, KLT debt, other debts

Surety

Organisation surety, other surety

Tasks

Cross-module completion tracking

Governed reporting period workflowThe production reporting model uses an annual fiscal year from 1 March through the end of February. A new period opens for data entry on 1 March.

Status

Meaning

Who can edit

Open

Data entry in progress

Partners and Investor Admins

Submitted

Sent for investor review

Locked for all until Investor Admin acts

Accepted

Approved and closed

Partners read-only; Investor Admin can edit via dedicated edit mode (changes audit-logged)

Partner admins submit periods from the Period Workflow page. Investor admins accept or reopen with mandatory notes visible to the portfolio company. The system remembers each user's last selected reporting period per partner organisation.Investor analytics and exportsThe investor report builder (/investor-admin/reports) supports:

Single-period and cross-period comparison modes

Filters by partner, sector, sub-sector, currency, and free-text search

Configurable column picker with metric presets

Comparison charts (Recharts)

Excel export aligned to the current view (via xlsx)

Document managementSix Supabase Storage buckets back the document modules:

Bucket

Purpose

deal-attachments

General deal files

deal-summaries

Deal summary attachments

legal-documents

Contracts and facility letters (investor-priority visibility)

shareholder-register

Cap table extracts

management-accounts

Management account packs

counter-indemnities

Indemnity schedules

Platform administrationSuper Admin routes cover reseller management, investor and partner onboarding, reference data (banks, sectors, countries), investor user administration, and a controlled data-clearing tool for maintenance.The Super Admin dashboard surfaces platform-wide counts and monthly revenue breakdown by currency.Technical highlights

Layer

Technology

Frontend

React 18, TypeScript, Vite 5, React Router 6

Styling

Tailwind CSS 3, Lucide React icons, React Hot Toast

Charts & export

Recharts, SheetJS (xlsx)

PWA

vite-plugin-pwa (installable, auto-updating service worker)

Backend / data

Supabase — PostgreSQL 17, Auth (email/password, PKCE), Storage, Realtime

Auth UI

@supabase/auth-ui-react

Hosting

Netlify (static SPA, dist/ publish)

Testing

Playwright E2E (53 spec files, page objects, global setup/teardown)

Database tooling

Supabase CLI, single baseline migration

Notable architecture decisionsDirect client-to-Supabase pattern. The application has no Netlify Functions or Supabase Edge Functions in the repository. Business logic is split between TypeScript modules in src/lib/ (notably reporting-periods.ts and report-builder.ts) and Postgres functions and policies in the baseline migration (~10,700 lines).Row-level security as the security boundary. All 52 tables have RLS enabled with 100 policies. Access is enforced at Postgres regardless of client-side routing.Pre-provisioned users only. Authentication uses Supabase Auth, but login is gated by the check_valid_user RPC — an auth account must exist in a valid user table before access is granted.Defence in depth at the edge. Netlify serves the SPA with security headers including Content-Security-Policy restricting connections to Supabase endpoints, plus X-Frame-Options, X-XSS-Protection, and Referrer-Policy.Audit trail for sensitive changes. Client-side audit logging writes to audit_logs; post-acceptance edits are recorded in post_accept_edit_log.Architecture diagram┌─────────────────────────────────────────────────────────────────┐ │ User browsers │ │ (React SPA · PWA · role-based routing) │ └────────────────────────────┬────────────────────────────────────┘ │ HTTPS ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Netlify CDN + static hosting │ │ SPA fallback · security headers · CSP to Supabase │ └────────────────────────────┬────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Supabase │ │ ┌──────────────┐ ┌──────────────┐ ┌───────────────────────┐ │ │ │ Auth (PKCE) │ │ PostgreSQL │ │ Storage (6 buckets) │ │ │ │ pre-provision│ │ 52 tables │ │ deal docs, accounts │ │ │ │ ed users │ │ 100 RLS │ │ │ │ │ │ │ │ policies │ │ │ │ │ │ │ │ ~100 funcs │ │ │ │ │ └──────────────┘ └──────────────┘ └───────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘ Organisation hierarchy: Super Admin └── Investor Organisations (subscription billing) └── Partner Organisations (portfolio companies) └── Deals (financial + document modules) Resellers (channel · commission on introduced investors)OutcomesCapability transformation

Before (documented pain)

After (what VCtomic provides)

Management accounts chased via email

Structured data entry across 20 deal modules, tied to reporting periods

Files scattered in shared drives

Six document types with Supabase Storage and role-based visibility

Spreadsheet edits without attribution

Historical financial rows, audit logs, and post-acceptance edit logging

Ad hoc submission timing

Governed Open → Submitted → Accepted workflow with mandatory reopen notes

Manual cross-portfolio roll-ups

Report builder with filters, comparison mode, charts, and Excel export

By the numbersEvidence from the codebase and schema:

Metric

Count

Database tables

RLS policies

100

Postgres functions

~100

Baseline migration lines

~10,700

Application routes

Deal sub-module pages

Page components

TypeScript / TSX source files

123

React components

Custom hooks

Library modules

Playwright E2E spec files

Supabase Storage buckets

Primary user roles

Document attachment types

Why this project mattersVCtomic demonstrates Monthos's ability to deliver a domain-complex, multi-tenant SaaS — not a generic CRUD application, but a system shaped by private markets reporting requirements:

Deep financial modelling spanning private equity and property deal paths, with debt, surety, NAV, valuation, and cashflow modules.

Governed workflow that encodes business rules (period locks, reopen notes, accepted-period edit mode) into both application logic and database policy.

Security appropriate to financial data — RLS on every table, pre-provisioned access, disabled-user blocking, and CSP-restricted hosting.

Production readiness signals — installable PWA, comprehensive E2E test coverage across roles and modules, and a single consolidated schema migration suitable for managed deployment.

It is a reference build for firms that need a portfolio reporting layer without building and maintaining custom infrastructure from scratch.Services demonstrated

Custom SaaS application design and build — multi-tenant architecture with five role-based experiences

Domain-driven feature development — financial, debt, surety, document, and workflow modules tailored to private markets reporting

Supabase / PostgreSQL engineering — schema design, RLS policies, Postgres functions, and Storage integration

React / TypeScript frontend — 60 page components, responsive navigation, dark mode, and PWA support

Security and access control — database-enforced tenancy, pre-provisioned auth, CSP headers, and audit logging

Quality assurance — 53 Playwright E2E specs with page objects and seeded test accounts across all roles

Netlify deployment configuration — static SPA hosting, redirects, and security headers

Get in touchMonthos designs and ships custom, production-grade applications for teams that need more than off-the-shelf software.monthos.comCase study prepared for Monthos.com · Project: VCtomicMonthos Group — Cheltondale, Johannesburg, SA. Email info@monthos.com, phone +27 (68) 750 7313.Case studies · Privacy Policy · Terms of Service