Build an Internal Framework or Use Off the Shelf?

Do not build your own framework. Build a thin layer of glue over standard, off-the-shelf tools. When people set out to create a shared foundation for a portfolio, the seductive mistake is to build a homegrown framework that every product sits inside. It feels like the ultimate reuse. It is actually the ultimate trap: you take on the maintenance burden of a framework, you cut yourself off from the ecosystem, and every new hire or future you has to learn a bespoke system instead of skills that transfer. Your foundation should be opinions and glue, not an invention.

Should I build a framework for my portfolio?

Almost never. A framework is a large, permanent commitment that you now own forever. It has to keep pace with the languages and libraries underneath it, handle cases you did not anticipate, and stay documented well enough that anyone can use it. That is a full product on its own, and it produces nothing customers pay for.

Off-the-shelf frameworks already solved the hard, general problems and have thousands of people maintaining them, writing docs for them, and answering questions about them. When you build your own, you inherit none of that. Every bug is yours. Every upgrade is yours. Every "how do I do X" has no answer except reading your own source. This is the classic build versus rewrite trap at the framework scale, where the cost of owning the thing dwarfs the benefit of it being yours.

The exception is narrow and specific. If your portfolio does something genuinely unusual that no tool supports, build the minimum to cover that gap. But that is a targeted tool, not a framework everything must sit inside.

What a foundation should actually be

Your foundation is a set of decisions plus the glue that encodes them. It is not a wall your products live behind. It is a paved road they choose to drive on.

Concretely, a good portfolio foundation is:

• Chosen standard tools: a mainstream web framework, a real database, a standard deploy pipeline. Boring, proven, widely understood.
• Opinions on top of them: how auth is wired, how billing connects, how config is structured, how logging is formatted. The decisions, made once.
• Thin glue: the small amount of code that wires the standard tools together the way you decided. Helpers, not a framework.
• A scaffold: a way to start a new product already wired up correctly.

The value is in the decisions, not in inventing new machinery. When I say standardize auth, billing, and deploy once, I mean standardize the choices and the wiring, using tools that already exist. The glue is small enough that any competent developer reads it in an afternoon, because underneath it is all standard technology they already know.

The lock-in you create for yourself

A homegrown framework is self-imposed vendor lock-in, except the vendor is you and you are the worst vendor. When products are welded into a bespoke framework, you cannot easily adopt a better library, cannot easily hand a product to someone else, and cannot easily let one product diverge when it needs to.

Thin glue over standard tools keeps every exit open. A product can drop the glue and use the underlying tool directly when it needs to. A new library slots in because you are on a mainstream stack, not a private one. This is the same reason I care about not locking myself in anywhere: the framework you cannot leave is as dangerous as the cloud you cannot leave, and you built this one yourself.

The paved road model is the healthy version. The road is the easy, default path. But it is a road, not a tunnel. Products can leave it. A framework is a tunnel, and tunnels are where portfolios go to calcify.

The pragmatic middle

The right answer is opinionated scaffolding over standard tools. You get the reuse of a shared foundation without the burden of a framework, because the reuse lives in the decisions and the wiring, and the heavy lifting lives in tools the whole industry maintains for free.

I run my portfolio exactly this way. Standard stack underneath, my opinions and glue on top, and a build platform that scaffolds a new product with those opinions already applied. That is what Bootspring does for me: it encodes the decisions and generates the wiring, on top of boring proven tools, so I get compounding reuse without owning a framework. The foundation is my opinions made cheap to apply, not a machine I have to keep alive.