FOR BUILDERS
Before you prompt an AI to add a feature, know where it lives — edge, app, data, or external. gofyio is a real multi-brand control plane; this is the map.
RUNTIME ARCHITECTURE
Edge, apps, data, AI and external providers — hover any node, then play a flow to see real request paths.
VIBECODER SYSTEM DESIGN
Ask these before prompting — gofyio is built around the answers.
If a rule, setting, or tenant boundary appears in multiple places, design it once and enforce it everywhere.
GOFYIO EXAMPLE
Tenant isolation lives in basefyio helpers — every API query scopes by companyId. Never duplicate isolation logic in a handler.
Anything that might change at launch time belongs in config or secrets — not scattered literals.
GOFYIO EXAMPLE
Platform decisions (orchestration v1, dashboard access, GX10 runtime) live in packages/config/platform-decisions.json — not buried in code.
Edge routes traffic, apps orchestrate, data persists, external providers integrate. Put each concern in the right box.
GOFYIO EXAMPLE
DNS record creation is an API → Cloudflare integration — not a dashboard concern. The dashboard triggers the pipeline; the API talks to providers.
Production systems need retries, idempotency, and dead-letter queues — not just the success screenshot.
GOFYIO EXAMPLE
go-live-36 steps are idempotent with BullMQ retries and a DLQ. A failed DNS step can retry without double-provisioning.
Separate public visitors, tailnet operators, and secret-bearing services. Least privilege by default.
GOFYIO EXAMPLE
Admin dashboard is Tailscale-only; secrets never appear in Settings — they resolve via envfyio/Infisical at runtime.
NEXT STEPS
Create a brand, run the 36-step pipeline, and watch these systems work together in the dashboard.
Runbooks: deploy · go-live-e2e · backup-restore · incident — in the monorepo docs/runbooks/