Docs Tradeoffs

Tradeoffs

Plumego is not optimized for every metric.

It makes a series of explicit tradeoffs in order to uphold its design philosophy.
Understanding these tradeoffs is essential before adopting the framework.

This document describes what Plumego gives up, why those choices were made, and what they mean in practice.

1. Slower Initial Development Speed

What is traded off

Plumego does not optimize for the fastest possible time-to-first-feature.

Compared to more opinionated frameworks, Plumego often requires:

  • More upfront structure
  • Explicit wiring of components
  • Manual handling of concerns that other frameworks automate

Why this tradeoff exists

Fast initial development often relies on:

  • Implicit conventions
  • Auto-wiring
  • Global state
  • Hidden framework behavior

Plumego deliberately avoids these patterns because they:

  • Obscure system behavior
  • Accumulate technical debt
  • Become difficult to reason about as systems grow

What this means for you

  • Early progress may feel slower
  • More decisions are required up front
  • The payoff appears over time, not immediately

Plumego assumes that initial speed is not the primary success metric.

2. More Code, Less Magic

What is traded off

Plumego favors explicit code, which often results in:

  • More lines of code
  • Fewer “one-liners”
  • Less automation

Why this tradeoff exists

Every hidden behavior must eventually be understood.

By making data flow and execution explicit, Plumego:

  • Reduces cognitive load during debugging
  • Makes side effects visible
  • Improves long-term readability

What this means for you

  • Codebases may appear more verbose
  • Engineers must be comfortable writing “glue code”
  • Review processes tend to focus on structure, not tricks

This verbosity is intentional and valued.

3. Smaller Built-In Feature Set

What is traded off

Plumego intentionally avoids providing:

  • ORM abstractions
  • Job schedulers
  • Configuration frameworks
  • Caching layers
  • Messaging systems

Why this tradeoff exists

These components are:

  • Highly opinionated
  • Context-dependent
  • Often deeply coupled to infrastructure choices

Including them would force Plumego to make assumptions that may not hold for your system.

What this means for you

  • You choose your own tools
  • Integration work is required
  • You retain full control over dependencies

Plumego values composability over completeness.

4. Reduced Framework Ecosystem

What is traded off

Plumego does not aim to build a large plugin ecosystem.

You will not find:

  • Hundreds of official plugins
  • A marketplace of extensions
  • Tight integration with third-party libraries

Why this tradeoff exists

Large ecosystems:

  • Create long-term maintenance obligations
  • Encourage coupling to framework internals
  • Make backward compatibility harder

Plumego prioritizes a small, stable core.

What this means for you

  • You integrate external libraries directly
  • You own those integration boundaries
  • You are less affected by ecosystem churn

5. Higher Engineering Responsibility

What is traded off

Plumego does not shield engineers from architectural decisions.

It will not:

  • Choose your data model
  • Enforce architectural patterns
  • Prevent you from making poor design choices

Why this tradeoff exists

Frameworks that make decisions for you often:

  • Encode assumptions that don’t scale
  • Limit future change
  • Hide complexity rather than reduce it

Plumego assumes engineering responsibility cannot be outsourced.

What this means for you

  • Teams must agree on conventions
  • Architectural discipline is required
  • Code review culture becomes important

Plumego works best in teams that embrace ownership.

6. Less “Beginner-Friendly” Experience

What is traded off

Plumego is not optimized for beginners.

It assumes familiarity with:

  • Go’s standard library
  • HTTP request handling
  • Context propagation
  • Basic architectural concepts

Why this tradeoff exists

Beginner-friendly abstractions often rely on:

  • Simplifications that hide important details
  • Patterns that do not generalize well
  • Magic that must later be unlearned

Plumego prefers to expose reality early.

What this means for you

  • Onboarding may take longer
  • Documentation reading is essential
  • Engineers grow deeper understanding over time

7. Fewer Guardrails

What is traded off

Plumego provides fewer enforced constraints.

It does not:

  • Prevent misuse by design
  • Lock you into specific patterns
  • Automatically “fix” architectural mistakes

Why this tradeoff exists

Strong guardrails can become rigid walls.

Plumego favors:

  • Flexibility within clear boundaries
  • Engineering judgment over enforcement
  • Adaptability over prescription

What this means for you

  • Mistakes are possible
  • Responsibility is shared by the team
  • Internal guidelines matter

Tradeoffs as a Design Signal

None of these tradeoffs are accidental.

Together, they signal a clear position:

Plumego optimizes for systems that must be understood and maintained over long periods of time.

If your priorities align with:

  • Speed over clarity
  • Convenience over control
  • Ecosystem over ownership

Plumego is not the right choice.

That is not a failure — it is a deliberate boundary.

Summary

By choosing Plumego, you accept:

  • Slower initial progress
  • More explicit code
  • Fewer built-in features
  • Greater engineering responsibility

In return, you gain:

  • Predictable behavior
  • Clear boundaries
  • Long-term maintainability
  • Architectural freedom

This exchange only makes sense if you value the latter more than the former.

Next

To clearly understand when these tradeoffs become unacceptable, continue with:

→ When Not to Use Plumego