Who It Is For
Demostatics has three distinct audiences: the institutions that buy statistical risk intelligence, the clients the firm intends to advise and to manage capital for, and the community that produces and validates part of it.
Target customers
Section titled “Target customers”The pitch deck names exactly four segments. These are the customers of line 1 — the data and intelligence business. See Business Model.
| Segment | What they need it for |
|---|---|
| Investors and financial analysts | Risk-weighted context for allocation decisions |
| Risk assessment professionals | Consistent regional risk comparison |
| Research institutions | Structured longitudinal data across domains |
| Policy and strategy teams | A unified view of conditions they must plan around |
Clients, as distinct from customers
Section titled “Clients, as distinct from customers”The founder decision to operate as an investment company adds two further audiences, neither of which buys data. Both are Planned — no code of any kind exists for either.
| Audience | Line | What the relationship is | Status |
|---|---|---|---|
| The four segments above | 1 | Buys structured data, risk views, reports, API access | Planned |
| Advised clients | 2 | Receives recommendations, research, model portfolios, signals | Planned |
| Managed clients and fund investors | 3 | Hands over capital for the firm to manage on their behalf | Planned |
The distinction matters more than the wording suggests. A data subscriber is a customer: the firm sells a product, the customer decides what to do with it, and the relationship ends at the contract. An advised or a managed client is owed regulatory obligations — suitability, conflict management, record-keeping, and in line 3 the handling of someone else’s money. Those duties do not arise from the contract; they arise from the licence, and they cannot be contracted away.
The same figure can therefore reach all three audiences, but it carries a different weight each time. See Business Model for the four lines and Regulatory Posture for what each one requires.
The compliance function does not exist
Section titled “The compliance function does not exist”Lines 2 and 3 cannot be served without one, and there is none today: no compliance officer, no written policies, no counsel engaged, no legal entity holding a licence. Not built.
This is a hiring and licensing question, not an engineering one. No amount of work in these repositories produces it, and it has the longest lead time of anything on the plan. Nothing written here is legal advice, and qualified counsel is required in every jurisdiction the firm operates in or serves clients from before any of it becomes a plan. See Regulatory Posture.
Founders
Section titled “Founders”demostatics-web/README.md names two founders:
- Fikret Güney Ersezer
- Emre Tezsezen
The GitHub organization is github.com/Demostatics. The public contact address is
admin@demostatics.com.
Roles inside the product
Section titled “Roles inside the product”demostatics-web implements five roles, backed by spatie/laravel-permission. New
registrations get user automatically. Shipped.
| Role | What it can do |
|---|---|
user | Post, comment, vote, read everything their verification level allows |
moderator | Everything a user can, plus banning plain users |
editor | Curates editorial articles and the About Us surface |
technical_staff | Maintains the platform; listed on the public staff roster |
admin | Everything, including banning anyone who is not an admin |
The entire moderation rule is one method — User::hasHigherPermissionsThan(). A moderator
outranks a plain user; an admin outranks anyone who is not an admin; everything else is
false. Both the web and API moderation controllers and all three policies consult it, so
the rule exists exactly once.
A regulated firm needs roles this enum has no counterpart for — sign-off on what the firm
says in public, oversight of advice given to clients, and access separation between the
data, advisory and trading functions — and naming them is a matter for counsel rather than
for this page. app/Models/UserRole.php defines exactly the five cases above, and the
permission model has one axis: whether you outrank someone. Not built.
The governance model
Section titled “The governance model”The community structure described in the policy pages is more elaborate than what the code implements, and the difference is worth stating.
Described. A Moderation Board composed of editors, moderators and technical staff, whose members are invited through a community-driven nomination and selection process. Users discuss procedures in the forums, and where a majority agrees by vote, the technical staff adapt the platform accordingly.
Implemented. Roles, bans, polls with voting, threaded comments, and a public staff roster (the “Authorized Services” panel listing admins, technical staff, editors and moderators plus a live online count). Shipped.
Not implemented. The nomination and selection process, the binding link between a poll result and a platform change, and any invitation mechanism for authoritative contributors.
See Moderation, Forum Rules and About Moderators for the policy as written.
Who builds it
Section titled “Who builds it”One person, across three languages and five repositories, plus whatever help arrives. The roadmap’s own scoping is blunt about what that means:
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.
The failure mode it warns about is not lateness but fragmentation — six half-built subsystems each blocked on a different missing prerequisite. Its recommendation is to treat Phases 0–4 as the smallest coherent thing that is genuinely useful, and to resist starting anything after them.
- Where Everything Lives — the five repositories
- Where Things Stand — what one engineer has actually built