Inside Jaspero's Engineering Stack: The Tools, Frameworks, and Decisions Behind Every Product We Ship

What is Jaspero's default technology stack?

Jaspero's default stack is SvelteKit for web frontends, Firebase (Firestore, Auth, Cloud Functions, Hosting) for the backend, React Native for cross-platform mobile apps, and Postgres or BigQuery for workloads that Firestore handles poorly. TypeScript is used end to end across all four layers.

This is a default, not a mandate. It exists because a small team that repeats the same architecture across projects gets faster at it: the same auth patterns, the same deployment pipeline, the same debugging instincts. When a client arrives with an existing Next.js codebase, a Node API on AWS, or a Flutter app, we work inside what they have rather than proposing a rewrite. The default is what we choose when the choice is genuinely ours.

The value of a written-down default is that every deviation becomes a conscious decision with a stated reason. If a project ships on Postgres instead of Firestore, there is a specific workload that drove it, usually analytical queries or reporting, and that reason gets recorded so the next engineer to open the repo understands the shape of the system before reading a line of code.

• • Web: SvelteKit with TypeScript, deployed to Firebase Hosting or Cloud Run
• • Backend: Firestore, Firebase Auth, Cloud Functions, Cloud Storage
• • Mobile: React Native, shared TypeScript types with the web and backend
• • Analytics and reporting: BigQuery, with Postgres for relational or transactional workloads
• • CMS: JMS, our own open source content management system, for content-driven sites

Why SvelteKit for the web layer?

We default to SvelteKit because it produces smaller client bundles than React-based frameworks, its routing and data loading model is simpler to teach and review, and its prerendering, SSR, and CSR modes can be mixed per route. For content-heavy marketing sites and data-heavy dashboards alike, that flexibility maps cleanly onto real requirements.

The per-route rendering control matters more in practice than raw benchmark numbers. A marketing page prerenders at build time and serves as static HTML. A logged-in dashboard renders on the client with a Firestore listener. A product page that needs fresh data and SEO renders on the server. All three live in the same codebase with the same components, and the decision is a single export per route rather than an architectural fork.

The honest trade-off is ecosystem size. React has more third-party component libraries, more Stack Overflow answers, and a much larger hiring pool. On projects where a client's internal team will inherit the codebase and that team writes React, we recommend Next.js instead. We have written a direct comparison of the two for teams making that call, and our SvelteKit scaling and SEO posts cover the patterns we use once a SvelteKit project outgrows a handful of routes.

Why Firebase and Firestore as the default backend

Firebase removes an entire category of work from early-stage projects: authentication, real-time data sync, file storage, server-side functions, and hosting arrive as one integrated platform with no servers to provision. For products where time to first working version matters more than infrastructure control, that trade is almost always worth making.

The parts that pay off repeatedly are Firebase Auth, which handles email, phone, and social providers plus custom claims for role-based access, and Firestore's real-time listeners, which make live dashboards and chat-like features trivial instead of requiring a WebSocket layer. Security rules push authorization down into the database, so a mobile client and a web client enforce the same access logic without duplicating it in two API layers.

The costs are real and specific. Firestore charges per document read, so a badly modeled collection turns a dashboard refresh into thousands of billable reads. Queries are limited: no joins, no aggregations beyond counts, no full-text search without an external index. Composite indexes have to be declared ahead of time. We plan for these constraints during data modeling rather than discovering them in a billing alert, and we have written up our Firestore modeling and cost-control patterns in detail.

When we move workloads off Firestore to Postgres or BigQuery

We move a workload off Firestore when it needs analytical queries, multi-table joins, or reporting across large date ranges. Those are the three patterns Firestore charges the most for and serves the worst. Operational data stays in Firestore; analytical and relational data moves to BigQuery or Postgres.

The usual pattern is a streaming export from Firestore into BigQuery, with dashboards and business intelligence queries running against BigQuery instead of the live application database. A BI dashboard aggregating a year of orders is a single BigQuery scan costing cents. The same aggregation in Firestore means reading every order document, and the cost scales linearly with the business. Postgres enters the picture when the domain is genuinely relational: inventory with strict consistency requirements, financial ledgers, or anything where a transaction has to span several entities atomically.

The decision point is not project size, it is query shape. A platform with a million users and simple key-based lookups is a fine Firestore workload. A platform with ten thousand users and a reporting screen that filters across six dimensions is not. We look at the queries the product actually needs before deciding where the data lives.

How the mobile layer fits: React Native and shared contracts

React Native is our default for mobile because it lets one team ship iOS and Android from a single TypeScript codebase that shares data models, validation logic, and Firebase SDK usage with the web app. For products where the mobile app is a client for the same backend as the web app, the duplication savings are substantial.

The architectural discipline that makes this work is keeping the data contract in one place. Firestore document shapes, Cloud Function request and response types, and shared enums live in a package both the web and mobile apps import. When a field changes, TypeScript fails the build in every consumer rather than silently breaking a screen in production. We have written about the performance patterns behind this, including minimizing bridge traffic and structuring state for apps at consumer scale.

React Native is not the answer for everything. Apps built around heavy real-time graphics, deep platform-specific hardware access, or extreme frame-rate sensitivity are better served natively. Most business applications, marketplaces, and consumer products are not in that category.

The decisions that matter more than the stack

The stack choice matters less than four decisions that shape every project: where the boundaries between systems sit, how data contracts are versioned, how authentication and authorization propagate across services, and what gets automated in the deployment pipeline. Teams that get these right survive a framework change. Teams that get them wrong struggle regardless of framework.

Boundaries and contracts are where multi-system products succeed or fail. A platform with a customer portal, an admin panel, a partner dashboard, a mobile app, and a BI layer has five consumers of the same data, each with different access rights and refresh needs. Defining shared models and event flows explicitly, rather than letting each surface query the database its own way, is what keeps a four-year engagement maintainable. The same applies to auth: every system needs a stated trust boundary, and service-to-service calls need identity, not just a shared secret.

The rest is discipline that compounds. TypeScript strict mode on from day one. Automated deploys from the main branch. Environment separation with real staging data shapes. Security rules and index definitions in version control alongside application code. None of it is novel, and all of it is the difference between a codebase a new engineer can be productive in within a week and one that requires archaeology.

We keep several production codebases fully open source, including complete SvelteKit and Firebase sites, so these patterns are readable rather than described. If you want to see how the stack actually looks in a shipped product, the repositories are the most direct answer.

For the detailed version of the Firestore modeling and cost-control decisions summarized here, see our Firebase at real scale write-up, which covers document structure, read amplification, security rules, and the exact signals we use to move a workload off Firestore.