Building a Manufacturing Floor From the Ground Up
When product configuration becomes an engineering problem: how Vantis Shade Systems moved tube deflection, roll diameter and spring selection into the product definition, so the shop floor receives the answer.
By Matthew Weber · · 10 min read
Designing a manufacturing operation from the ground up sounds, at first, like a physical challenge.
You need equipment, workstations, material flow, inventory locations, quality-control processes, and production scheduling. People need to know what to build, where to build it, and what happens next.
When we began designing the manufacturing floor for Vantis Shade Systems, all of those things mattered.
But we quickly discovered that one of the hardest problems wasn't actually on the manufacturing floor.
It was figuring out exactly what needed to be manufactured.
For a highly configurable product like a window shade, that turns out to be a surprisingly difficult software problem.
A Shade Isn't Just a List of Options
From the customer's perspective, ordering a shade seems straightforward:
- Enter a width and height.
- Choose a fabric.
- Choose a control type.
- Select a few options.
From an engineering perspective, those selections can change nearly everything about the product.
Width can affect the tube, brackets, fabric dimensions, finished roll diameter, and whether the shade can physically be manufactured. Different fabrics have different densities, thicknesses, and available roll widths, affecting shade weight, roll diameter, tube load, and hardware requirements.
The control system introduces another set of variables. A motor, chain clutch, and spring-assisted touch-lift system have entirely different component and engineering requirements.
And these aren't always simple rules like:
If width is greater than 96 inches, use Tube B.
The correct answer might depend on width, height, fabric density, fabric thickness, control type, tube rigidity, shade weight, and roll diameter—many of which are themselves calculated from other values.
The Difference Between Configuration and Engineering
Most product configurators are good at configuration.
They can answer whether an option is available, what colors can be selected, what something costs, or which SKU should be added.
Manufacturing requires us to answer a different class of questions.
At Vantis Shade Systems, width and height aren't simply dimensions on an order. They help determine the physical characteristics of the shade.
Our product definition doesn't just know which fabric a customer selected. The fabric catalog contains engineering properties such as density, thickness, maximum roll width, and whether the material can be railroaded. Even different openness factors within the same fabric family can have different physical properties.
The system calculates actual fabric dimensions, including material required to wrap the roller tube and finish the hem bar. Those dimensions determine fabric area; area and density determine fabric mass; that mass combines with the tube and hem bar to determine the load carried by the roller tube.
We've gone far beyond:
"Customer selected Fabric A."
We're describing the physical object we're about to manufacture.
Why Traditional Configuration Systems Struggle
Before finding Painless Manufacturing, the approaches available to us generally fell into two categories.
The first was predefined values and rules:
Width 0–72" → Tube A
Width 72–120" → Tube B
Width 120"+ → Tube C
But that's not necessarily how the engineering works.
Perhaps Tube A works at 80 inches with one fabric but not another. Changing the fabric changes weight and roll diameter. Changing the drop changes how much material is on the tube.
You can keep adding ranges, exceptions, and lookup tables, but eventually you're no longer modeling the product.
You're approximating it.
The other approach is formulas, often placed in fields and rules that become increasingly difficult to understand:
IF(A12 > 120 AND B7 = "MTR-4", ((A12 - C3) * D18) + E2, ...)
Technically, it works.
Practically, you've hidden part of your engineering department inside a formula field.
Six months later, someone has to figure out what C3, D18, and E2 mean—and why changing one affects a seemingly unrelated component.
When a Product Definition Starts Doing Engineering
One of my favorite examples from the Vantis Shade Systems product definition is tube deflection.
A roller tube is effectively a beam carrying a distributed load. As a shade gets wider and heavier, that tube will deflect. Too much deflection can create problems with the finished shade.
A traditional system might solve that with another table:
Up to X inches → 1.5" tube
Above X inches → 2" tube
But width isn't actually what we're concerned about.
We're concerned about deflection.
So why not calculate it?
The product definition knows the flexural rigidity of the selected tube. It calculates the load being placed on it and the expected tube deflection using the distributed-load beam equation, then expresses that result as a percentage of shade width.
The configuration can validate that result:
Calculated Tube Deflection
↓
Compare Against Allowable Deflection
↓
Within Limit?
↙ ↘
Yes No
↓ ↓
Continue Increase Tube Size
or Reduce Load
Here's how that looks in the product definition's engineering block:
engineering do
constant :gravity, 9.81, unit: "m/s²", label: "Gravity"
constant :max_deflection, 0.10, unit: "%", label: "Deflection limit"
#
# LOADS & TUBE
#
calc :tube_load, unit: "g", label: "Tube load" do
tube_mass + fabric_mass + hembar_mass
end
calc :tube_ei, unit: "N·m²", label: "Flexural rigidity (EI)" do
tube_map&.[](:flex) || 0
end
calc :load_inertia, unit: "N·m", label: "Rotational inertia" do
(((tube_load - tube_mass).to_i * gravity * 19.05) / 1000000).round(2)
end
limit :tube_deflection, label: "Tube deflection" do
value :eng_deflection_percent
warn_at 0.925
max :max_deflection
condition -> { tube_size.present? }
fields :width
message "Tube load exceeds parameters. Increase tube size or reduce load (width)"
end
limit :roll_size, label: "Spooled roll diameter" do
value :spooled_diameter
max :max_roll_diameter
fields :length
message "Spooled roll diameter exceeds system capabilities. Use a larger system or bracket"
end
end
We're no longer asking:
"Have we declared this combination valid?"
We're asking:
"Does this shade satisfy the engineering constraint?"
That's a fundamentally different approach.
Then It Gets More Complicated
Touch-lift shades provide an even better example.
Selecting the appropriate spring isn't simply a matter of knowing the shade's width or weight.
The system calculates the roller revolutions required based on tube diameter, fabric thickness, and shade length. It then determines how the effective radius changes as fabric moves on and off the tube.
Because torque depends on radius, the required torque changes throughout the shade's travel.
The result looks more like an engineering model:
Shade Dimensions + Material Properties
↓
Required Roller Turns
↓
Changing Roll Radius
↓
Torque Through Travel
↓
Ideal Spring Rate
↓
Candidate Springs
↓
Selected Spring + Pre-Turns
The product definition compares that demand against physical springs with properties such as spring rate, maximum turns, maximum torque, and minimum shade width.
Springs that can't handle the width, required turns, or peak torque are eliminated. The remaining candidates are ranked against the calculated ideal spring rate, and the system calculates the appropriate pre-turns.
And this happens while the shade is being configured.
Representing that cleanly in the systems we evaluated before Painless was extraordinarily difficult.
The Dependency Problem
Once calculations depend on other calculations, you're no longer dealing with isolated formulas.
You're dealing with a dependency graph:
Width + Mount Type
↓
Finished Width
↓
Tube Width
↓
Fabric Width
↓
Fabric Area ← Fabric Length
↓
Fabric Mass ← Fabric Density
↓
Tube Load
↓
Tube Deflection
The same inputs simultaneously feed calculations for roll diameter, component selection, spring requirements, costs, and manufacturing dimensions.
Changing one value near the beginning can affect dozens downstream.
That realization changed how we thought about product configuration.
We weren't trying to create a database containing every possible shade.
We needed a system capable of describing how a shade behaves.
Why Real-Time Calculation Matters
Doing all of this engineering after an order is submitted would be considerably easier.
But that's not what we wanted.
When someone changes a shade from 96 to 120 inches wide, that isn't merely a database field changing.
That change can propagate through the entire product:
Width
↓
Fabric Dimensions
↓
Fabric Mass
↓
Tube Load
↓
Tube Deflection
↓
Roll Diameter
↓
Component Selection
↓
Manufacturing Instructions
Changing the fabric can cause a similar cascade because the selected material provides its own density, thickness, and maximum width.
The product definition even calculates finished spooled diameter from fabric length, thickness, and tube diameter, then validates whether that roll can physically fit within the selected system.
There isn't really a single "engineering calculation."
There's a network of calculations whose inputs and outputs depend on one another, and they need to resolve quickly enough that the person configuring the shade doesn't know any of this is happening.
They simply see that a configuration is valid—or that it isn't.
Finding Painless
Finding Painless Manufacturing fundamentally changed what we thought was practical.
Instead of treating engineering calculations as scattered configuration rules, Painless allowed us to treat them as a first-class part of the product definition.
Instead of enumerating every possible finished shade, we can describe the relationships that determine one.
Straightforward inputs such as:
Width
Height
Fabric
Control Type
Mount Type
Presentation
Tube Size
can produce:
Fabric Dimensions
Fabric Mass
Tube Load
Roll Diameter
Tube Deflection
Required Torque
Spring Selection
Cut Dimensions
Those calculated values can then become inputs to further calculations, validations, component selections, and manufacturing operations.
The result begins to resemble an engineering model rather than a traditional configurator.
From Engineering Calculation to Factory Instruction
This is where Painless became especially interesting while designing the Vantis Shade Systems manufacturing floor.
The calculations don't stop at determining whether we can manufacture the shade.
The same product definition tells us how to manufacture it.
Calculated tube width becomes the cut length sent to metal cutting. Calculated fabric dimensions become instructions for textile cutting. A cassette configuration introduces operations that don't exist for other presentations.
For a touch-lift shade, all of the calculations around weight, roll diameter, torque, and spring selection can eventually become instructions as simple as:
Pick Easy Spring Unit
Set spring to position 17
Pre-turn spring to 8.5 turns
The assembler doesn't need to calculate torque or consult a spring chart.
The system has already translated customer configuration into engineering, engineering into component selection, and component selection into manufacturing instructions. The workflow carries the calculated spring family, position, and pre-turn count directly to assembly.
The engineering complexity belongs in the product definition. The manufacturing floor should receive the answer.
From Product Configurator to Manufacturing Engine
That changed how we thought about the entire system.
Vantis Shade Systems isn't simply selecting SKUs.
It's evaluating a product.
Customer Configuration
↓
Engineering Model
↓
Validated Product
↓
Component Selection
↓
Bill of Materials
↓
Manufacturing Processes
↓
Work Instructions
↓
Finished Product
Even packaging becomes part of that model. The product definition calculates shipping dimensions and weight, length-plus-girth, oversized status, and whether the finished package falls within common-carrier limits.
The same definition that begins with a customer entering width and height can ultimately influence how the shade is engineered, manufactured, packaged, and shipped.
The Manufacturing Floor Becomes the Output
This led to perhaps the most important realization we had while building Vantis Shade Systems:
The manufacturing floor doesn't need to contain all of the knowledge required to build the product.
The product definition can contain that knowledge.
An operator shouldn't have to memorize that a particular fabric, width, control system, and mounting configuration requires a certain tube, bracket, deduction, or spring.
They shouldn't need an engineering spreadsheet beside their workstation.
The system already knows.
The operator needs to know what to do next.
That lets us design manufacturing around clear instructions, repeatable processes, and verification rather than institutional knowledge.
The complexity hasn't disappeared.
We've moved it somewhere that can evaluate it consistently.
Building From First Principles
Building a manufacturing operation from scratch is intimidating because there isn't an existing process to copy.
But that also became one of Vantis Shade Systems' greatest advantages.
We weren't forced to recreate workflows simply because that's how they've always been done.
We could ask more fundamental questions:
Why does an operator need to make this decision?
Why is this value manually calculated?
Why does someone need to remember this rule?
Why can't the system determine it automatically?
Increasingly, the answer was that it could.
Before finding Painless, accurately modeling the engineering characteristics of a shade in real time felt somewhere between impractical and impossible without building substantial custom software ourselves.
The alternatives generally forced us toward one of two compromises: simplify engineering into rigid tables and predefined limits, or encode increasingly complicated formulas into systems that weren't really designed to describe how a physical product behaves.
Painless gave us another option.
We're not trying to teach software every possible shade Vantis Shade Systems can manufacture.
We're teaching it how a shade works.
Once the system understands that, designing the manufacturing floor becomes a very different problem.
Instead of building a factory around complexity, we can build one around the instructions produced by a system that already understands it.