DeesseJS
TemplatesBlogChangelogDocs
DeesseJS logoDeesseJS

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

DeesseJS

  • Errors
  • DRPC
  • Collections
  • FP
  • UI
  • Admin
  • Cloud

Learn

  • Docs
  • Blog
  • Changelog
  • Knowledge Base
  • Academy
  • Community

Use cases

  • SaaS apps
  • AI products
  • Landing pages
  • API backends
  • Internal tools
  • Open source
  • Mobile backend

Company

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

Legal & Trust

  • Privacy
  • Terms
  • Cookies
  • DPA
  • Security

Community

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

Explore

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

How we work

Principles.

The day-to-day operating rules that complement the manifesto. Most of them were earned the hard way.

The nine tenets

I.

Ship the smallest useful thing

Every release answers one question. We cut scope until the remaining change is small enough to merge with full attention. The roadmap stays public so users see what's next and what's intentionally not yet.

II.

Public by default

Specs, decisions, and tradeoffs live in the open. We document in the file, not in a wiki. Decisions are recorded in the docs they affect, with their context, so a future reader can rebuild the choice from first principles.

III.

Two-way door first

Reversible changes ship fast. Irreversible ones earn design docs, second reviews, and a runbook. We bias toward options we can walk back from, and we name the few we cannot.

IV.

Templates are test fixtures

Every DeesseJS template is built once, smoke-tested, versioned, and reused. If a template needs custom logic that doesn't generalize, it stays a private fork — the registry earns its name by curating what survives contact with production.

V.

The CLI is the contract

Anything users do often lives in the CLI. The web surface explains; the terminal ships. When the two diverge, the terminal wins — that's where time accumulates.

VI.

Modular before clever

We split until each file has one job, then we stop. Reusable primitives live in packages/* with their own tests, their own version, their own release cadence. Cross-package coupling is a smell.

VII.

Defaults over configuration

We ship defaults that work for 80% of cases. Configuration exists for the 20%; we don't apologize for hiding it under a flag. Every option we expose is a future option someone has to maintain.

VIII.

Observability is a feature

If we can't see it, we can't ship it. Logs, traces, and metrics land with the feature, not after. Internal tools get the same telemetry treatment as user-facing ones.

IX.

Pause before adding

We add things on purpose. The default answer to a new dependency, a new endpoint, a new env var, a new product surface is *not yet*. If the case grows louder after a week of waiting, we revisit. Otherwise, we let it go.

Read next

ManifestoWhy we're here — the beliefs behind the work.VisionWhere this is going next.AboutWho we are, and how we got here.EcosystemThe sub-domains and shared values.