Phony Cloud Platform - Roadmap

Overview

This roadmap is gate-driven, not date-driven. Each phase ends at a validation gate; the next phase's spend (time and money) is only unlocked when the gate is passed. Three phases build on each other:

┌─────────────────────────────────────────────────────────────────────────┐
│                    PHONY IMPLEMENTATION STRATEGY                         │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  PHASE 1: OSS WEDGE (NOW)                                                │
│  ═══════════════════════                                                 │
│  Goal: Become the best Faker alternative for PHP/Laravel                 │
│  Engine + CLI + package manager: DONE. Remaining: PHP port,              │
│  conformance suite, bundled models, Laravel integration, launch.         │
│  Revenue: $0 (community building)                                        │
│                                                                          │
│         │  GATE 1: 500 GitHub stars                                      │
│         ▼                                                                │
│                                                                          │
│  PHASE 2: CLOUD CONTROL PLANE + LOCAL-FIRST SYNC (NEXT)                  │
│  ══════════════════════════════════════════════════════                  │
│  Goal: Monetize orchestration — hosted control plane (metadata           │
│  only) + DB Sync MVP running in customer infra. KVKK/Turkey              │
│  wedge for first sync revenue.                                           │
│                                                                          │
│         │  GATE 2: $30K ARR, 5+ paying sync customers                    │
│         ▼                                                                │
│                                                                          │
│  PHASE 3: SCALE & ECOSYSTEM (LATER)                                      │
│  ══════════════════════════════════                                      │
│  Goal: Enterprise (self-hosted control plane), deferred sync             │
│  depth (CDC, PITR), ARR-triggered privacy features, more                 │
│  runtimes (signal-driven).                                               │
│  Revenue: $150K → $600K+ ARR → Exit                                      │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Status: What Is Already Built

The foundation phase is largely complete. Marking it explicitly so the rest of the roadmap reads as remaining work:

Area	Status	Notes
Rust generation engine	DONE	Five core generator types (Logic, List, Model, Statistical, Event Sequence) plus composition, in the Rust workspace
PGDL (JSON) + PEL	DONE	`phony-pgdl` crate — canonical schema format is JSON, expression language implemented
`.ngram` model format + training	DONE	`phony train` produces `.ngram` model files; `phony generate` consumes PGDL JSON
CLI `train` + `generate`	DONE	Offline, no auth required
Git-based package manager	DONE	`phony.json` manifest, MVS resolution, content-addressed store, `phony.lock`, remote release assets, `install`/`add`/`remove`/`update`/`list` — see Package Manager
Hosted package registry	KILLED	Superseded by the git-based design. No registry, no publish, no hosted search — ever, unless a gate proves otherwise

Phase 1: OSS Wedge (NOW)

Goal: Ship the Faker replacement for PHP/Laravel and reach Gate 1. Gate 1: 500+ GitHub stars, 200+ weekly Packagist downloads, featured in Laravel News or similar.

Architecture Decision: One Core, One Port, Bindings

There is exactly one implementation of Phony's semantics: the Rust core. Training, full PGDL/PEL, and the package manager live only there.

PHP gets a hand-written pure-PHP port — the single exception, because Laravel is the flagship market and composer require must work with no extension, no FFI, no binary. The port is generation-only: an .ngram model reader, a PEL evaluator, and the generators. No training, no package resolution logic (it consumes the closure the CLI resolves).
Every other language gets bindings to the Rust core, not a reimplementation: Python via a PyO3 wheel, JavaScript/TypeScript via WASM (which also enables a browser playground). Ruby is deferred.
The contract between runtimes is a cross-runtime conformance vector suite: versioned test vectors (seed + PGDL input → expected output) generated from the Rust core and run in CI against every runtime. Same seed, same output, everywhere.
Fallback posture: if byte-for-byte parity between Rust and PHP proves too costly to maintain, we retreat to portable format + per-runtime determinism (same seed is deterministic within a runtime, models portable across runtimes) — but parity is the target.

┌─────────────────────────────────────────────────────────────────────────┐
│  WHY THIS ARCHITECTURE                                                   │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  • One source of semantics → no version drift across languages           │
│  • PHP port is small (reader + PEL + generators), not a second engine    │
│  • Conformance vectors make "same data everywhere" a tested claim        │
│  • Bindings (PyO3/WASM) reuse the core → new runtimes are cheap          │
│  • WASM binding doubles as a zero-install browser playground             │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Repository Structure

┌─────────────────────────────────────────────────────────────────────────┐
│  PUBLIC REPOSITORIES (MIT Licensed)                                      │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  Rust workspace                 Engine, PGDL/PEL (phony-pgdl), CLI       │
│  ├── engine + generators       Training + generation (DONE)             │
│  ├── pkg module                Git package manager (DONE)               │
│  └── conformance/              Versioned cross-runtime test vectors      │
│                                                                          │
│  phony-php                      Hand-written pure-PHP port (Packagist)   │
│  ├── .ngram reader             Generation-only                          │
│  ├── PEL evaluator             Validated against conformance vectors    │
│  └── generators                                                         │
│                                                                          │
│  phony-laravel                  Laravel integration (Packagist)          │
│                                                                          │
│  Content packages (git, one repo each — no registry)                     │
│  ├── @phony/base               Generic generators/assets                │
│  ├── @phony/tr_TR              Turkish models (release-artifact .ngram) │
│  └── @phony/en_US              English models (release-artifact .ngram) │
│                                                                          │
├─────────────────────────────────────────────────────────────────────────┤
│  PRIVATE REPOSITORY (Proprietary)                                        │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  phonycloud/cloud               Control plane (Phase 2)                   │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Remaining Work

1.1 Conformance Vector Suite

Deliverable	Description
Vector generator	Rust binary emits versioned vectors: seed + PGDL JSON → expected output
Coverage matrix	Every generator type, PEL function, and model sampling path
Rust CI harness	Vectors run against the core on every commit
Published artifact	Vectors versioned + downloadable so any runtime can self-certify

1.2 phony-php Port

Deliverable	Description
`.ngram` reader	Load binary model files, pure PHP, no extensions
PEL evaluator	Evaluate expressions identically to the Rust core
Generators	Logic, List, Model, Statistical, Event Sequence + composition
Conformance CI	PHP port runs the full vector suite; parity is the release criterion

1.3 Bundled Models

Deliverable	Description
`@phony/tr_TR`	Turkish names, addresses, companies — plus TCKN and other TR-format generators
`@phony/en_US`	English equivalents
`@phony/base`	Locale-independent generators and assets
Release assets	Large `.ngram` models shipped as release artifacts, not git blobs

1.4 Laravel Integration

Deliverable	Description
Service provider + facade	Auto-discovery, `Phony::` facade
Factory integration	Drop into Eloquent factories
Deterministic seeding	Per-test seeds → reproducible factories in CI
Config	`config/phony.php`

1.5 Faker API Compatibility + Agent-Readable Migration

The primary "user" performing a Faker→Phony migration is increasingly a coding agent, not a human. Both deliverables are designed for that reader:

Deliverable	Description
Faker compat layer	Drop-in `fake()`-compatible API surface on top of the Phony engine — one line in `CLAUDE.md`/`AGENTS.md` should be enough to redirect an agent's `fake()` reflex to Phony
Migration guide	Mechanical, rule-based, example-mapping format (Faker call → Phony call) so an agent can apply it without judgment calls
AGENTS.md snippet	Canonical copy-paste block for consumer repos

1.6 Agent Surface (never paywalled)

Deliverable	Description
AGENTS.md	In phony-php and phony-laravel repo roots
Editor skills / snippets	Claude Code, Cursor et al. instructions
Messaging	"Agent-written tests stay reproducible — no flaky fake data"

1.7 Docs + OSS Release + Launch

Deliverable	Description
Docs site	Getting started, CLI reference, PHP API, tutorials
Packagist + crates.io + install script	`composer require`, `cargo install`, `curl \| sh`
Launch	Laravel News, Show HN, Product Hunt, r/php + r/laravel

Phase 1 Success Criteria (Gate 1):

[x] Rust engine, PGDL/PEL, CLI train + generate shipped
[x] Git-based package manager shipped
[ ] Conformance vector suite passing on Rust and PHP
[ ] phony-php + phony-laravel on Packagist
[ ] @phony/tr_TR, @phony/en_US, @phony/base published (git packages)
[ ] Faker compat layer + agent-readable migration guide
[ ] 500+ GitHub stars, 200+ weekly Packagist downloads
[ ] Featured in Laravel News or similar

Phase 2: Cloud Control Plane + Local-First Sync (NEXT)

Precondition: Gate 1 passed. Goal: First revenue from DB Sync, with a local-first architecture. Gate 2: $30K+ ARR, 5+ paying customers, <5% monthly churn.

Architecture: Local-First Cloud

The data plane (sync, anonymization, snapshots) runs in customer infrastructure — the customer's data never transits our servers.
The hosted control plane sees metadata only: schemas, PII findings, job status, audit events. It sells orchestration, visibility, and compliance reporting.
The mock API is the hosted exception — it serves synthetic data only, so hosting it creates no PII exposure.
Free tier has no hosted COGS (engine + CLI are local; no hosted workloads to subsidize).
Enterprise = self-hosted control plane (Phase 3).
Value metric for billing: connected data sources — generation volume, users, and agents are never metered.

Implementation Order

Order	Feature	Rationale
2.1	Control-plane foundation	Everything depends on this
2.2	DB Sync MVP (local-first)	The revenue feature
2.3	KVKK / Turkey wedge	First paying sync customers
2.4	Mock API (read-only, hosted)	Synthetic-only, unique feature
2.5	Snapshots (local-first)	Ephemeral envs; agent story
2.6	Language bindings (post-Gate 1, demand-driven)	PyO3 wheel, WASM + playground

2.1 Control-Plane Foundation

Deliverable	Description
Auth + orgs + projects	Registration, OAuth, teams, roles, API keys
Billing	Stripe; plans gated by connected data sources
Agent enrollment	Customer-infra agent registers with control plane; outbound-only connection
CLI cloud commands	`phony login`, `phony whoami`, agent bootstrap
MCP server	Control-plane MCP surface for coding agents (free tier included — agent surface is a distribution channel, never paywalled)

2.2 Database Sync MVP (Local-First)

Deliberately narrow: MySQL → staging, full sync, heuristic PII detection, manual + daily scheduled runs. Depth comes later.

Deliverable	Description
MySQL connector	Runs in the customer-infra agent; credentials never leave customer infra
Schema analysis	Introspection, FK detection — schema metadata reported to control plane
Heuristic PII detection	Column-name + pattern heuristics; findings surfaced in dashboard
Full sync + anonymize	Complete table copy with transforms, in customer infra
Manual + daily runs	Trigger from dashboard/CLI; simple daily schedule
Sync dashboard	Connection wizard, transform rules, run history — metadata only

Explicitly deferred out of the MVP: PostgreSQL, incremental sync, CDC, PITR, cross-database subsetting (see Phase 3).

2.3 KVKK / Turkey Wedge

The first paying sync customers are most likely Turkish mid-market teams: KVKK creates the compliance pressure, Tonic has no meaningful Turkish presence, and Phony already has the local assets.

Deliverable	Description
TCKN + TR formats	Valid-checksum TCKN, TR phone/IBAN/plate generators (ships in Phase 1 packages; surfaced as sync transforms here)
tr_TR model quality	Production-grade Turkish names/addresses/companies
KVKK report pack	Anonymization evidence report per sync run, in Turkish, mapped to KVKK terminology
TR go-to-market	Turkish content, local case study, Laravel TR community

2.4 Mock API (Read-Only, Hosted Exception)

Deliverable	Description
PGDL → REST endpoints	Deterministic, seed-based responses; synthetic data only
Hosting	Subdomain routing, CORS, per-tier rate limits
Pagination	Deterministic cursor + offset paging

Stateful mock (POST/PUT/DELETE, webhooks, latency/error simulation) is deferred to Phase 3 — read-only must prove valuable first.

2.5 Snapshots (Local-First)

Deliverable	Description
Snapshot create/restore	Anonymized DB captures, stored in customer storage (S3-compatible)
Scheduling + retention	Control-plane orchestrated
Ephemeral environments	Spin up a prod-like, PII-free DB per branch/test run — "give your coding agent a prod-like DB it can't leak PII from"

Incremental snapshots and point-in-time restore are deferred to Phase 3.

2.6 Language Bindings (Post-Gate 1, Demand-Driven)

No reimplementations — bindings to the Rust core, certified by the same conformance vectors:

Deliverable	Description
Python wheel	PyO3 binding, `pip install phony`; pytest fixtures
JS/TS WASM	npm package; Node + browser
Browser playground	WASM-powered try-it-now on phony.cloud — zero install

Phase 2 Success Criteria (Gate 2):

[ ] Internal production use (dogfooding)
[ ] 10+ beta customers using sync
[ ] 5+ paying customers (first ones likely via the KVKK wedge)
[ ] $30K+ ARR
[ ] <5% monthly churn
[ ] Zero customer data touching hosted infrastructure (mock API synthetic-only excepted)

Phase 3: Scale & Ecosystem (LATER)

Precondition: Gate 2 passed. Goal: Enterprise readiness, sync depth, exit preparation.

3.1 Enterprise Features

Category	Features
Deployment	Self-hosted control plane (the enterprise product), VPC peering, air-gapped
Auth	SSO (SAML, OIDC), SCIM provisioning, RBAC, IP allowlisting
Compliance	SOC2 Type II, GDPR docs, KVKK docs, HIPAA BAA, data residency
Support	99.9%+ SLA, dedicated success manager

3.2 Sync Depth (Deferred from Phase 2)

Feature	Notes
PostgreSQL support	Second connector, type mapping, COPY bulk load
Incremental sync	Timestamp/checksum-based
CDC	Log-based change capture — deliberately deferred; heavy for a solo founder, only justified by paying demand
PITR	Point-in-time restore on snapshots — same posture
Stateful mock API	Mutations, webhooks, latency/error simulation

3.3 Additional Runtimes (Signal-Driven)

Decision signals: GitHub issues, paying customers asking, market gap.

Runtime	Priority	Approach
Ruby	Deferred	Binding (magnus/FFI) if Rails demand materializes — not a port
Go	Future	Binding (cgo)
More locales	Ongoing	New `@phony/<locale>` git packages — community-contributable

There is no hosted package registry on any horizon: packages stay git-based (decision record). Registry analytics, badges, private-package hosting are all dead with it — private packages are just private git repos.

3.4 Advanced Privacy Features (ARR-Triggered, Cloud Platform)

These are cloud-platform features — data-plane capabilities orchestrated by the control plane, not OSS engine features. Each unlocks only at its ARR trigger:

ARR Trigger	Features
$150K+	Differential Privacy: Mathematical privacy guarantees (ε-differential privacy), Laplace/Gaussian mechanisms, GDPR/HIPAA compliance certification
$200K+	Geo-Aware Generation: Lat/long fuzzing with k-anonymity, HIPAA Safe Harbor address generation, population-aware postal code truncation
$250K+	Structured Data Masks: JSON path masking, XML XPath masking, regex capture group transformation, HTML content redaction
$300K+	Format-Preserving Transformation: Character scramble (email, phone), credit card masking (Luhn-valid), SSN/ID format preservation
$400K+	Database subsetting, NER-based PII detection, automated data discovery
$600K+	Unstructured de-identification, document redaction, image/PDF anonymization
$1M+	Guided redaction workflows, expert determination support, compliance audit reports

3.5 Statistical & ML Features (ARR-Triggered, Cloud Platform)

ARR Trigger	Features
$300K+	Distribution Learning: Auto-detect distributions from source data, histogram matching, percentile preservation
$400K+	Correlation Preservation: Learn and preserve multi-column correlations, covariance matrix replication
$600K+	AI Synthesizer: VAE-based deep learning for high-fidelity data synthesis, automatic relationship detection

Phase 3 Success Criteria:

[ ] $600K-1M+ ARR
[ ] 300+ paying customers
[ ] SOC2 Type II certified
[ ] At least 2 enterprise customers ($5K+/mo) on self-hosted control plane
[ ] At least 1 binding runtime shipped (if demand)
[ ] Exit-ready metrics

Dependency Graph

PHASE 1: OSS WEDGE
══════════════════════════════════════════════════════════════════════════

  Rust core (engine + phony-pgdl + CLI + pkg)          [DONE]
  │   ├── train / generate
  │   ├── git package manager (phony.json, phony.lock)
  │   └── .ngram model format
  │
  ├──▶ conformance/ vector suite  ──────────────┐
  │                                             │ certifies
  ├──▶ phony-php (pure-PHP port) ◀──────────────┘
  │        │
  │        └──▶ phony-laravel (facade, factories)
  │
  ├──▶ @phony/base, @phony/tr_TR, @phony/en_US (git content packages)
  │
  └──▶ Faker compat + agent migration guide + AGENTS.md
           │
           ▼
       OSS LAUNCH ──▶ GATE 1: 500 stars

══════════════════════════════════════════════════════════════════════════

PHASE 2: CONTROL PLANE + LOCAL-FIRST SYNC
══════════════════════════════════════════════════════════════════════════

  Control plane (hosted, metadata only)
  │   ├── auth / orgs / billing (connected data sources)
  │   ├── MCP server (agent surface, free)
  │   └── dashboards (schema, PII findings, run history)
  │
  ├──▶ Customer-infra agent (data plane)
  │        ├── DB Sync MVP (MySQL, full, heuristic PII, daily)
  │        └── Snapshots (customer storage)
  │
  ├──▶ KVKK wedge (TCKN transforms + KVKK report pack)
  │
  ├──▶ Mock API (hosted exception, synthetic-only, read-only)
  │
  └──▶ Bindings: PyO3 wheel, WASM + browser playground (post-Gate 1)
           │
           ▼
       GATE 2: $30K ARR, 5+ paying

══════════════════════════════════════════════════════════════════════════

PHASE 3: SCALE (signal- and ARR-driven)
══════════════════════════════════════════════════════════════════════════

  Self-hosted control plane (Enterprise)
  Sync depth: PostgreSQL → incremental → CDC → PITR
  Stateful mock API
  ARR-triggered privacy + statistical ladders
  Additional runtimes (Ruby et al. — bindings only)

CLI Command Reference

The phony CLI is a unified tool for both offline (free) and cloud (paid) operations.

┌─────────────────────────────────────────────────────────────────────────┐
│                    UNIFIED CLI (Single Binary: phony)                    │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  OFFLINE COMMANDS (Free, MIT Licensed, No Auth Required)                 │
│  ═══════════════════════════════════════════════════════                 │
│                                                                          │
│  $ phony train input.txt -o model.ngram        # Train a model           │
│  $ phony train data.csv --column name          # Train from CSV column   │
│  $ phony generate schema.pgdl.json             # Generate from PGDL JSON │
│  $ phony info model.ngram                      # Show model metadata     │
│  $ phony validate model.ngram                  # Validate model format   │
│  $ phony stats model.ngram                     # N-gram statistics       │
│                                                                          │
│  PACKAGES (git-based — no registry, no publish)                          │
│  ══════════════════════════════════════════════                          │
│                                                                          │
│  $ phony install                               # Resolve + fetch closure │
│  $ phony add github.com/acme/geo-tr@v1         # Add a dependency        │
│  $ phony remove @acme/geo-tr                   # Remove a dependency     │
│  $ phony update                                # Update within constraints│
│  $ phony list                                  # List resolved packages  │
│                                                                          │
│  CLOUD COMMANDS (Requires: phony login)                                  │
│  ════════════════════════════════════════                                │
│                                                                          │
│  $ phony login / logout / whoami               # Auth + identity         │
│  $ phony sync                                  # Trigger sync (runs in   │
│  $ phony sync --status                         #  customer infra)        │
│  $ phony snapshot create --name "v1.2"         # Anonymized snapshot     │
│  $ phony snapshot restore v1.2                 # Restore (ephemeral env) │
│  $ phony mock deploy                           # Hosted mock API         │
│                                                                          │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  SIMILAR TO:  gh (GitHub CLI)    → gh auth login / gh repo create        │
│               vercel             → vercel login / vercel deploy          │
│                                                                          │
│  BENEFIT:     Single tool for entire workflow                            │
│               Offline-first (train/generate/install never need auth)     │
│               Progressive disclosure (cloud unlocks with login)          │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

Timeline Summary

Gates, not dates:

Phase	Trigger to Start	Exit Gate
Phase 1	Now (engine already built)	500+ GitHub stars, 200+ weekly Packagist downloads
Phase 2	Gate 1 passed	$30K+ ARR, 5+ paying, <5% churn
Phase 3	Gate 2 passed	$600K-1M ARR, enterprise-ready, exit-ready

Milestone Checkpoints

Checkpoint	Deliverable
P1.a	Conformance vector suite green on Rust
P1.b	phony-php passes conformance suite
P1.c	@phony/tr_TR + @phony/en_US + @phony/base published
P1.d	Laravel integration + Faker compat + migration guide
P1.e	OSS launch → Gate 1
P2.a	Control plane live (auth, billing, agent enrollment, MCP)
P2.b	DB Sync MVP: MySQL full sync in customer infra
P2.c	KVKK report pack; first Turkish paying customer
P2.d	Mock API read-only + snapshots
P2.e	Gate 2 ($30K ARR)

Phony Cloud Platform - Roadmap ​

Overview ​

Status: What Is Already Built ​

Phase 1: OSS Wedge (NOW) ​

Architecture Decision: One Core, One Port, Bindings ​

Repository Structure ​

Remaining Work ​

1.1 Conformance Vector Suite ​

1.2 phony-php Port ​

1.3 Bundled Models ​

1.4 Laravel Integration ​

1.5 Faker API Compatibility + Agent-Readable Migration ​

1.6 Agent Surface (never paywalled) ​

1.7 Docs + OSS Release + Launch ​

Phase 2: Cloud Control Plane + Local-First Sync (NEXT) ​

Architecture: Local-First Cloud ​

Implementation Order ​

2.1 Control-Plane Foundation ​

2.2 Database Sync MVP (Local-First) ​

2.3 KVKK / Turkey Wedge ​

2.4 Mock API (Read-Only, Hosted Exception) ​

2.5 Snapshots (Local-First) ​

2.6 Language Bindings (Post-Gate 1, Demand-Driven) ​

Phase 3: Scale & Ecosystem (LATER) ​

3.1 Enterprise Features ​

3.2 Sync Depth (Deferred from Phase 2) ​

3.3 Additional Runtimes (Signal-Driven) ​

3.4 Advanced Privacy Features (ARR-Triggered, Cloud Platform) ​

3.5 Statistical & ML Features (ARR-Triggered, Cloud Platform) ​

Dependency Graph ​

CLI Command Reference ​

Timeline Summary ​

Milestone Checkpoints ​