π Welcome, Developers! β
This section is for the engineering team and anyone brave enough to peek under the hood.
Speed is our default. Precision is our discipline.
We move fast by mastering our tools, automating ruthlessly, and sticking to a consistent stack that scales. No trend-chasing. Just results.
π§± Tech Stack Overview β
A consistent stack means faster onboarding, better collaboration, and fewer WTFs at 2AM. Until we hit a real limitation (rare), we stick to what works β and we learn it deeply.
Hereβs what powers our operation:
- Nuxt β The frontend framework we build everything on.
- Nitro β Nuxtβs server engine. Used for APIs, microservices, and scheduled jobs.
- Firebase β Auth, Firestore, Storage, Functions, Hosting. Out of the box and battle-tested.
- TypeScript β Static typing across the entire stack. Strict mode. No exceptions.
- Nx Monorepo β Manages our monorepo, dependency graph, caching, and CI workflows.
- Stripe β Payments, subscriptions, billing logic.
- Arktype β Runtime validation with static inference. The brains behind our form schemas.
π₯ Frontend β
- Nuxt β Fast, flexible, and SSR/SSG-friendly.
- Vue 3 β Composition API all the way.
- Pinia β For global state when needed. Usually not needed, thanks to Nuxtβs
useState(). - Arkform β Our custom-built form library. Small, powerful, fully typesafe.
- Arkfire β Internal Firebase Nuxt module. Handles connection, emulator setup, and provides a typed Firestore ORM.
π§ Backend β
- Firebase β Auth, Firestore, Storage. Scales with us and gets out of the way.
- Nitro β Used for all server-side logic: API routes, microservices, schedulers.
- Custom Services β Email, PDF generation, job scheduler, etc. Modular, isolated, and growing steadily.
βοΈ Tooling β
- Nx β Manages all projects, libraries, builds, and tests from a single workspace.
- TypeScript β Strict mode. Full send.
- Vitest / Cypress β For unit and end-to-end testing. Nuxt-native, fast, and modern.
- ESLint + Prettier β Enforced. Automatically. Always.
Style β
Return types for the win. We have tools built around using them effectivly, giving us rich and predictable errors.
π Docs Etiquette β
- Keep things clear and concise.
- Write like the next dev has no context β because they probably donβt.
- If you fix a βWTFβ moment, document it. Future-you will thank you.
- Keep sections organized β treat these docs as a living, evolving resource.
- Full documentation for internal libraries, patterns, and edge cases lives in the Libs section.
- Undocumented code = technical debt. Donβt leave it behind.