Docs When Not to Use Plumego

When Not to Use Plumego

Plumego is intentionally opinionated.

It is designed for a specific class of systems and teams, and it explicitly does not try to fit every scenario.

This document describes situations where using Plumego is likely a poor choice —
not because Plumego is insufficient, but because its priorities do not align with your needs.

Stopping early is a responsible engineering decision.

1. You Need to Ship an MVP as Fast as Possible

If your primary goal is:

  • Rapid prototyping
  • Market validation
  • Short-term experimentation
  • Fast iteration with minimal upfront design

Plumego is not optimized for this phase.

Why

Plumego requires:

  • Explicit structure
  • Conscious boundary definition
  • Manual integration of common concerns

These choices add early friction that does not pay off in short-lived projects.

Better alternatives

Highly opinionated frameworks or generators that maximize speed and reduce decision-making are often more appropriate.

2. Your Team Relies Heavily on Framework Abstractions

If your team expects the framework to:

  • Auto-wire dependencies
  • Provide implicit data binding
  • Hide HTTP and context details
  • Enforce architectural patterns

Plumego will feel uncomfortable.

Why

Plumego assumes engineers:

  • Understand Go’s standard library
  • Are willing to make architectural decisions
  • Accept responsibility for system behavior

It does not attempt to protect users from complexity by hiding it.

3. Your Team Is New to Go or Backend Engineering

Plumego is not designed as a teaching framework.

If your team:

  • Is new to Go
  • Is unfamiliar with net/http
  • Has limited experience with long-lived backend systems

Plumego may slow down onboarding significantly.

Why

Plumego exposes reality early:

  • Context propagation is explicit
  • Error handling is manual
  • Request flow must be understood

Beginner-friendly abstractions are intentionally avoided.

4. You Depend on a Large Framework Ecosystem

If your project depends on:

  • Official plugins
  • Framework-managed integrations
  • Deeply coupled middleware ecosystems

Plumego is not a good fit.

Why

Plumego does not aim to build or maintain a large plugin ecosystem.

It favors:

  • Direct library integration
  • Explicit dependency management
  • Minimal framework surface area

This reduces lock-in, but increases integration work.

5. Your System Has a Short or Fixed Lifespan

If your system is:

  • A temporary service
  • A campaign or event backend
  • A one-off internal tool
  • Guaranteed to be replaced soon

Plumego’s long-term benefits may never materialize.

Why

Plumego trades short-term convenience for long-term clarity.

If long-term clarity has no value in your context, the tradeoff does not make sense.

6. You Prefer Minimal Code Over Explicit Structure

If you evaluate frameworks primarily by:

  • Lines of code saved
  • Conciseness of examples
  • One-liner solutions

Plumego will likely disappoint.

Why

Plumego intentionally prefers:

  • Explicit wiring
  • Clear data flow
  • Visible dependencies

This often results in more code — by design.

7. You Expect the Framework to Enforce Correctness

Plumego does not strongly enforce correctness through rigid constraints.

It will not:

  • Prevent architectural misuse
  • Enforce specific layering
  • Automatically correct poor design choices

Why

Plumego believes:

Engineering judgment cannot be replaced by framework authority.

Teams must establish their own conventions, reviews, and discipline.

8. You Do Not Share Plumego’s Design Values

This is the most important criterion.

Plumego values:

  • Explicitness over convenience
  • Predictability over cleverness
  • Longevity over speed
  • Engineering responsibility over framework automation

If these values feel overly conservative or restrictive,
Plumego will create ongoing friction rather than clarity.

Not Using Plumego Is a Valid Outcome

Choosing not to use Plumego does not mean you made a poor technical decision.

It means:

  • You evaluated your context honestly
  • You respected tradeoffs
  • You selected tools aligned with your priorities

That is exactly how Plumego expects engineers to work.

Summary Checklist

Plumego is likely not a good fit if:

  • You need extreme development speed
  • Your team prefers heavy framework automation
  • Your system is short-lived
  • You rely on a rich plugin ecosystem
  • You want the framework to make decisions for you

If multiple items apply, you should strongly consider alternatives.

Next

If you still believe Plumego may be suitable after reading this:

→ Plumego and Birdor

If this document convinced you otherwise:

Stopping here is the correct decision.