Docs When You Should Not Use Plumego

Introduction: A Responsible Framework Must Define Its “Non-Use Cases”

Any framework that takes engineering quality seriously must be willing to answer one question:

“In what situations should you not use me?”

If a framework claims that it:

  • fits every team,
  • fits every stage,
  • fits every business,

then it is almost certainly not credible.

Plumego was never designed to be a universal answer.
It is a choice explicitly created for a specific class of engineering problems.

So this article is not “self-negation.”
It is doing something more important:

Making Plumego’s boundary conditions explicit.

1. If Your Top Priority Is “Ship Extremely Fast,” Don’t Use Plumego

Plumego Is Not Designed for MVP Speed

If the core goal of your current project is:

  • ship as soon as possible,
  • validate as soon as possible,
  • iterate and fail fast,
  • abandon and restart quickly,

then what you usually need is:

  • strong conventions,
  • code generation,
  • plenty of defaults,
  • minimal upfront engineering decisions.

Plumego is the opposite.

It will ask you to:

  • define a clear project structure,
  • consciously separate layers,
  • handle errors explicitly,
  • leave boundaries for the future.

In an MVP stage, these are often a burden.

A Simple Rule of Thumb

If what you are saying right now is:

“Let’s just get it working—we’ll refactor later anyway.”

Then Plumego is probably not a good fit.

Plumego assumes:

“This code will likely be maintained in the future.”

2. If Your Team’s Go Fundamentals Are Weak, Don’t Use Plumego

Plumego Assumes You Understand Go—Not That Go Will “Protect” You

One of Plumego’s design assumptions is:

Users are familiar with (and even respectful of) the Go standard library.

That implies:

  • you understand context.Context propagation semantics,
  • you understand the net/http handler model,
  • you can distinguish “framework conventions” from “language behavior.”

If your team members are mostly:

  • temporarily switching from other languages,
  • heavily dependent on framework wrappers,
  • rarely reading standard library docs,

then Plumego may make them:

  • feel uneasy while writing code,
  • struggle to debug,
  • feel confused about “why it must be written this way.”

A Framework Is Not a Teaching Tool

Plumego will not:

  • teach you what HTTP is,
  • teach you what Context is,
  • teach you how to organize business logic.

It assumes you already know these things—and then provides a more durable engineering baseline.

3. If You Heavily Depend on “Framework Ecosystem Plugins,” Don’t Use Plumego

Plumego Does Not Try to Build a Massive Ecosystem

Some frameworks’ core advantage is:

  • a large plugin ecosystem,
  • mature middleware libraries,
  • an out-of-the-box component marketplace.

For example:

  • authentication,
  • rate limiting,
  • observability,
  • configuration centers,
  • deep ORM integrations.

Plumego’s strategy is:

Don’t lock you in—and don’t choose for you.

Which means:

  • you integrate components yourself,
  • you evaluate trade-offs yourself,
  • you maintain boundaries yourself.

A Practical Reality Check

If your project clearly depends on:

  • a “star plugin” in a particular framework ecosystem,
  • a strongly coupled engineering system,
  • an official, tightly integrated end-to-end solution,

then using Plumego may increase—not reduce—your cost.

4. If You Want “The Fewest Lines of Code,” Don’t Use Plumego

Plumego Does Not Optimize for Minimal Code

In Plumego, you will often see:

  • explicit structural separation,
  • deliberate dependency passing,
  • code that “could be merged” intentionally kept separate.

This is a design choice—not a lack of capability.

Plumego values:

  • readability,
  • maintainability,
  • replaceability,
  • evolvability.

The Key Divergence

If you judge a framework mainly by:

“For the same feature, which one requires fewer lines?”

Then Plumego will almost certainly lose.

And it accepts that from day one.

5. If Your System’s Lifecycle Is Clearly Short, Don’t Use Plumego

Plumego Is Designed for Systems That Will Live Long

Plumego is well-suited for:

  • internal foundational services,
  • platform/middle-layer systems,
  • long-running products,
  • core business systems.

But if your system:

  • lasts only a few months,
  • is explicitly one-off,
  • or is an event/campaign service,

then much of Plumego’s “long-term value”
simply cannot be realized.

Engineering Is Not a Moral Choice—It’s a Cost Calculation

In short-lived projects:

  • clear structure ≠ guaranteed payoff,
  • long-term maintainability ≠ competitiveness.

Choosing Plumego may become over-engineering.

6. If You Expect “The Framework to Make Decisions for You,” Don’t Use Plumego

Plumego Will Not Think for You

Plumego carries an implicit premise:

Engineering decisions should be owned by engineers—not delegated to the framework.

So it will not:

  • force a particular ORM,
  • decide your directory layout,
  • hide complexity on your behalf.

It will only:

  • provide a clear boundary model,
  • offer recommended patterns,
  • ensure those patterns are sustainable.

A Blunt Question

If what you want is:

“Tell me exactly how to write it—don’t make me think.”

Then Plumego will not be friendly to you.

7. If You Need “Strongly Enforced Team Style Constraints,” Be Careful

Plumego Is a Skeleton, Not a Full Rulebook

Plumego provides:

  • technical boundaries,
  • a request model,
  • lifecycle structure.

But it does not enforce:

  • a specific code style,
  • a specific DDD / Clean Architecture variant,
  • a full template-based code generation workflow.

This implies:

  • the team must be disciplined,
  • internal conventions must be added,
  • a healthy code review culture is required.

If your team needs:

  • very strong uniform constraints,
  • extremely clear “standard answers,”

then Plumego may feel “too free.”

8. If You Fundamentally Disagree with Plumego’s Values

This is the most important—and most commonly overlooked—point.

Plumego’s values are explicit:

  • restraint,
  • explicitness,
  • long-term thinking,
  • respect for complexity.

If your instinct is that these are:

  • too slow,
  • too conservative,
  • too engineering-heavy,
  • not “modern” enough,

then even if it is technically feasible, cultural friction will persist.

9. Summary: Not Using Plumego Does Not Mean You Made a Wrong Choice

Choosing a framework is ultimately answering a few questions:

  • How much cost are you willing to pay for the future?
  • How much explicit complexity can you tolerate?
  • Do you trust the framework more—or do you trust yourself more?

Plumego simply provides one very clear answer.

If your answers differ,
you should not—and do not need to—force Plumego into your project.

Closing: Knowing When Not to Use Something Is Real Engineering Maturity

A mature engineering system does not use the same tool everywhere.

It does this instead:

Use the right complexity in the right place.

Plumego has never aimed to be “used by more projects.”

It aims to:

Appear only where it truly fits.

If you read this article carefully and decide not to use Plumego,
that is evidence of a responsible engineering decision.