BricoWerx's Story
BRICOWERX
BricoWerx began in June with an idea from ScienceWerx CIO Bassem Kadry: build a reusable "LEGO set" of features and modules so the company stops rebuilding the same functionality across different products. Senior Analyst Youssef Ali identified the core challenge features are built to fit the specific system design and tech stack of their original project and designed the first component to solve it: the Adapter Engine. Trained on a variety of system designs and engineering decisions, the Adapter Engine detects how much of an existing feature can be reused and adapts it to fit a new product's system design and stack, laying the technical foundation for BricoWerx as a true library of reusable, cross-stack software components.
From idea to company.
The Idea & Negotiation
The **ideation phase** is essentially the opening part of the story—before the Adapter Engine becomes the technical solution. I’d extract it like this: ### Ideation Phase — BricoWerx The idea for **BricoWerx** started in June from a simple observation by Bassem Kadry, CIO of ScienceWerx: across different products, the team was repeatedly building many of the same capabilities—permissions, notifications, content editors, user management, and other common modules—from scratch. That led to a simple question: > **What if ScienceWerx had its own LEGO set for software development?** Instead of rebuilding the same functionality for every new product, the team could create a shared library of reusable features and modules. Developers could pull existing pieces from that library and assemble them into new products, reducing development time, duplicated effort, and cost. The initial concept was straightforward: **Build once → Store it → Reuse it → Adapt it → Deploy it again.** However, the team quickly identified the core challenge behind the idea. Unlike LEGO bricks, software components do not naturally fit together. Each feature is usually created around a specific application's architecture, data model, technology stack, coding conventions, and engineering decisions. So the ideation evolved from simply asking: **“How can we create a library of reusable software modules?”** to a more important question: **“How can we make software built for one system intelligently reusable in another system?”** That realization defined the real opportunity behind **BricoWerx**: not merely a repository of reusable code, but an intelligent platform capable of identifying, adapting, and reassembling existing software components across different products and technology stacks. From that ideation came the first foundational concept for BricoWerx: the **Adapter Engine**.
Testing & Using Internally
The first step was to validate whether the problem we had identified was real and significant enough to solve. We reviewed products across the ScienceWerx portfolio and looked specifically for repeated functionality. The pattern was clear: permissions systems, notification modules, content editors, user management tools, and other common features were being rebuilt again and again across different projects. That confirmed the first assumption: **we were duplicating development effort.** The next step was to test whether the obvious solution — simply reusing existing code — would work. We compared similar features across different products and quickly found that reuse was not as simple as copying a module from one system into another. Even when two features performed the same function, they were often built around different data models, architectures, frameworks, conventions, dependencies, and engineering decisions. That confirmed the second assumption: **the problem was not the lack of reusable code. The real problem was the lack of a way to adapt reusable code across different systems.** This changed the direction of the project. Instead of building only a repository of components, BricoWerx needed a layer that could analyze an existing feature, understand how it was built, determine what parts were reusable, identify what needed to change, and translate that feature into the structure of another product. That validation led directly to the core hypothesis behind the Adapter Engine: **If we can identify the underlying pattern of a software feature independently of the product it came from, then we can determine how much of that feature can be reused and what is required to make it work somewhere else.** The validation phase therefore established three things: * The duplication problem existed across real ScienceWerx products. * Simple code reuse alone would not solve it. * Intelligent adaptation was the missing layer needed to make reuse practical. That became the foundation for designing the Adapter Engine and moving BricoWerx from an idea into a testable product concept. I can also make this more **technical**, more **lean-startup style**, or more like a **formal product validation document**.
Porting & Creating Sub-Tools
Once the problem had been validated, the next step was to build the first system capable of solving it. Rather than starting with a full reusable-component marketplace or a large library of software modules, the team focused on the most important technical challenge first: adaptation. That led to the development of the Adapter Engine as the first core component of BricoWerx. The Adapter Engine was designed to analyze an existing software feature and understand how that feature was constructed. It examines the feature’s structure, dependencies, data relationships, architectural patterns, and implementation decisions to determine how portable that feature really is. The goal was not simply to copy code from one project to another. The goal was to make the system capable of answering three practical questions: What part of this feature can be reused as-is? What part needs to be modified? What changes are required for the feature to work inside a different product or technology stack? To support that process, the system was designed around real software architectures rather than a single standardized project structure. The Adapter Engine needed to recognize that different products may solve the same problem in very different ways. This meant building the engine to identify the underlying functional pattern of a feature, separate that pattern from its original implementation, and then determine how it could be translated into another system. The first build therefore focused on creating the intelligence layer behind BricoWerx. Instead of beginning with the LEGO box, we began with the mechanism that makes the LEGO pieces compatible. That build established the technical foundation for everything that comes next: a reusable module library, component discovery, automated adaptation, cross-stack deployment, and eventually a broader system for assembling software products from existing capabilities. The Adapter Engine became the first working expression of the BricoWerx concept turning the original idea of reusable software into something that could actually be tested, improved, and expanded.
Introducing
With the Adapter Engine built as the foundation of BricoWerx, the next step was to move the concept out of development and into real use. The launch was designed as an internal deployment across ScienceWerx projects rather than a broad external release. The goal was simple: prove that BricoWerx could work against real products, real codebases, and real engineering constraints. The first launch phase focused on introducing the Adapter Engine into existing ScienceWerx development workflows. Instead of asking teams to change how they built products from day one, BricoWerx was positioned as an intelligence layer that could analyze what had already been created and identify opportunities for reuse. Existing modules and features became the first test library. The Adapter Engine could examine those components, identify similarities across products, estimate what could be reused, and determine what modifications would be required before a feature could be transferred into another system. This turned the launch into more than a product release. It became a live validation environment. Each project gave BricoWerx more examples of how software features were structured, where reuse worked, where adaptation failed, and what patterns appeared repeatedly across different architectures and technology stacks. The launch also created the foundation for measuring the value of the platform. Instead of evaluating BricoWerx only by whether a component could technically be reused, the team could begin measuring: development time saved percentage of code successfully reused reduction in duplicated engineering work adaptation time compared with rebuilding from scratch reliability of adapted components number of reusable modules identified across the portfolio These measurements would determine how BricoWerx evolved. The initial launch was therefore not intended to represent the final version of the platform. It was the beginning of a continuous cycle where every real deployment would generate new knowledge, improve the Adapter Engine, and expand the reusable component library. What started as an internal question — “Why are we building the same things again?” — had now moved through ideation, validation, and development into a working system being tested against real products. BricoWerx had moved from concept to infrastructure. And from that point forward, every product built inside ScienceWerx had the potential to make the next product faster to build.
It started in June with a simple question from my manager, Bassem Kadry, CIO of ScienceWerx.
Across our portfolio of products, Bassem had noticed a recurring pattern: we were building many of the same features again and again, just in different forms. A permissions system in one product. A notification module in another. A content editor somewhere else. Each one was built from scratch and customized for the project it lived in, even though the underlying problem had already been solved before.
That led to a deceptively simple idea:
What if we had our own LEGO set for software development?
A place where we could store the features and modules we had already built, then pull them into future products instead of starting from zero every time.
As a Senior Analyst at ScienceWerx, I immediately saw the potential. If we could reuse what we had already created, we could reduce development time, avoid duplicated effort, and build new products much faster.
But before treating the idea as a solution, we needed to validate the problem.
We looked across our existing products and confirmed that the duplication was real. The same types of capabilities were being rebuilt repeatedly across different projects. The problem was not hypothetical; it was already embedded in our development process.
The next question was whether we could simply take a feature from one product and reuse it in another.
That was where the real challenge appeared.
Software components are not like LEGO bricks. A LEGO brick works because every piece follows the same connection system. Software does not.
A feature is usually designed around the specific product it was created for: its data model, architecture, coding conventions, technology stack, and the engineering decisions behind it.
Two features may perform the same function and still be completely different underneath.
So we validated something even more important: a simple library of reusable code would not solve the problem.
The idea had to evolve.
The question was no longer:
“How do we create a library of reusable software modules?”
It became:
“How do we make software built for one system intelligently reusable in another?”
That shift became the foundation of BricoWerx.
The name came from “Bricolage,” the idea of building something new by assembling pieces that already exist. BricoWerx would become the place where those pieces could live, be understood, adapted, and reused.
But to make that possible, we needed one critical capability first.
Before building the LEGO set, we needed something that could look at a pile of mismatched pieces and understand which ones were actually versions of the same thing.
That became the Adapter Engine.
The Adapter Engine was designed to analyze a feature built for one product and understand its structure. Instead of assuming that every project follows the same architecture, it looks at the underlying design patterns and engineering decisions behind the feature.
From there, it can determine what percentage of the feature can be reused as-is, what needs to be modified, and how the feature could be adapted to work within a different technology stack or system architecture.
In simple terms, the Adapter Engine answers three questions:
What can we reuse?
What needs to change?
And how do we make it fit?
That is the core idea behind BricoWerx.
What began as a question about avoiding repeated development evolved, through validation, into something much larger: an intelligent system for recognizing, adapting, and reusing software capabilities across products.
And the Adapter Engine is the foundation everything else in BricoWerx will be built on.
If you want, I can also make this sound more like a **startup case study**, an **innovation journey**, or a **founder-style narrative**.