Playing with Clay: Building More with Less in Software

How I stopped copy-pasting solutions and started shaping new paths.

At work, I was recently faced with a familiar challenge: How do we increase channels and exposure so that our solutions can reach — and benefit — even more customers?

In software, the easy answer is almost always the same: “Why not just copy and paste it?”

It’s tempting. It’s fast. It works.

But something didn’t sit right with me.

Software, at its best, feels like shaping clay — formless at first, then full of possibility. Illustration generated using AI.

Choosing the Path Less Traveled

I found myself constantly pulled toward the copy-paste approach. Yet, at the same time, my experience in software was nudging me in a different direction — toward something less obvious.

There’s often a quiet signal when you’re about to do something interesting: a slight discomfort, a sense that what you’re considering might be unconventional, maybe even an anti-pattern.

I’ve learned to pay attention to that feeling.

So I treated this like charting a path less traveled. Fewer people take it, but it tends to be more exploratory — more challenging, and ultimately, more rewarding.

The Spark: Write Once, Deploy Once, Consume Everywhere

Through a series of brainstorming sessions (with a little help from LLM agents), I landed on an idea: multi-module bundling using Webpack.

It started with a simple question:

What if I could write once, deploy once — and yet have it consumed anywhere, everywhere?

That question led to a deeper challenge of a common assumption:

Who says a UI bundle has to be just one? Why can’t a single codebase produce multiple bundles?

This isn’t entirely new. But revisiting it with a real use case made it feel surprisingly powerful.

One Codebase, Two Faces

The approach I settled on was this:

Use Webpack to build and wrap the application in two forms:

• A standalone application
• A microfrontend, powered by a framework like single-spa

The biggest advantage? A single cost of development.

With the copy-paste model, every change has to be duplicated:

• Update one version
• Then update the other
• Then manage divergence across the entire SDLC

Effort compounds quickly.

With this approach, the microfrontend essentially piggybacks on the existing development lifecycle. It coexists with the standalone app, extending it without duplicating it.

In a way, it feels like injecting new capabilities into the same organism — allowing it to behave differently depending on where and how it’s used.

The Real Trade-off: Developer Experience

Of course, this approach isn’t free.

The biggest cost shows up in developer experience.

You’re no longer building and validating a single mode — you’re managing two:

• Standalone
• Microfrontend

The ability to switch between these modes quickly becomes critical. If every change requires restarting the app just to test another form, friction builds fast.

In my case, I addressed this with a simple mechanism:

• Using URL parameters to toggle between modes during development

It’s not elegant — but it keeps the feedback loop tight, which matters more.

A Calculated Risk

I’m fully aware this approach may introduce challenges down the road:

• Compatibility issues
• Library inconsistencies
• Edge cases I haven’t yet encountered

But the cost-benefit analysis made sense for my use case.

And more importantly — I’m willing to try.

Because the reality is:

There is no perfect solution — only solutions that move us forward.

In an imperfect ecosystem, solving problems often means embracing imperfect approaches.

Why This Feels Like Playing with Clay

What I enjoy most about software is that it feels like playing with clay.

You start with nothing. You shape something. You create new channels. You connect them together — without discarding what already exists.

It’s creative, iterative, and deeply problem-driven.

You’re not just building systems — you’re shaping possibilities.

The Kind of Builder I Want to Become

At the end of the day, this is bigger than just architecture choices.

I want to become someone who:

• Deploys resources effectively
• Handles a wide range of problems
• Thinks both tactically and strategically

Someone who can assess situations holistically — like a strategist in a complex environment — and design solutions that don’t just work now, but continue to hold up in the future.

Not perfect solutions.

But thoughtful ones. Intentional ones. Ones that bring a bit more order into an otherwise messy world.