The operating system behind a family office

What it is, and who uses it

A desk that runs a few hundred positions across many brokerage accounts, on margin, with a pipeline of names it is researching and a weekly rhythm of decisions, needs more than a brokerage portal. It needs one book that reconciles to the custodian every morning, a way to look at every position against the same yardstick, a record of why each name is held and who argued for it, and a feed of what moved and why that is already written by the time anyone sits down. For years that lived in a workbook that was rebuilt every week. This platform replaced it, and it has grown with the desk for the better part of a year of daily use.

The day has a shape. Overnight, the custodian's encrypted feed lands and is reconciled into tax lots; prices, fundamentals, statements and news are refreshed; the monitors run and the attention memory decides what is new. By the time the desk opens the Daily Review, the Compare heat map has scored every position, the fundamentals monitor has fired on what crossed a limit, and the morning email has already said which fifteen names deserve a look and why. During the day the Review Board carries the arguments: analysts vote on the pipeline and the portfolio, the portfolio manager converts a call into a trade with one leg per account, and the trade queue is the only door to the custodian. After the close, the movers email reads the whole market and the snapshot reads the book.

What makes it different is that it argues with itself. A red cell is red only when the number is strictly past the limit the monitor fires at, so the table and the alerts can never disagree. Every measure carries its definition and its last four quarters, so a reader can check a number before acting on it. A thesis has exactly one writer and a version history. A topic report tiers every listed name in a space and says, for each one, what it rests on and what would break it. And nothing automated can trade: the AI reads, scores, drafts and flags, and a person decides.

What you are looking at

The platform replaced a spreadsheet-based workflow for a multi-account book with a nightly broker feed, live pricing, a research pipeline, a daily review system and a set of automated briefings. Every screen in this demo is the real template rendered over an invented book: the tickers are real public companies so the charts and fundamentals are genuine, but the accounts, lots, notes, votes, theses and people are synthetic. The AI-written passages (earnings previews and reads, desk briefs, KPI cards, mover notes) are composed for the demo from those public figures and a short profile of each company; nothing is generated live, and none of it is a recommendation.

Some of the parts worth a look:

• The Compare heat map scores every position against the same limits the fundamentals monitor fires at, and an attention memory tracks whether each red cell is new, worse, chronic or already seen, so the morning email leads with what changed rather than with what is merely red. Right-click a cell to mark it seen; click a reading to see its last four quarters.
• The Review Board keeps the pipeline and the portfolio on one table. Analysts vote; a trade is filed only when the portfolio manager converts a call, never by an AI and never by agreement alone. The report pane prints a one-pager per stock with evidence chips captured from the figures that made the case.
• The research layer gives every idea a provenance, every stock a versioned thesis with a single writer, and every theme a generated report that discovers, verifies and tiers the listed names in a space, with odds, differentiation and both cases written for every one.
• The operations half runs on a separate worker process: the broker feed, overnight enrichment, cache warming, twenty-odd scheduled emails, and backups with an immutable off-site copy that has been proven by rebuilding the whole platform from it.

How it is built

Python and Flask with SQLAlchemy on PostgreSQL; Jinja templates with Tailwind, Alpine.js for the reactive parts and Chart.js and Lightweight Charts for the charts. One web service and one worker process, so a long import or a model sweep can never take a page down; a scheduler with a dozen nightly jobs, each wall-clock bounded and watched by a heartbeat.

• Data in. The custodian's PGP-encrypted SFTP feed every morning, with a self-healing backfill for a late day; yfinance for prices, fundamentals, statements and corporate actions, with the corporate-action cliffs re-synced automatically; SEC EDGAR for 13F filings; Finnhub and RSS for news; a free-text-proof ticker universe.
• Models where reading is the job. Haiku for classification and screens, Sonnet for judgement, Perplexity for search, each metered and cached where a cache can actually hit; a reviewer that reads a stock's own dossier before it is shown the desk's thesis; prompts that forbid recommendations where a recommendation would be a second opinion.
• Rules that keep the numbers honest. Red means strictly past the limit; a missing value sorts last in both directions; a failed fetch is never recorded as data; a percent and a fraction never meet in one variable; every rollup is a prefix test over one tree.
• Five thousand five hundred tests, checked by mutation: each defect a test guards against is re-introduced on purpose to prove the test can fail, and the ones that could not are rewritten. Templates are rendered under strict undefined and their inline scripts parsed by Node in the suite.
• Operations. A deploy on every push through a serialised safe-deploy that waits out a running import; nightly backups of every database to two object stores, one of them immutable for thirty days; an in-app assistant that reads the book through the app's own calculations, never by recomputing them in SQL.

What it is, and who uses it

A family office that holds a few hundred private investments through dozens of legal entities, owns a portfolio of properties each run by a different manager, lends to its own projects and operating companies, and still has to close its books every month and file its taxes every spring, outgrows spreadsheets quietly and then all at once. For years this office ran on a set of linked workbooks, a general ledger that did not know what a deal was, and a few people who remembered how the pieces fit together. This platform replaced that, one domain at a time, until the workbooks could be retired.

It is used daily by everyone who touches the money. The controller runs the month-end close in it, against the QuickBooks postings it pulls in, and reconciles cash, brokerage and vendor statements from the same screens. The investment side records marks, distributions and capital calls, and reads performance by deal, vintage, manager and asset class. The real-estate side reviews every property's monthly package, approves the translated figures and compares managers on the numbers they sent. The principal reads a dashboard, a personal financial statement and a weekly cash report that all come from the same rows. In tax season the K-1 tracker, the booked-income check and the capital roll-forward replace the spreadsheet that used to be built from scratch each year.

Two ideas run through all of it. The first is attribution: a deal is stored once per holding entity, and the ownership chain attributes every dollar to the family exactly once, so the dashboard, the entity pages and the deal pages can never disagree about what the family owns. The second is provenance: every figure that came from somewhere else — a manager's statement, a sponsor's notice, a QuickBooks posting, a document filed by the sibling Documents app — keeps a link back to the thing it was read from, so a number on screen can always be checked against the page that produced it.

What you are looking at

The Family Office platform is the system of record for a single family's investments: every deal, the entity that holds it, what was put in, what it is worth, and every dollar that has come back. It replaced a set of linked workbooks, and most of its rules exist because a workbook once got them wrong.

Some of the parts worth a look:

• One deal, many rows. A deal held through several entities is stored once per holding entity, and every figure is attributed to the family exactly once through the ownership chain, never twice.
• Returns come from the ledger. Distributions are classified from the actual transaction lines (operations, capital, sponsor economics), so the multiples on screen can be traced to the postings behind them.
• Real estate is its own book. Each property carries its statements, debt, capital projects and valuation inputs, and the dashboard rolls them up by state, manager and stage.
• The tax season is tracked, not remembered. Which K-1s are expected, which arrived, which entities file what and when, and the action items that fall out of the review.

How it is built

Python and Flask on PostgreSQL, with SQLAlchemy models over a schema of some one hundred and forty tables; server-rendered Jinja pages with Alpine.js for the interactive parts and Chart.js for the charts. It runs as a web service and a separate worker process, so an overnight job or a long import can never take a page down.

• QuickBooks Online is the ledger of record. Its postings are pulled into the platform through the QuickBooks API and kept as a mirror, and every cash, close, booked-income and recurring-cash page reads those same rows rather than a copy of its own.
• Documents arrive from the sibling apps. The Documents app files each manager package into the office's library and the platform ingests it, translates it through the manager's chart-of-accounts mapping and keeps the ingest as the provenance of every figure; the Stocks app publishes the public-equities positions the dashboard consolidates.
• Translation is data, not code. Each manager's format is a set of mapping rows from their account names to the platform's standard terms, edited in the app; a line the mapping does not know is reported on the tie-out rather than silently dropped.
• An audit trigger in the database records every insert and delete on the sensitive tables, with the session, the application and the connection that made it, outside the reach of application code.
• Office add-ins for Excel and Outlook let the team file a document, pick a record or pull a figure without leaving the spreadsheet or the mail client.
• Over ten thousand tests, checked by mutation: each defect a test guards against is re-introduced on purpose to prove the test can actually fail. Boot-time migrations run under a database advisory lock, every push deploys through a serialised safe-deploy, and every database and repository is captured nightly to two object stores, one of them immutable, from which the whole platform has been rebuilt in a rehearsal.

What it is, and who uses it

An investment desk sees far more opportunities than it can take: venture rounds, private-equity co-investments, credit, fund commitments, and multifamily, industrial and commercial properties, each arriving as a deck, an email thread or a phone call. The hard part is not finding deals; it is deciding them consistently, remembering why, and never letting one stall without anyone noticing. Before this application the desk tracked that in a spreadsheet and a shared inbox, and a deal's history lived in whoever had handled it.

The Deal Evaluator gives every opportunity the same path. It arrives by email or by hand and is drafted into a record; it is classified into one of seven deal types, each with its own diligence checklist, scoring rubric and weights; it moves through the stages of a pipeline where one person is responsible at every step; it is scored on questions with red-flag knockouts, underwritten against the sponsor's own numbers where the type calls for it, compared against its peers, and written up in a memo that grows with the stage. Follow-ups, sign-offs and the emails and documents that came with the deal all hang off the same record, so the page for a deal is its complete dossier.

The desk reads the pipeline board every morning, the analysts work inside the deal pages, and the principal reads the memos and the comparisons before a decision. A few rules keep it honest: a sign-off records whose court a deal is in but blocks nobody, so nothing can silently stall behind a missing signature; a memo section written at screening is carried forward rather than rewritten, so the reasoning at each stage stays on the record; and the AI only ever reads a deal's own documents, never the open web, so what it drafts can be checked against the file.

What you are looking at

The Deal Evaluator is where inbound opportunities get decided. A deal arrives by email or by hand, is classified into one of seven types (venture, private equity, credit, a fund, or a multifamily, industrial or commercial property), and walks a pipeline of stages with a named owner at every step. Each type has its own rubric: weighted questions, hard red-flag knockouts and a computed recommendation, so two people scoring the same deal are measured against the same model.

Some of the parts worth a look:

• The underwriting module hangs a standardised apartment underwrite off a deal: every income and expense line is driven by a method (the house standard, the T-12, the sponsor's budget or a custom figure), reconciled against both source documents, and rolled into a five-year pro-forma with a refinance, an exit and the waterfall.
• The stage memo is one document that grows with the deal. A section written at screening is carried into the first assessment and the underwriting memo rather than rewritten, and the combined dossier points back instead of repeating.
• Sign-offs and ownership never gate anything, by design: anyone can move any deal, and the system records who did and whose court it is in, so nothing silently stalls without a name on it.
• The intake reads a forwarded email or a deck and drafts the record; the diligence checklist is per type, and the AI reads the deal's own documents when asked, never the open web.

How it is built

Python and Flask on PostgreSQL, server-rendered pages with Alpine.js for the interactive parts. The per-type configuration — checklists, rubric questions, section and question weights, stage owners, underwriting bands — is data edited in the app, not code, so the desk can change how a type is judged without a deploy.

• Email intake reads a forwarded thread and its attachments through the Microsoft Graph API and drafts the record; the diligence checklist and the rubric are instantiated for the deal's type the moment it is classified.
• Document reading, not web search. When the AI is asked to summarise, score or draft, it is given the deal's own documents and nothing else, so every claim it makes can be checked against the file it came from.
• Scoring is explainable. A recommendation is computed from the answers through the stored weights and knockouts, and the evaluation page shows every step of that arithmetic.
• Shared platform. Single sign-on with the office's other applications, the same database cluster, nightly backups to two object stores and a deploy on every push through a serialised safe-deploy.
• Over twelve hundred tests, checked by mutation so that a test which cannot fail is found before it is trusted.

What it is, and who uses it

The private book is the hardest part of a family office's portfolio to see clearly. Funds report quarterly and late, in capital-account statements that each administrator formats differently. Direct companies send investor letters, board decks and management accounts in their own shapes and on their own cadence, or stop sending them when things get hard. Marks move rarely and are stale most of the time. The question the office actually needs answered — which of these positions needs attention now, and why — was being answered by reading PDFs.

The PE / VC Monitor is a reading layer over the office's own record of its private positions. It takes the positions the Family Office platform already holds (cost, mark, distributions, performance) and adds everything the office learns about them from what they send: every document classified and dated, every investor letter read into dated headlines and proposed figures, every company's own accounts kept period by period with a tie-out, and every fund's schedule of investments read into a holdings grid. A review queue sits between the reading and the record, so a figure a model proposed never counts until a person approves it.

On top of that record it keeps a small universal spine of operating metrics for every company — revenue, EBITDA, cash, burn, runway, headcount — scored against the plan the company itself sent, within one reporting cadence, so a miss is visible the month it happens. Coverage says who is actually reporting against the cadence the office expects. Attention rules flag a stale mark, a stalled income stream, an underwater position, a high risk score or a data gap. The overview page is the answer to the office's question, with the evidence one click below it.

What you are looking at

The PE / VC Monitor is a read-only reporting layer over the family office's own record of its private investments. It takes the positions the Family Office platform already holds (cost, mark, distributions, performance) and adds the part that record never had: how each operating company is actually doing, who is reporting and who has gone dark, and a running story of what has happened to every deal.

Some of the parts worth a look:

• The operating layer keeps a small universal spine of metrics for every company (revenue, EBITDA, cash, burn, runway, headcount) and scores each against the plan the company sent, within one reporting cadence, so a monthly figure is never judged against an annual one.
• Documents become data. Every file a company sends is classified and dated from its name; the investor letters are read by a model, which proposes figures and a headline that a person then approves or rejects. Nothing it proposes reaches the book without that click.
• Funds get their own lens. A blind pool has no P&L, but it does have a portfolio: the schedule of investments is read into a holdings grid, companies down and report dates across, with the fund's own printed totals kept beside the sum of the rows.
• Capital is attributed. A commitment read off a statement is tagged with whose position it describes, so a pooled vehicle's figure can never be shown as the office's own.

How it is built

Python and Flask on PostgreSQL, server-rendered pages with Alpine.js. The monitor is deliberately read-only over the positions themselves: it reads them from the Family Office platform through an internal API and adds its own tables for documents, extracted figures, operating metrics, reviews and headlines, so the office's record of what it owns has exactly one writer.

• Extraction has priorities. Dark companies and fund holdings are read first, because they are where the office knows least; a company that reports well is read for its figures, a fund for its portfolio.
• Statements are stored as tables, not as text, period by period as the company wrote them, so a tie-out can check that revenue less costs equals the profit they printed, and a figure can be compared across reports.
• The operating spine is universal. Six metrics every company can report, scored against the company's own plan within one cadence, so companies in different industries can share one exceptions board without pretending their businesses are alike.
• Shared platform. Single sign-on with the other applications, the same database cluster, nightly backups to two object stores and a deploy on every push.
• Several hundred tests, checked by mutation, including the readers driven over statement shapes the office has actually received.

What it is, and who uses it

A family office with a few hundred private investments receives thousands of documents a year at one shared address: capital-account statements, K-1s, capital calls and distribution notices, rent rolls and monthly property packages, offering memoranda, covenant reports, legal letters, and the long email threads around all of them. Every one of those has to be recognised, renamed and filed in the right folder of the document library, and the ones that matter — a distribution cut, a covenant breach, a statement that never came — have to be noticed by someone. Done by hand it was a part-time job that was always behind.

Documents watches that mailbox. For each email it reads the message and its attachments, identifies the deal from the sender's domain, the names and aliases it knows and the folders it has seen before, works out the document type and the period it covers (from the file name first, then the subject, then the body), and proposes a destination folder and a standard name. A reviewer sees that proposal on a card, with the sentences it was read from, and approves, redirects or declines it. Only then does the file move. The same pipeline handles files dropped into a shared folder and documents returning from e-signature, so there is one registry of deals and one set of rules however a document arrives.

Because the filing is recorded as data, the office gets answers it never had before. The statement tracker lights a cell for every deal, document type and period that was actually filed, so what is missing is a query rather than a memory. Coverage asks the same question of the last six months of email. Red flags are raised from the text of what was read, each one with the sentence that triggered it, and stay open until a person resolves them. And the audit log keeps every decision, proposal and action with the person who made it.

What you are looking at

Documents is the application that watches a family office's shared investments mailbox. Sponsors, fund administrators, lenders and counsel send statements, notices and letters to one address; the app reads each one, works out which deal it belongs to, what kind of document it is and which period it covers, proposes a filename and a folder, and files it into the office's document library once a person says yes.

Some of the parts worth a look:

• A proposal, never an action. The reader proposes a destination for every attachment and every important email body; nothing moves until a reviewer approves it, and the audit log keeps the decision with the person who made it.
• Coverage is derived from what was filed. The statement tracker lights a cell when a document for that deal and period actually landed in the library, so the grid is a record rather than a checklist someone remembers to tick.
• Red flags come from the text. A distribution cut or a covenant breach is flagged with the sentence it was read from, and stays open until a person resolves it.
• Two side doors share the pipeline. Files dropped into a shared Dropbox folder and documents sent out for e-signature are routed through the same deal registry and filed into the same folders.

How it is built

Python and Flask on PostgreSQL, server-rendered pages with Alpine.js. The mailbox is read through the Microsoft Graph API and the library is SharePoint, reached through the same API; the app never holds a copy of a document longer than it takes to read it.

• Reading is a model's job; filing is a person's. A language model reads each email and attachment and proposes deal, type, period, folder and name, and every proposal carries the evidence it rests on. Nothing moves until a reviewer approves it, and the reviewer's decision is what the audit log records.
• A sandbox library beside the real one. Every automated operation is exercised against a sandbox copy of the library first, and the real library is protected by a no-break rule: existing files are never renamed, moved or deleted by the pipeline on its own.
• Deals are identified by path, not by name, because the real and sandbox libraries carry the same folder names; an operation that cannot tell which library it is in refuses.
• Cleanup and bulk operations go through a token-guarded API that moves files by content hash, so a planned reorganisation can be reviewed as a plan and replayed safely.
• Over a thousand tests, checked by mutation, including the period detector driven over the real file names the office has received, so a new labelling habit from a sponsor is caught by a test rather than by a misfiled statement.

What it is, and who uses it

The family gives through a donor-advised account at a community foundation. The family deposits into the account; the office decides each month who receives what; the foundation writes and mails the cheques and keeps the register of what actually left. So there are always two books: the office's working sheet of what it meant to give, and the foundation's register of what was paid. They disagree in ordinary ways (the register runs a month behind, a cheque is approved in one month and mailed in the next, a cheque is voided and reissued) and in the occasional way that matters.

Philanthropy reads both books and keeps them honest with each other. It never adds a gift that is paid to one that is only prepared, or either of those to a school bill that has not been paid yet; those are three different numbers and the app shows them side by side. Every cheque goes through a per-month sign-off, prepared by one person and approved by another, with the owner's comment on this cheque kept apart from the standing note on the organisation. The reconciliation compares the sheet with the register month by month, counts the newest month as pending rather than as a difference, and leaves only the genuine gaps to look at.

Tuition runs on the schools' clock, August to July, while gifts run on the calendar year, so a school year spans two of the office's yearly tabs. The app puts them back together: what each school billed for the year, what has been paid against it so far, and what is still due.

What you are looking at

Philanthropy is the office's view of the family's giving. The money moves through a giving account at a community foundation: the family deposits into it, and the foundation writes the cheques the office directs. The office keeps its own working sheet of who gets what each month; the foundation keeps the register of what actually left. This app reads both and keeps them honest with each other.

• Paid, not yet sent and billed are three different numbers, and the app never adds them together: a cheque is paid when it is on the register, prepared when it is approved but still in the drawer, and only a school ever sends a bill.
• The register lags, so the newest month is reconciled separately and said to be pending rather than shown as a difference.
• Approval is per cheque per month, with the preparer's and the owner's sign-offs and the owner's comment on this cheque kept apart from the standing note on the organisation.

How it is built

Python and Flask, server-rendered pages with a little JavaScript. The app has no database of its own for the books: it reads the office's working sheet and the foundation's register as workbooks from the office's document library, parses them on a schedule, and serves the parsed snapshot. The office's own work in the app (sign-offs, comments, sent marks, edits to the grid) is kept in a separate store, so a re-read of the workbooks never loses what was done in the app.

• The workbooks stay the source. The register is the foundation's and the sheet is the office's; the app reads them as they are written, including their total rows and their notes columns, rather than asking anyone to change how they keep them.
• Reconciliation is per month and per organisation, so a difference is located, not just reported, and a dating difference (approved one month, cleared the next) is recognised as such.
• Shared platform. Single sign-on with the other applications, backups of the edit store to object storage, and a deploy on every push.

What it is, and who uses it

A family office runs on obligations that arrive from everywhere: a lender asks for an insurance certificate, a fund sends a capital call, the accountant needs a report for the extension, the principal asks a question in a meeting. Before this app the obligations lived in inboxes and memories, and the question "who owns this, and is it done?" had no single answer.

Tasks is that answer. Anything the office owes becomes a task with owners, watchers, a due date, a priority and, where it belongs to one, a project. An email forwarded to the office becomes a task with the thread attached, and the replies keep landing on it as comments, so the history of the request lives with the work. A task can be finished but waiting for the person who asked to review or sign it off, which is the difference between "I did it" and "it is right".

The office's routines run on the same list. Weekly and monthly work is created by templates on a schedule. Meetings have an agenda built from tasks: an item not discussed carries forward to the next meeting, and an action item is a task with an owner and a date, so nothing said in a meeting is lost.

What you are looking at

Tasks is the office's shared to-do list. Work arrives from people and from email: a forwarded message becomes a task with the thread attached, and replies land on the task as comments. Each task has owners, watchers, a due date, a priority and, when it belongs to one, a project.

• Review before done. A task can be finished but waiting for review or sign-off, so the person who asked for it confirms it is right.
• Meetings run on tasks. The agenda is a list of tasks, an undiscussed item carries forward, and an action item is a task with an owner.
• Recurring work creates itself from templates on a schedule, so the weekly and monthly routines never depend on someone remembering them.

How it is built

Python and Flask on PostgreSQL, server-rendered pages with htmx and Alpine.js for the panel and the inline edits. The app reads the office's mailboxes through Microsoft Graph subscriptions and a delta poller, matches replies to the task they belong to by conversation, and stores the thread with the task.

• Email threading is by conversation, not by subject line, so a reply with a changed subject still lands on the right task, and a merged task carries its emails with it.
• The DB is canonical. A message deleted in Outlook is never deleted from a task: the task keeps the record of what was asked.
• Shared platform. Single sign-on with the other applications, backups of the database to object storage, and a deploy on every push.

What it is, and who uses it

The office owns apartment communities, shopping centres, warehouses and an office tower directly, through partnerships it controls. Each property manager sends a monthly package in its own format: an operating statement, a balance sheet, a rent roll. The office needs three answers from all of it: is each building performing, is each loan safe, and are the markets the buildings sit in getting better or worse.

Real Estate reads the buildings, loans, monthly results and rent rolls from the family-office platform, so there is one record of what the office owns. It merges each manager's statements into a running P&L and balance sheet that tie out line by line, reads the rent roll into occupancy, unit mix and lease expirations, and runs a scan that raises an alert when NOI falls, occupancy slips, coverage tightens, a loan nears maturity or a package goes stale.

The Markets half scores every US metropolitan area on public statistics: population and income growth, jobs and unemployment, wages, home prices and rents, new supply from building permits, mortgage activity, migration, walkability and natural-hazard risk. The office's own markets are marked, so a building's performance can be read against the market around it.

What you are looking at

Real Estate is the office's view of the buildings it owns directly and of the markets they sit in. It reads the buildings, loans, monthly operating results and rent rolls from the family-office platform, and adds what the asset side needs: statements merged into a running P&L, debt maturities, alerts, and a market score for every US metro.

How it is built

Python and Flask on PostgreSQL, server-rendered pages. The app shares the family-office platform's database: it reads that platform's property, loan, financial and rent-roll tables and keeps only its own alert, note, digest and market tables, so the office's record of what it owns has one writer.

• Public data, ingested on a schedule. Fifteen public sources (Census, BLS, BEA, HUD, FHFA through FRED, FEMA, IRS, CFPB, EPA, Zillow, Redfin, Apartment List and others) are fetched, crosswalked from county to metro, stored as dated metrics and scored.
• Statements are stored as tables, period by period as the manager wrote them, so a tie-out can check them and a line can be compared across months.
• Shared platform. Single sign-on with the other applications, backups to object storage, and a deploy on every push.

What it is, and who uses it

When a family office brings outside investors into its deals, those investors need the same things a fund's limited partners do: what they own, what they have put in, what they have been paid, the quarterly reports, the K-1s at tax time and the notices for capital calls and distributions. Email and shared folders handle that badly: files go to the wrong person, nobody can find last year's K-1, and there is no record of who opened what.

The portal gives each investor one sign-in and shows them only what is theirs: their investments with the contributions and distributions behind them, the deals they are in with the sponsor's updates, their documents by year, and the messages the office has sent. Investors who hold through a trust or an LLC see each of their entities.

The office runs it from the admin console: investors and their entities, deals and the updates posted to them, documents and who can see them, messages, and separate sites for separate investor groups. Every sign-in, download and change is written to an audit log.

What you are looking at

How it is built

Python and Flask on PostgreSQL, server-rendered pages. It runs as its own application with its own database and its own user table, separate from the platform the office's staff use, because the people signing in are outsiders.

• Visibility in one place. One module answers which entities, deals and documents an investor may see; every page asks it rather than writing its own query.
• Security for outsiders. Password lockout, two-factor codes with backup codes, rate limits on sign-in, strict security headers and a signed audit trail.
• Files in object storage. Documents live in cloud storage; a download is a short-lived signed link issued only after the portal checks the investor may see the file, and the download is recorded.

What it is, and who uses it

A small office running ten applications cannot have ten logins, ten user lists and ten ideas of who is allowed to see the investment book. Admin is where a person signs in once, with a password and a second factor or a passkey, and receives a signed cookie every other application trusts. It records which applications each person may open and at what role, and the other applications ask it, every few seconds, whether a session has been revoked.

It also keeps the platform's books on itself. Every call any application makes to an AI model or a data provider is logged with its cost, so the month's spend is charted against a budget by application, model and person. Every administrative action goes into an audit log whose entries are signed so that an edit or a deletion shows. Every email any application sends is logged, and the pages people actually use are counted, so an unused screen can be retired with evidence.

From here an administrator invites and deactivates people, changes their access, looks at the platform as another user to check what they see, sends announcements, edits the automated emails, and in an emergency signs everyone out of every application at once.

What you are looking at

How it is built

Python and Flask on PostgreSQL, server-rendered pages. It is the one application that owns the user table; the others hold no passwords and read a signed cookie.

• Revocation without a shared session store. Each cookie carries a generation number; bumping it, or a platform-wide sign-out time, invalidates it everywhere, and the applications poll a small state endpoint for it.
• Usage reported by the callers. Each application wraps its AI and data clients so every call posts its tokens, latency and cost here; monthly rollups keep the history small.
• Tamper-evident logs. Each audit entry carries an HMAC of its contents, so a verification pass can show whether any entry was altered.