Jaspero's Open Source Portfolio: Inside JMS and Five Public SvelteKit + Firebase Repositories

What is Jaspero and what does it publish on GitHub?

Jaspero is a software development agency that builds web and mobile products, mostly on SvelteKit, Firebase, and React Native. On GitHub, under the Jaspero organization, we publish JMS (our open source content management system) and the complete source of several production websites we built and still maintain.

The reason these repositories exist is simple. Most public SvelteKit and Firebase examples are toy projects: a todo list, a demo auth flow, a blog with three posts. They stop being useful the moment you need multilingual content, a real editorial workflow, image processing, Cloud Functions, security rules, or a deploy pipeline. The repositories listed below are live sites with paying stakeholders, published as-is, which means the awkward parts are visible too.

If you arrived here searching for "jaspero github", "jaspero jms", or "jaspero cms", this page is the index. Each section below explains what a repository contains, what architectural decision it demonstrates, and the specific files worth opening first.

What is JMS, Jaspero's CMS?

JMS is Jaspero's open source content management system. It is a schema-driven admin layer on top of Firebase: you describe a Firestore collection with a JSON schema, and JMS generates the list views, filters, forms, and validation for editing that collection, without writing a bespoke admin panel for every project.

The design goal was to stop rebuilding the same back office. Nearly every client project needs an interface where non-technical people edit pages, articles, products, team members, or events. Those interfaces are structurally identical and differ only in fields. JMS treats the collection definition as data: field types, layout, validation rules, table columns, sorting, and permissions all live in configuration rather than in hand-written Angular or Svelte components.

Practically, that means the CMS half of a project becomes configuration work, and the interesting engineering effort moves to the public-facing site and the domain logic. The trade-off is real: when a client needs a genuinely unusual editing experience, you either extend JMS with a custom component or accept a slightly generic screen. We have found the trade-off worth it on content-heavy sites and less compelling on products where the internal tool is the product.

• • Schema-driven collections: field definitions in configuration generate forms, tables, and validation
• • Firebase-native: Firestore for data, Firebase Auth for access, Cloud Storage for media
• • Role and permission handling wired to Firestore security rules rather than only enforced in the UI
• • Designed to sit alongside a separately deployed public site rather than render it

What do the five public SvelteKit + Firebase repositories contain?

Five Jaspero repositories publish the complete source of live sites: Human Glycome, Agrimatco, Intl Glyco, Genos, and Bioinspekt. Together they cover a research consortium CMS, a full corporate site with a product catalogue, a scientific organization homepage, a webshop with Cloud Functions, and a JMS-managed marketing site.

They are deliberately different in scope. Intl Glyco is the smallest and the best starting point if you want to see how a prerendered SvelteKit site with a handful of content types is structured end to end. Genos is the largest, because a webshop drags in order handling, backend functions, and transactional email. Reading them in order of increasing complexity is a faster education than reading any one of them in isolation.

• • Human Glycome: CMS plus public website for a research consortium studying human glycoconjugates. Useful for seeing how editorial content, researcher profiles, and publication listings are modelled in Firestore.
• • Agrimatco: the full source of agrimatco.hr, an agricultural distributor's corporate site. The most complete example of a real-world full-stack SvelteKit and Firebase build in the set, including a structured product catalogue and multilingual content.
• • Intl Glyco: homepage for the International Glycoconjugate Organization, which runs biennial symposia and awards. Small surface area, clean routing and prerendering, good first read.
• • Genos: website, CMS, and webshop for a biotech company, with backend Cloud Functions and content management deployed on Firebase. Shows commerce flows and server-side logic in the same repo as the marketing site.
• • Bioinspekt: complete source of the Bioinspekt website with content managed through JMS. The clearest demonstration of the CMS-plus-site split in production.

How should you read these repositories?

Start with routing and data access, not with components. In every repository, open src/routes to see the page structure, then find where Firestore is queried and whether it happens on the server, at build time, or in the browser. That single question explains most of the rest of the architecture, including caching, SEO behaviour, and cost.

After that, follow this order. Look at the prerender and SSR flags per route, because they tell you what the team decided was static and what needed to be fresh. Then read the Firestore security rules, which are the actual authorization model regardless of what the UI shows. Then read the Cloud Functions, if the repo has them, since anything that cannot be trusted to a client sits there: payment handling, email, image processing, aggregation writes. Finally look at the head and meta handling, which is where most SvelteKit sites quietly succeed or fail at SEO.

One honest caveat: these are real projects, not curated teaching material. Some of them carry decisions we would make differently today, and some contain code written years apart under different conventions. Read them as evidence of how production work actually looks, not as a style guide to copy line for line.

• • src/routes: page structure, dynamic segments, layout inheritance
• • Route-level prerender and ssr flags: the static versus dynamic boundary
• • Firestore rules: the real authorization model
• • Cloud Functions: anything that must not run on a client
• • Head and meta handling: canonical URLs, titles, structured data
• • Firebase config and deploy scripts: hosting rewrites, indexes, environments

Why publish client work as open source at all?

Because for an agency, claims about engineering quality are cheap and code is not. Publishing the full source of sites we built lets prospective clients and engineers verify how we structure projects, handle authorization, and treat performance, without a sales call and without a curated slide deck.

There are secondary benefits. The repositories act as a shared reference for our own team, so patterns like route-level prerendering or the CMS-plus-site split do not have to be re-explained on each new engagement. They also make onboarding faster, since a new engineer can read a complete, working example of the stack before touching a client codebase.

Not everything is public, and it should not be. Client work covered by confidentiality, systems that handle personal or laboratory data, and anything where the source would materially weaken security stays private. The public repositories are the ones where the client agreed and where openness costs nothing but transparency. That distinction matters: open sourcing is a decision made per project with the client, not a blanket policy.

For a deeper look at the prerendering and meta-tag decisions visible in these repositories, see our SvelteKit SEO in production write-up, which draws its examples from the same four open-sourced builds.