Most Spring Boot projects that survive more than two years contain a package named common, core or framework. Inside it there is usually a base entity class, an abstract CRUD controller, a global exception handler, a homegrown audit mechanism, soft delete implemented through a boolean flag, and a utility class that resolves the current user.
That package is an application framework. It was never planned as one, it is rarely documented, and it is typically maintained by one or two people. This article examines why that pattern appears so consistently, what it costs over the life of a system, and how engineering leaders should decide whether to keep building it.
The Choice Is Not "Framework Versus Spring"
A common objection frames this as a binary: adopt an application framework or stay with Spring. That framing is inaccurate.
Jmix, the framework we build, is Spring Boot. Applications use an ordinary ApplicationContext, ordinary beans, standard JPA entities and standard Spring Security. Any component can be injected, overridden or bypassed in favour of plain Spring.
The real decision is narrower and more practical: does your team write the convention layer, or adopt an existing one? Every organization running line-of-business software on the JVM makes this decision, usually implicitly.
Why the Pattern Reproduces
It Has a Documented Name
The tendency was named by Alex Papadimoulis in 2006 as the inner-platform effect: the tendency to build a system so customizable that it becomes a replica, often a poor replica, of the development platform underneath. It emerges specifically when an internal library accumulates general-purpose features that duplicate platform capabilities.
The older formulation, Greenspun's tenth rule, makes the same observation about sufficiently complex programs reimplementing a large fraction of a more capable system, informally and with defects.
The Ecosystem Is Evidence of a Gap
If bare Spring Boot fully addressed the need, the surrounding tool ecosystem would not exist. It does, and it is substantial:
- Spring Roo, the Spring team's own attempt to eliminate this boilerplate, is now archived. The underlying problem outlived the solution.
- JHipster remains active, generating precisely the layer teams otherwise write by hand.
- Apache Causeway, a top-level Apache Software Foundation project, generates a complete user interface from a domain model at runtime, on Spring Boot.
- Openkoda and Erupt provide authentication, roles, multi-tenancy, and administrative screens as platform features.
Outside the Java ecosystem, the gap is closed inside the framework itself. Django ships an admin interface. Rails provide scaffolding. In those communities, a framework-supplied administrative layer is unremarkable.
The consistent conclusion across ecosystems: this layer is required by nearly every business application, and someone has to supply it. The only decision is who.
What an Opinionated Framework Supplies
The components teams rebuild most often, and what a framework provides instead:
| Capability | Typical in-house implementation | Framework default |
|---|---|---|
| Users and roles | Custom entity, hand-written admin screens | Complete user and role administration |
| Access control | @PreAuthorize annotations, manual UI hiding | Declarative policies enforced on server and in UI |
| Soft delete | Boolean flag plus a query filter | Built-in, applied consistently |
| Auditing | Custom listeners | Configured entity auditing |
| Optimistic locking | Manual version handling | Standard |
| CRUD screens | Written or generated per project | Generated as editable source |
The distinction that matters is not capability but ownership. An in-house layer is documented by whoever wrote it, understood by whoever remains, and transferable to no other project. A public framework is documented externally, maintained independently of staff turnover, and already known to candidates you have not yet hired.
Server-Side UI: The Objection Worth Addressing
Jmix builds its user interface on Vaadin Flow, which is server-side: components and screen state live on the server. Teams accustomed to single-page applications raise this immediately, and it deserves a direct answer rather than a defense.
For line-of-business systems, internal applications used by tens or hundreds of authenticated employees, server-side UI removes substantial cost:
- no separate frontend codebase, build pipeline or specialist hiring;
- no REST and DTO layer to design, version and map in both directions;
- no duplicated validation and state management across two stacks.
The boundary is equally clear. Public, high-traffic, SEO-sensitive frontends are not the target: for those, a headless approach with a dedicated frontend is the correct choice. Within its intended scope, "server-side is outdated" is an aesthetic position rather than an engineering one.
The Cost Structure Executives Should Examine
Arguments for in-house frameworks are usually expressed as control. The relevant question is control over what.
The control being defended is control over infrastructure: how base entities, CRUD layers, permission checks and audit trails are implemented internally. These are decisions in which your product does not differ from a competitor's in any way a customer perceives.
An opinionated framework removes discretion over infrastructure and preserves it entirely over the domain, which is where differentiation actually occurs.
The ongoing costs of the in-house alternative are predictable:
Key-person dependency. Institutional knowledge of an internal framework concentrates in one or two engineers. Their departure converts a working system into a legacy one.
Onboarding duration. New engineers learn a public framework from documentation and community resources. They learn an internal framework only from colleagues, consuming senior time for months.
Total cost of ownership. Initial development is the smaller expense. Maintenance, documentation, migration across Spring versions and continuous knowledge transfer accumulate for the life of the system.
Estimation reliability. Convention-driven projects are predictable to staff and estimate. Internally-conventioned projects are predictable only to their authors.
How to Decide
The assessment is straightforward and can be done this quarter:
- Measure the internal framework package: lines of code, commit history, number of engineers who have modified it in the past year.
- Convert that into person-months, including the maintenance since initial development.
- Determine what fraction of it implements capabilities available as platform defaults.
- Assess whether any of it differentiates your product from a competitor's.
If most of the package duplicates platform capability and none of it differentiates the product, it is a maintenance liability presented as an asset. That does not mandate replacement, since migration has its own cost, but it should inform every subsequent build-versus-adopt decision.
When the Author Is an AI Agent
This calculus changes when code is written by AI agents rather than engineers, and it changes in a direction that penalizes in-house frameworks specifically. An agent has no memory of undocumented internal conventions and no colleague to ask. It reconstructs the missing layer from first principles on every attempt.
We measured this under controlled conditions: one agent, one frozen specification, two stacks, three scored runs each, with a hidden test suite. The results, including those unfavourable to our position, are in the benchmark report.
