Technical Architecture
Version: 1.0 foundational
Scope: Mandatory architecture for FRX Studios products.
General Principle
FRX uses modern, scalable technologies with the lowest reasonable maintenance cost.
The architecture should serve a small product at the beginning, while allowing it to grow later.
Core rule: do not add a new service or layer unless it solves a real problem.
Mandatory Architecture
| Layer | Technology | Role |
|---|---|---|
| Website | Cloudflare Pages | Company sites and static frontends |
| API | Cloudflare Workers | APIs, backend tasks, and lightweight functions |
| Database | Supabase PostgreSQL | Core data, accounts, rooms, content, leaderboards |
| Auth | Supabase Auth | Authentication and user management |
| Storage | Cloudflare R2 | Files, images, audio, and attachments |
| CDN / Domain | Cloudflare | Domain, performance, protection, and distribution |
| Cloudflare Email Routing + Gmail / Pro Provider | Official email and routing | |
| Client | Flutter + Riverpod + GetX + Hive | Mobile and web apps, state, and cache |
| Analytics | Firebase + GA4 + Cloudflare Analytics | Usage and performance measurement |
| Crashes | Firebase Crashlytics | Crash reporting |
| Payments | Paddle + App Stores | Payments and purchases |
| Documentation | Markdown + GitHub | Documentation and versions |
| Wiki / PM | Notion | Internal knowledge and project management |
| Design | Figma | Design and UI work |
| AI Coding | Claude Code | AI-supported development |
Product Structure Pattern
Products should be organized by features, not only by file type.
Each feature should keep its screens, services, state, and tests as clear as possible.
Initial example:
text
features/
gameplay/
auth/
multiplayer/
profile/
store/
analytics/Blur Guess as Reference
Blur Guess uses:
- Flutter for the client.
- Cloudflare Workers for the API.
- Supabase for accounts, data, and Realtime.
- Durable Object for multiplayer matchmaking.
- R2 for files such as voice notes.
- Firebase, GA4, and Cloudflare Analytics for measurement.
- Crashlytics for crashes.
- Gemini for dynamic content and stories.
Any new product should start from this logic, not from a random new architecture.
Scaling Rules
Technical scaling should happen only when there is a clear reason such as:
- real load increase.
- security need.
- lower operating cost.
- complexity harming maintenance.
- a new product that needs logical separation.
Premature scaling without need adds burden to a small team.