Boundary is the first Clojure framework that ships enforced FC/IS architecture, auto-generated admin UI, pluggable observability, declarative interceptors, state machine workflows, full-text search, report generation, calendar scheduling, multi-tenancy, real-time, distributed caching, background jobs, PII-safe logging, feature flags, a PSP abstraction (Mollie/Stripe), framework-aware AI tooling, shared UI style bundles, marker-based i18n, and Twilio/SMTP/IMAP adapters — 22 libraries in one coherent, swappable stack.
The Clojure community is right to be skeptical of frameworks. Here's the direct answer.
The question isn't "framework vs. no framework." It's "explicit conventions vs. implicit conventions." Every serious Clojure backend already has the latter. Someone decided that business logic lives here and I/O lives there. Someone decided how snake_case converts at the database boundary. Someone documented why the service layer is structured the way it is — or didn't, and now that knowledge lives in one person's head.
Boundary makes those decisions explicit, enforced, and consistent across every module and every team member. The enforcement is worth examining: bb check:fcis runs as a pre-commit hook and in CI. It will fail your build if a core/ namespace imports anything from shell/, any I/O library, or a logging framework. That's not magic — it's a clj-kondo rule and a Babashka script. You could write it yourself. Boundary just ships it so you don't have to.
If "architecture library" resonates more than "framework," that framing works too. Boundary is opinionated about structure, not about which libraries power it — each boundary-* artifact is a standard deps.edn dependency you can adopt one at a time. Your existing Integrant, Reitit, and next.jdbc code doesn't go away. Boundary provides the connective tissue and enforces the pattern.
If you're a solo developer who owns the whole codebase and genuinely enjoys making architectural decisions fresh each project, Boundary adds friction, not value. It's built for teams and systems that need to stay consistent over years — where onboarding time, cross-team refactoring, and long-term maintainability have real costs.
These numbers come from comparing Boundary to the standard approach of assembling a Clojure stack from scratch.
Every SaaS subscription Boundary replaces with a self-hosted alternative — running on your existing infrastructure.
| Service Category | Typical SaaS/month | Boundary Replacement | Savings/month |
|---|---|---|---|
| Auth (Auth0, Clerk) | €130–€1,550 | boundary-user | €130–€1,550 |
| Background Jobs (Inngest, Temporal) | €90–€460 | boundary-jobs | €90–€460 |
| Admin UI (Retool, Forest Admin) | €90–€460 | boundary-admin | €90–€460 |
| Search (Algolia, Elastic Cloud) | €460–€1,840 | boundary-search | €460–€1,840 |
| Error Tracking (Sentry) | €90–€460 | boundary-observability | €0–€370 |
| Total Monthly | €860–€4,770 | Self-hosted on existing infra | €770–€4,680 |
Annual savings: €9,240–€56,160 per project. For a 10-project enterprise: €92,400–€561,600/year.
Boundary vs. the frameworks Clojure developers reach for — and the ones they come from.
| Capability | Boundary | Django | Rails | Phoenix | Kit |
|---|---|---|---|---|---|
| FC/IS enforcement | Built-in | — | — | — | — |
| Auto-generated admin UI | Built-in | Built-in | Gem | — | — |
| MFA + JWT auth | Built-in | 3rd party | Gem | 3rd party | Buddy |
| Background jobs | Built-in | Celery | Gem | Oban | Module |
| Multi-tenancy | Built-in | 3rd party | Gem | 3rd party | — |
| Real-time (WS/SSE) | Built-in | Channels | Cable | Channels | Sente |
| Full-text search | Built-in | 3rd party | 3rd party | — | — |
| State machine workflows | Built-in | 3rd party | 3rd party | 3rd party | — |
| Report generation (PDF/XLSX/DOCX) | Built-in | 3rd party | 3rd party | — | — |
| Calendar / scheduling (RRULE) | Built-in | 3rd party | 3rd party | — | — |
| AI-powered scaffolding | Built-in | — | — | — | — |
| Pluggable observability stack | Built-in | Manual | Gem | Manual | Manual |
| Automatic instrumentation | Built-in | Manual | Manual | Manual | Manual |
| PII redaction in logging | Built-in | Manual | Manual | Manual | Manual |
| Feature flags | Built-in | 3rd party | Gem | 3rd party | — |
| PSP abstraction (Stripe/Mollie) | Built-in | 3rd party | Gem | 3rd party | — |
| Framework-aware AI tooling | Built-in | — | — | — | — |
| Zero-code database switching | Built-in | Manual | Manual | Manual | Manual |
Built-in = ships with the framework · 3rd party = community library or external service · Manual = possible but must be wired by the developer · — = not available
Generic AI tools can write Clojure. Boundary makes those tools produce code that's architecturally correct, immediately mergeable, and consistent with everything already in the codebase. The reason is structural, not magical.
AI assistants generate better code in codebases they can predict. Every Boundary module follows the same layout: core/ for pure logic, shell/ for side effects, ports.clj for contracts, schema.clj for validation. When every module looks the same, a tool that has seen one can correctly generate, refactor, or extend any other — without learning project-specific conventions. It also avoids the most common AI mistake in FC/IS codebases: accidentally putting a database call inside a core/ function.
Every library in Boundary ships an AGENTS.md alongside the README. These files are written for AI coding agents — Claude Code, Cursor, Copilot — not for humans reading at 2am. A README explains what a library does. An AGENTS.md explains which layer owns which responsibility, which pitfalls cause runtime errors, and what correct patterns look like with annotated examples. This is a design choice, not an afterthought: the primary consumer of detailed technical documentation in 2026 is often an AI agent.
Malli schemas are machine-readable by design. An AI assistant that can read a schema knows exactly what data is valid, what fields are optional, what the constraints are, and what transformations are needed at the persistence boundary. When bb ai sql generates a HoneySQL query, it reads the actual Malli schemas for the relevant modules to understand the data model — rather than inferring from function signatures or guessing column names. The schema is the single source of truth, and it's parseable.
boundary-ai understands Boundary's conventions, not just Clojure syntax. NL scaffolding: bb scaffold ai "invoice module with number, line items, total, status" generates a complete FC/IS-compliant module in under a minute. Error explainer: reads Clojure stack traces with Boundary-specific context. Test generator: produces unit test namespaces for core/ functions. SQL copilot: natural language → HoneySQL. Offline-first: runs via Ollama by default — no data leaves your machine unless you explicitly configure a cloud provider.
Get a full Boundary project running in under five minutes.