custom cet extensions

More of your products, fewer errors.

When your CET extension reflects how your product actually works, users specify it confidently, and your factory receives orders it can build. No corrections. No callbacks. No revenue left on the table because the software got it wrong.

What we do.

How your team says it

“If they configure it that way, the whole thing tips over.”

How the extension knows it
if config.load > base.threshold
then block(config)
// structural instability
We speak both languages, so your team doesn’t have to.
What “custom” actually means

Your rules don’t live in a spreadsheet. They live in your team.

The knowledge that runs your business lives in your people. In the rules your engineers know by heart, the exceptions your sales reps navigate daily, and the processes that have always just been done a certain way.

 

We take that knowledge and turn it into something your whole team can use. Custom doesn’t mean complicated. It means the extension knows what your engineers know.

HOW WE GET THERE

We learn your product the way your best engineer knows it.

We start with your real product.

Every extension starts the same way. Not the catalog version of your product. The real version, with the exceptions, the edge cases, and the configurations that only exist in someone’s head until we write them down.

We build the logic behind it.

From there we build logic that reflects how your product actually works. Rules that guide users toward valid configurations. Constraints that prevent mistakes before they happen, including the ones that cause real-world failure.

It enforces what your team knows.

When it’s done, the extension enforces what your team already knows, without anyone having to remember it.

The plan

Three steps to a working extension.

Week 1

Tell us about your product.

A working session with your engineers. We pull the rules out of their heads, including the pricing exceptions and the configurations nobody ever wrote down. We ask until there is nothing left to uncover, and we start with the product that needs to be in CET first.

Weeks 2–X

We build it. You break it.

We build against your actual product, not a demo. Then you test it on the configurations that have always caused problems. Edge cases, exceptions, the ones your team navigates by instinct. Nothing ships until it holds.
Launch and ongoing

You launch, and we stay on.

Your users configure your product without calling anyone. Orders come in clean, and your team stops being the safety net between the software and the factory floor. New products, price increases, and new rules are handled too. Most clients spend 20% or less of their budget on maintenance.

The questions we get before every project.

We do one thing. CET extensions, built to the highest standard we know how to achieve. That singular focus means we’re not splitting our attention across different platforms. Every insight we’ve developed, every edge case we’ve navigated, every lesson that came from a hard project goes back into how we build the next one. That compounds over time in ways that are difficult to replicate without the same depth of commitment.

 

We also specifically seek out complexity. Manufacturers with straightforward product lines have plenty of options. Manufacturers with genuinely difficult products — layers of rules, configurations that interact in non-obvious ways, edge cases that have to be handled correctly or the whole thing falls apart — that’s where we do our best work. We’ve built solutions across commercial interiors, laboratories, material handling, demountable walls, and more. If your product is complicated, we’ve likely encountered something like it before. If we haven’t, that’s not a reason to hesitate — it’s the kind of problem we lean into.

 

What that translates to practically is a partner who already speaks your language before the first meeting. We don’t need to learn CET for your project. We don’t need to figure out what’s possible. We spend that energy on understanding your product and building something your users will actually want to use.

The honest answer is that it depends on your product and how deeply your extension gets adopted — but the returns tend to show up in two distinct ways, and both multiply over time.

The first is revenue. A well-built extension puts your products in front of thousands of active specifiers who are already in CET, already working on projects, and already making buying decisions. When your products are easy to work with and your competitors’ aren’t, designers spec yours. They don’t need to be sold. They don’t need to be trained. The software guides them through the complexity so they don’t have to understand all of it themselves. For manufacturers with complicated products — conveyor systems, demountable walls, high-density storage, anything with layers of rules and configurations — that’s a significant unlock. You stop being the product that requires a specialist and start being the product that anyone can specify confidently.

The second is operational. Accurate orders. Fewer errors reaching your factory floor — and fewer errors reaching the people selling your products. When a configuration mistake is made, the result can erode relationships, complicate reorders, and quietly undermine people’s confidence in specifying your products at all. A well-built extension reduces errors on both ends of the transaction simultaneously: your factory receives cleaner orders, and your sales channel stops eating the cost of avoidable mistakes. Those savings don’t show up on a single invoice, but they accumulate quietly and consistently from the moment your extension goes live. The more complex your product, the more those hidden costs have been dragging on margins across your entire channel — and the more dramatically a great extension makes them disappear.

Most manufacturers start seeing meaningful returns within three to five years of launch. The ones who see it fastest are usually the ones whose products were hardest to specify before. Complexity that used to be a liability becomes an advantage when the software handles it for you.

That depends heavily on your product line — how complex it is, how many configurations exist, and how deep you want the experience to go. Most projects land somewhere between six months and a year, but that range doesn’t tell the whole story.

 

What we’ve found is that the time you invest upfront pays for itself many times over. We build extensions that feel right the first time a designer or engineer uses them — not something that ships rough and improves over the next several versions. That means we ask harder questions earlier, work through the complexity before it becomes your users’ problem, and don’t hand you something that needs constant attention after launch. The manufacturers who’ve taken that approach with us don’t just have a better extension — they have something that keeps working for them years down the road without requiring much from them at all.

 

If you’re thinking about this as a project with a finish line, we can talk timelines. But the manufacturers we work with best tend to think about it differently — less as a one-time build and more as a long-term asset that earns its keep every time a designer specifies their product instead of a competitor’s. That’s the kind of return that compounds over two or three years in ways that are hard to see from the starting line.

 

When you’re ready to talk specifics, we’ll give you a real estimate based on what we’re actually building — not a number pulled out of thin air.

Less than you might think to get started, and more than you’d expect to get it right.

Every manufacturer we work with stores their product information differently — spec sheets, engineering drawings, price lists, tribal knowledge that lives entirely in someone’s head. We’ve seen it all, and we adapt to whatever you have. Getting started doesn’t require a perfectly organized data package.

What it does require is access to the people who genuinely understand how your products work — not just how they’re marketed, but how they go together, what’s allowed, what isn’t, and why. That might be an engineer, a veteran sales rep, a product manager, or someone on your factory floor. Title doesn’t matter. What matters is that we can get to the real product knowledge, because that’s exactly what makes the difference between an extension that feels authoritative and one that feels like it’s guessing.

The more openly your team can share that knowledge with us — and the more available they are when questions come up — the faster we can turn it into something your customers and specifiers will actually want to use. That collaboration is where the quality comes from. We do the heavy lifting on our end, but we can only build what your products actually are. The better we understand them, the better the experience your designers and engineers will have on day one.
In their words

From the people we build for.

Filter by what mattered most to them.

Testimonial Preview

swipe to browse

Scroll to Top