Where Things Stand

This page is the platform’s status at a glance. It is deliberately blunt, because the gap between what the founding documents describe and what runs today is large, and every planning decision depends on knowing exactly where that gap falls.

Status by component

Component	Status	In one sentence
Web display tier	Shipped	Forum, polls, accounts, moderation, editorial and a full JSON API all work
Mobile client	Shipped	Five tabs and a full auth stack against the real API
Desktop client	Partial	A complete, polished analytics client — connected to a mock server
Worker tier	Not built	Two lines of README
Docs site	Shipped	This site
Subscriptions and billing	Not built	No plan, subscription, entitlement or usage table exists
Data ingestion	Not built	Nothing gathers anything
Regulatory and licensing position	Not built	No legal entity, no licence application, no counsel engaged and no compliance function

Status by business line

Demostatics is now positioned as an investment company running four lines of business at once. Only the first has any code behind it.

#	Line	Status	Where it stands
1	Data and intelligence	Planned	The platform surfaces exist — Reports, Database, the API, both clients — but nothing gathers data and nothing is sold
2	Investment advisory	Not built	No implementation of any kind in any repository
3	Discretionary management	Not built	No implementation of any kind in any repository
4	Proprietary trading	Not built	No implementation of any kind in any repository

Lines 2, 3 and 4 are regulated activities, which is what the regulatory row above is about. See Business Model and Regulatory Posture.

The consequence for this page is that the platform is no longer only a product. The same pipeline is meant to feed paying subscribers, the firm’s own advisory calls, its managed portfolios and its own trading book — so every component in the first table is both product and internal infrastructure, and Not built now costs four businesses rather than one.

What actually works today

Run demostatics-web locally and you get a real, working application:

• Registration, login, email verification, password reset, profile editing
• A forum with communities, threaded comments, search, and three sort orders
• Polls with options, voting that moves rather than duplicates, and comments
• Role-based moderation with bans, and a live staff roster with presence
• Editorial news and About Us articles by category
• A Reports listing with a geographic and category filter cascade, exportable to Excel, Word, CSV and JSON
• A Database listing of latest values with the same filters
• A complete JSON API covering all of the above, with a test suite covering it

Point the mobile app at it and all of that works from a phone.

Run the desktop client against its bundled mock server and you get a dockable analytics workspace: live charts with downsampling, curve fitting, descriptive statistics, correlation matrices, a composite risk score, threshold alerts with desktop notifications, an offline cache, hardware-profiled render quality, a command palette, and a streaming AI assistant.

That is a substantial amount of working software.

What does not work

Nothing gathers data. The entire ingestion, processing and structuring pipeline is unbuilt. The reports and database_items rows come from local seeders.

There are no numbers. database_items.value is a text column holding display strings. There is no history table anywhere. So there are no charts over real data, no statistics, no thresholds and no alerts against anything Demostatics produced.

There is nothing to buy. No plan, feature, subscription, entitlement grant or usage table exists on the server of record, and there is no tier column on users. The entire tier-and-feature model lives in Rust, against a mock.

The two clients cannot meet. They do not share an account, an entitlement model, a dataset identifier namespace, or a data shape. See The Two Contracts.

Nothing is reconstructible after the fact. reports carries published_at and database_items carries measured_at — one date column each, no source, no method, no method version and no revision history. That was a display detail while the platform only displayed. It is a record-keeping requirement now that advisory calls and trades may be made on these figures, and it is cheap to add before the Phase 2 tables exist and expensive after.

What is blocking deployment right now

Three of the five engineering blockers below are configuration rather than code, which makes them cheap to fix and easy to forget. The sixth row is not an engineering problem at all.

Blocker	Effect	Detectable by
Mail is written to a log file	Every new signup is stranded unverified, and the verified tier gates every write plus Reports and Database	GET /api/v1/health → can_register: false
No supervised queue worker	Jobs are accepted and never run — invisible until the first payment webhook	GET /api/v1/health → queue: "requires_worker"
The scheduler may not be installed	The daily token prune never runs	Nothing verifies it
No TLS	Bearer tokens travel unencrypted in the default configuration	Nothing
No worker tier	Reports and Database have no data producer	Nothing
No entity, licence or counsel	Blocks business lines 2, 3 and 4 entirely. Does not block deploying or selling the data platform	Nothing

Licensing blocks the business, not the build

The distinction matters and is easy to blur. The data platform can be deployed, populated and sold to subscribers with none of the licensing work finished — the five engineering blockers are the only things standing between today and a live line 1. What licensing blocks is advisory, discretionary management and proprietary trading: none of those can take a client or a position until the entity and the permissions exist. Where exactly the boundary between selling data and giving advice falls is a question for counsel, not for this page.

It is also, by a wide margin, the longest lead time on this list — months to years against days or weeks for everything above it. It is the only blocker here that no amount of engineering shortens, which is why it starts now rather than when the platform is finished. See Regulatory Posture.

The health endpoint was built for exactly this

GET /api/v1/health reports world_store, can_register and queue because each is a dependency whose absence is otherwise silent — the API looks healthy while an entire tier is dead. Check it first on any deployment.

See Deployment Readiness for the full checklist.

What comes next

The roadmap runs ten phases. The short version:

Phase	What it delivers	Why it is where it is
0	Make it deployable	Nothing below is safe or testable without it
1	Settle the contracts on paper	One week, no code. The cheapest phase and the one that prevents the most rework
2	Numeric time series, from source	The technical unlock for the entire product
3	Entitlement and web billing	First revenue, with no store commission
4	The data product on mobile	The app becomes worth paying for
5–8	Platform, IAP, alerts, device linking	Additive, each easier because the phase before it built what it needs
9	Money movement	No longer conditional. Mandatory for line 3, and gated on licensing rather than on engineering

The roadmap’s own recommendation still holds for the software: Phases 0–4 are the smallest coherent thing that is genuinely useful. Numeric data with history, browsable and charted, behind a working paywall, on a real deployment, sold from the web. Everything after that is additive.

What changed is the ordering around it. Licensing no longer sits at the end of the list waiting for the platform to be finished — it starts immediately and runs in parallel with Phase 0, because it is the long pole and nothing engineering does makes it shorter. Two tracks, not one: build the platform, and start the licensing work on day one of it.

Starting the licensing work is not the same as designing the money layer

A half-designed money schema is a liability the day it merges rather than the day it is used. Design the money layer against a real licence and a real custodian, not against a guess about what they will require.

→ Roadmap · Regulatory Posture

The honest scope

Roughly 9–18 months for one full-stack engineer across three languages and three repositories, plus legal, two store accounts, a licensed financial partner, and a worker backend that does not exist in any of these repos.

That estimate covers the platform, which is line 1. It does not include the licensing lead time for lines 2, 3 and 4, which runs alongside it and is measured in months to years.

Next

• How It Works — the architecture in one page
• Business Model — the four lines and what each requires
• Regulatory Posture — licensing, conflicts and record-keeping
• Open Questions — decisions that block work