The SvelteKit Startup Cost Sheet: What Five Production SvelteKit + Firebase Apps Cost to Build and Run

What a production SvelteKit + Firebase build actually costs

A marketing-plus-CMS SvelteKit site with Firebase behind it typically lands in the 8,000 to 18,000 EUR band and takes 4 to 7 weeks with one or two engineers. Add a webshop, multi-language content, or role-based back office and the band moves to roughly 20,000 to 45,000 EUR over 8 to 14 weeks.

Those bands come from the same shape of work repeated five times. The five builds we have open-sourced (human-glycome, agrimatco, intl-glyco, genos, bioinspekt) are all SvelteKit front ends with Firebase Hosting, Firestore, Cloud Functions, and JMS as the content layer. The cost difference between them is almost never the framework. It is the number of distinct content types, whether there is a transactional flow, and how much of the content model the client wants to edit themselves.

The practical estimation unit we use is the route, not the page. A route with a static layout and CMS-driven content is cheap after the first one on a project, usually a day or less. A route with a form, a server action, validation, an email side effect and an admin view of the submitted data is a different animal entirely, closer to three to five days. When we quote, we count routes in those two buckets separately and apply our day rate, then add a fixed block for deployment, CI, security rules, and SEO work that does not scale with route count.

Five repositories, by size, timeline, and what made each one more expensive

The five public repos cluster into three sizes: small brochure-plus-CMS sites in the 10 to 20 route range, mid-size institutional sites with structured content and multi-language needs, and one commerce build with a cart, checkout, and order handling. Size drives weeks; complexity of the write path drives cost.

Intl Glyco and Bioinspekt are the smallest of the group. Both are content-led sites where nearly every route is read-only and prerendered, with a handful of shared components (header, footer, section blocks, contact form) and JMS driving content. Human Glycome sits a step above because a research consortium has genuinely structured content: people, publications, member institutions, events. That means more Firestore collections, more admin editing surfaces, and more relations to model, which is where the extra weeks go.

Agrimatco is a full company site with a large product catalogue, so the cost driver is not visual design but the product taxonomy and the search and filter behaviour on top of it. Genos is the outlier, because a webshop adds payment integration, stock handling, order state, transactional email, and an order admin view. Those five or six features alone are worth more engineering days than the entire rest of a small site.

• • Small content site (roughly 10-20 routes, no transactions): 4-6 weeks, 1 engineer plus part-time design, lower end of the 8,000-18,000 EUR band
• • Structured institutional site (multiple related content types, multi-language): 6-9 weeks, 1-2 engineers, upper end of that band into the low 20,000s
• • Catalogue site with search, filters and lead capture: 8-11 weeks, 2 engineers, 20,000-35,000 EUR
• • Commerce build (cart, checkout, orders, transactional email, order admin): 10-14 weeks, 2 engineers, 30,000-45,000 EUR
• • Time to first deployed URL on all five: within the first week, because Firebase Hosting plus a SvelteKit adapter is a same-day setup

What these apps cost to run each month on Firebase

For content sites at typical institutional and SME traffic, the monthly Firebase bill sits in the single-digit to low double-digit EUR range, and two of the five have months where the bill is effectively zero because they stay inside the free tier. The commerce build is the only one with a consistently non-trivial invoice, driven by Cloud Functions invocations and Firestore writes, not by hosting bandwidth.

The reason run-rate stays low is architectural, not lucky. Content routes are prerendered or cached at the CDN edge, so a visitor reading an about page triggers zero Firestore reads. Firestore is only touched on the write path (form submissions, orders, content edits in JMS) and on the small number of routes that genuinely need live data. When we have seen Firebase bills blow up on other people's projects, it is almost always a client-side listener attached to a collection on a public page, or an unbounded query without a limit, both of which multiply reads by traffic.

The cost lines a founder should budget for beyond Firebase are small but real: a domain, an email sending provider for transactional mail, error monitoring, and, for commerce, payment processing fees. Across these builds the whole infrastructure stack for a content site typically stays under roughly 30 EUR a month in the first year. That number is worth stating plainly because founders often assume a custom build carries a hosting bill comparable to their SaaS subscriptions, and at this scale it does not.

• • Hosting and CDN: negligible for content sites, since most routes are prerendered static output
• • Firestore: reads dominated by admin and CMS usage, not public traffic, when read paths are cached properly
• • Cloud Functions: the main variable line, scaling with form submissions, orders, and scheduled jobs
• • Email, monitoring, domain: small fixed lines, typically a few EUR each per month
• • Commerce adds payment provider percentage fees, which is a revenue-linked cost, not infrastructure

The CMS decision: JMS versus Sanity versus Contentful, and the line that decided it

We use JMS, our own open source CMS, on all five builds, and the deciding factor was the per-seat and per-record pricing of hosted alternatives against a client base that edits content a few times a month. A hosted CMS subscription that costs 20 to 100+ EUR monthly forever is a meaningful share of the total run-rate on a site whose infrastructure otherwise costs under 30 EUR.

That is not an argument that hosted CMS platforms are bad. Sanity and Contentful both give you a polished editing experience, a hosted CDN for assets, localisation workflows, and preview infrastructure that we would otherwise have to build and maintain. For a content team of ten people publishing daily, that subscription is obviously worth it. For a research consortium updating an events page quarterly, it is a recurring cost with no matching recurring value, and it puts a vendor between the client and their own content.

The second factor is data locality. With JMS, content lives in the same Firestore project as everything else, so a page, a product, and a submitted enquiry are all queryable in one place with one set of security rules. With an external CMS you get a second source of truth, a second auth model, and a sync path to maintain. On small builds that integration work is a meaningful fraction of the project. We would still reach for a hosted CMS on a project with a large editorial team, complex approval workflows, or a content model that has to feed several separate products.

What we reused across all five builds, and what was bespoke every time

Roughly the same infrastructure layer was reused on every one of the five: the SvelteKit plus Firebase project scaffold, the JMS content integration, the auth pattern in hooks.server.ts, form handling with server actions and Zod validation, the SEO and structured data layer, and the deploy pipeline. That reuse is the reason a small site can ship in four weeks rather than ten.

What was bespoke every single time was the content model and the design system. No two clients have the same entities. A research consortium has publications and member institutions; an agricultural distributor has product categories, active ingredients, and crop applications; a webshop has products, variants, stock, and orders. Trying to force a generic schema onto those is how you get a CMS nobody uses. Design is the same story: the component library is rebuilt per project because these are brand sites, and a shared visual kit would make them look like each other.

This split matters when you read a quote. If an agency is charging you as though the auth flow, deploy pipeline, and form plumbing are novel engineering on your project, they are billing you for something they should have amortised across their previous work. The honest version of the estimate puts most of the budget where the thinking actually happens: your entities, your editing workflow, and the handful of features that only exist in your business.

Three builds where SvelteKit was the wrong call, and what we did instead

SvelteKit is our default for web, but we have talked clients out of it three times: when the product depends on a third-party SDK that only ships a React integration, when the client's in-house hire only knows React, and when the timeline requires a mature component library rather than building one. In all three cases Next.js or plain React was the cheaper total-cost answer.

The third-party SDK case is the most clear-cut. Some vendors, particularly in payments, analytics dashboards, rich text editing, and video, ship a first-class React component and a thin, lagging vanilla wrapper. Wrapping a complex React SDK inside a Svelte component is possible, but you own the glue forever and you inherit every upgrade break. If two or three of those SDKs are central to the product, the framework choice is already made for you.

The in-house hiring case is about the handover, not the code. If a client is about to hire their first engineer and every candidate in their budget and region writes React, choosing SvelteKit means the agency stays on the critical path indefinitely. That is good for our revenue and bad for the client, so we say it out loud during scoping. The component library case is narrower: when a build is mostly dense admin tables, complex data grids, date pickers, and charts on a tight deadline, the React ecosystem has battle-tested options that would otherwise cost weeks to reproduce. We pick SvelteKit when the interface is mostly bespoke anyway, which is exactly what all five of these public builds are.

Every project referenced here is public and inspectable; see our open source portfolio index for a repo-by-repo guide to reading each codebase.