DeesseJS
  • Enterprise
  • Pricing
DeesseJS logoDeesseJS

Software engineering as a commodity: agents that code, workflows that scale, infrastructure that works. Built with the DeesseJS ecosystem.

Ecosystem

  • Errors
  • DRPC
  • Collections
  • FP

Learn

  • Docs
  • Blog
  • Changelog
  • Knowledge Base

Use cases

  • SaaS apps
  • AI products
  • Landing pages
  • API backends
  • Internal tools

Company

  • About
  • Manifesto
  • Principles
  • Vision
  • Enterprise
  • Delivery
  • Help

Legal & Trust

  • Privacy
  • Terms
  • Cookies
  • DPA
  • Security

Community

  • Open Source Program
  • Students
  • Github
  • LinkedIn
  • X

Explore

  • Customers
  • Templates
  • Ecosystem
  • Stack
© 2026 DeesseJS. All rights reserved.

Use case · Open source

Maintainer-friendly starters, versioned through the registry.

MIT-licensed starters for OSS maintainers. Pin a version, ship your app, never touch the registry again unless you want to.

Use it yourselfTalk to delivery

What's in the box

The four sub-systems every OSS project needs.

Twelve capabilities grouped by the maintainer-side question they answer. Pick a cluster, read what you actually get, and ship it.

License + changelog, day one

The two things every real OSS project has, written into the template from the first commit.

MIT baked into every template

Every template ships with an MIT LICENSE file in the right place, the right name. No copy-paste from a previous project, no half-licensed dep tree. The registry checks at template acceptance.

CHANGELOG.md, generated

Conventional commits flow into CHANGELOG.md on every release. Not a manual edit, not a stale bullet from 18 months ago. The release notes read like the project has been alive for years.

Public roadmap, written into the repo

Roadmap lives at docs/roadmap/ in the repo, versioned with the code. Users see what's coming without subscribing to a Notion page maintained by one person.

license-and-changelog
Sourcepost.mdx
---
title: "Ship from contracts, not scratch"
slug: ship-from-contracts
date: 2026-09-14
tags: [saas, agents, registry]
author: martyy
status: published
---

Your agent navigates the same
contracts the registry ships. The
template doesn't just scaffold - it
locks the surface so the model
cannot drift.
Previewrendered

Ship from contracts, not scratch

Your agent navigates the same contracts the registry ships. The template doesn’t just scaffold — it locks the surface so the model cannot drift.

saasagentsregistry

The public registry CLI

Users install with one command and update with the same. They never need to learn the internal toolchain.

deessejs init — one command to scaffold

Users run deessejs init <template>. The CLI resolves the version, scaffolds the project, installs deps. They never see a tarball URL, never edit a workflow file, never know what's underneath.

Versioned updates, through the same path

deessejs update bumps the user to the next template version, with the same changelog-style notes they get from any dependency. The update path is the install path — no separate upgrade ritual.

Templates discoverable, not pinned in a doc

deessejs list <query> resolves from the live registry, not from a hardcoded catalog. Templates appear when published, disappear when deprecated, version themselves naturally.

registry-cli
preview unavailable

Same shape across contributors

A PR from outside the team lands in the same shape as one from inside. Conventions outlive the original author.

AGENTS.md at the template root

Every template ships with an AGENTS.md at the root, describing the conventions a contributor needs to know. An outside contributor reads it once and writes code the same way the inside team does.

CI enforces the checklist

Typecheck, lint, format, dependency audit — the same checklist runs on every PR, internal or external. A contribution that doesn't pass the checklist isn't a contribution.

CODEOWNERS routes reviews correctly

Each area has an owner — not always the same person, but always someone who knows the surface. An outside PR to the auth layer doesn't wait for a maintainer who never touched auth to review it.

community-shapes
preview unavailable

Releases that don't break

Tagged, tested, and announced through the channels the project already uses. No release-day scramble.

Changesets, not guesswork

Every PR carries a changeset. The release PR aggregates them; the maintainer reviews them; the registry publishes them. No 'oops, that was a breaking change' after the tag lands.

Semver bumps, enforced

Major, minor, patch — enforced at the registry level from the changeset content. A feat with a breaking change bumps major; a feat without breaking bumps minor. The version matches the change.

GitHub release + published announcement

The release job opens a GitHub release with the same notes the CHANGELOG carries, posts to the social channels the maintainer configures, and pings the consumers via the registry's update path.

release-automation
Queue · 3 workersrecent
  • j_8a3fsend_welcome_email×1ok 182ms
  • j_8b2csync_stripe_customer×1ok 412ms
  • j_8c11issue_invite_token×1···
  • j_8d4erender_invoice_pdf×2retry
  • j_8f9apurge_old_sessions×1ok 71ms

Standards

What ships with every template.

MMIT licensePPublic roadmapddeessejs CLIAAccepted registry

Process

How an OSS project ships.

  1. Step 01

    License and changelog, day one

    MIT license baked into every template. Changelog-driven releases, public roadmap. The boring things that make a project real.

  2. Step 02

    Install with the public CLI

    Users run deessejs init. They do not need to know your internal toolchain. Updates flow back through the same registry.

  3. Step 03

    Community contributions, same shape

    Templates ship with the same AGENTS.md and conventions. A contribution from outside your team lands in the same shape as one from inside.

Built on this

Four templates, each on its own surface.

Production-ready starter templates, each deployed at its own URL. Used as the reference set for what the registry can ship.

oss-starter

MIT-licensed starter, branded README + CONTRIBUTING.

changelog-driven

Conventional commits → CHANGELOG → GitHub release, automated.

registry-submit

PR flow to add a new template to the public registry.

versioning-rules

Semver + changesets, enforced at the registry level.

Explore

Related use cases.

Related

SaaS apps

Multi-tenant B2B SaaS with auth, billing, and a working dashboard on day one.

Read more

Related

Internal tools

Operator consoles that work behind SSO, on the same auth and contracts as your customer app.

Read more

Related

Landing pages

High-converting marketing surfaces, tuned for the B2B SaaS shelf.

Read more

Two doors

Use it yourself, or have us ship it for you.

Self-serve gives you the registry and the templates. Engagement gives you the team that built it. Pick the door that fits the timeline.

Browse templatesTalk to delivery