Configurable Product Software Architecture Done Right (Simply Explained)

The Mistake That Costs You for Years

A custom manufacturing client came to me with what looked like a simple problem. They made window treatments. Shades and blinds. The kind of product where a customer picks a fabric, a size, and a mounting style, and the price changes based on what they pick.

Their plan was to build software that could handle every product they might ever sell. Roller shades today. Maybe motorized systems someday. Maybe outdoor screens. Maybe shutters. Five product types on the whiteboard, and a plan to build five separate systems to handle them.

This is a trap, and AI makes it worse.

When software is cheap to create, building five systems in an afternoon feels free. It is not free. Every system has to be tested, maintained, and worked around every time you make a change. Five systems means five times the places where something can break.

And most of that work would support products that might never sell. You pay to build it. Then you pay to maintain it forever. The reward is a system that does things nobody asked for.

So the real question is this. How do you handle a genuinely complex product without building something so tangled it costs a fortune every time you want to change it?

The answer is not "build less." It is "build what you can prove you need, and design the rest so it is cheap to add later."

Let the Numbers Decide, Not the Meeting

The first thing I did was not draw a diagram. I looked at their actual order history.

The numbers ended the debate fast. About 83% of their sales came from one core product. Another 13% was accessories. The exciting new products, the ones that justified three of the five planned systems, were essentially zero sales. Not "small." Zero.

Real numbers killed three systems before a single line of code existed.

This is the step most people skip. What you want to build and what actually makes you money are almost never the same list. The gap between those two lists is where wasted money lives.

So the rule is simple. Build for the demand you can prove. Design for the demand you can't yet. Proven demand gets a working system. Everything else gets a clean spot to plug into later, and nothing more.

A ten-minute look at their order data saved months of building things nobody would use.

Two systems backed by data beat five systems backed by a meeting.

Keep the Easy Stuff Easy

Once we knew the scope, I split the design into two parts.

The first part is the catalog. Think of it like a restaurant menu kept in a simple spreadsheet. Product types, option groups, and the options inside them all live as rows you can edit. A roller shade is a product type. "Fabric," "Size," and "Mount Type" are the categories under it. "Linen White" and "Charcoal" are the choices.

Here is why that matters. When this manufacturer launches a new fabric line next spring, what does it take?

Someone on their team types in the new fabrics. That's it. The system picks them up automatically. No software engineer. No risky update. No chance of breaking the products already selling.

Compare that to how most systems work. In a lot of them, every product detail is hardwired into the software in a dozen scattered places. Every new fabric means editing all of that, retesting it, and hoping you didn't break something you forgot about. That is what makes these systems brittle and expensive. It's why so many of them freeze up a year after launch and nobody wants to touch them.

A new fabric line should be a Tuesday afternoon for someone in operations, not a major project. When your options live in a simple list, it is.

Build the Hard Stuff Once, Use It Everywhere

The second part is the calculator. This handles the things a simple list can't.

Real rules. A shade has a minimum and maximum width. The amount of fabric depends on the exact size, which you can't list out because the sizes are endless. The price isn't a lookup. It's a calculation. That has to be actual software, because it's actual math.

We built exactly two of these calculators. One for the core product, one for accessories. Not five.

But here's the most important decision in the whole project. Both calculators hand back their answer in the exact same format. Every time. Line items, a parts list, and a price. Same shape, no matter which product.

That sameness is the trick. The rest of the system never has to know which calculator did the work. It asks for an answer and gets the same kind of answer every time.

Think of it like electrical outlets. Every appliance plugs into the same outlet. The toaster and the lamp work completely differently inside, but the plug is identical. That standard plug is what lets you add new appliances without rewiring your house.

When a new product family eventually earns its place through real sales, adding it is small. One new calculator. One new line in a lookup table. That's the whole job. The system was built to accept new parts, so adding one doesn't mean tearing the whole thing apart.

Most systems get harder to change as they grow. This one stays the same effort every time. One file, one row.

One Brain, Three Jobs

Here's where the design really pays off.

Because every calculator produces the same parts list in the same format, a single "parts brain" feeds three different parts of the business from one source of truth.

The customer-facing tool uses it to show what they're buying and what it costs. The ordering team uses it to know what materials to reorder. The intake team uses it to confirm an order can actually be built.

One parts list. Three uses.

Without this, you'd build that parts logic three separate times. Over months, the three versions drift apart. The website quotes one set of parts and the warehouse orders a different set. I've watched that gap sink real operations. Fixing it after the fact costs far more than building it right would have.

With one shared parts brain, there's nothing to drift apart. The customer sees the same parts the warehouse orders.

One honest limitation. A truly new product with a completely different cost structure may need real new work. That's fine. That's exactly the case where the sales have earned the investment. The goal isn't to make every product free. It's to make the products that fit your proven business nearly free, and give the genuinely new ones the attention they deserve when they prove they deserve it.

The Lesson

AI makes it trivial to generate software. That sounds like a pure win, but it changes how things go wrong. Before, over-engineering was expensive enough that budgets stopped it. Now you can spin up five unnecessary systems in an afternoon and feel productive. Then you spend two years drowning in the upkeep of code that serves products nobody buys.

The discipline that matters now is restraint. Let the data decide what to build. Design it so growth means adding a part, not performing surgery. Keep the easy stuff easy and the hard stuff in one place.

If you're staring at a product setup project and worried it'll become the expensive mess nobody wants to touch, the decision that prevents that happens before any code gets written. That's the work I do first, every time.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together