Fabrikatör builds inventory planning software for e-commerce brands: demand forecasting, purchase orders, replenishment, and analytics, sold mainly to Shopify merchants. Data is the product. We spoke with Demirhan Aydın, Co-founder and CTO, about why a company that already runs its own data pipelines built its newest product on Bruin, and what he took away from a year and a half in production.

A new product, a fresh start

Fabrikatör's existing application runs on a pipeline the team built themselves, with their own tooling. When the company set out to build a second application for larger customers, Demirhan wanted to leave the old structure behind and take the data layer seriously from day one.

His first prototype was built on dbt. The transformation part worked, but everything around it was missing. He needed to run the pipeline, orchestrate it, validate it, connect it to CI, and observe it. Each of those meant another tool.

Decision points for choosing Bruin

Demirhan had known Bruin's founders, Sabri and Burak, since the early days of the company. As founders in the same city and a related space, they had traded ideas long before Fabrikatör became a customer. When the dbt prototype started sprawling, he pinged them.

What convinced him was the demo: seeing the layers and structure of the pipeline, running tests inside the IDE, and orchestrating everything from the same place.

“Seeing the structure, running the tests inside the IDE, and orchestrating it yourself was a big relief. We were more secure, and we realized we could move quickly by dealing with Bruin instead of three or four tools.“

Bruin's open-source core mattered as well. The pipelines are plain SQL, Python, and YAML that the team owns and can run anywhere, so committing to the tool never meant committing to a black box. It is also why he tells other founders they can start on Bruin before they subscribe to anything.

“Having the open-source part is definitely a plus. I know the job, and with one tool or another it is the same work. You don't think about which brand a knife is when you're using it. It works.“

How Fabrikatör used Bruin

Bruin ran both Fabrikatör's internal analytics and the customer-facing pipelines that generated answers inside customer data warehouses managed by Fabrikatör. The most distinctive use, though, was as a semantic layer.

Fabrikatör's application lets merchants ask questions like "what was my revenue last year" or "what is my stockout ratio", which an AI agent turns into SQL and runs against the customer's warehouse. The problem is that revenue means something slightly different to every customer, and handing the agent a raw database schema is not enough to get it right.

So the team took the documentation Bruin already keeps next to each asset: column descriptions, accepted values, validation checks, plus custom keys they added to describe columns further. They compiled those definitions into a semantic layer and injected it as context for the agent.

“Instead of just giving the schema to the SQL agent, we took the definitions from Bruin. We already had the accepted values and the validation checks there, and we injected our own custom keys to express each column. We put all of that in as context, so the agent writes better SQL for each customer.“

“Back then everything was scattered. You have Markdown files, but they are somewhere else and they are not up to date. Having the definitions live on top of the SQL was eye-opening for us.“

Impact of Bruin

Because the new product started on Bruin from day one, Demirhan is careful not to claim cost savings he cannot measure. What he can speak to is time, in two places.

Onboarding a new engineer. Bruin was a tool no data engineer on the market had used before, and Demirhan expected that to slow down hiring someone to own the pipeline. It did not.

“Bruin was a new tool that nobody had experience with, so I expected onboarding to be hard. Within a week the new person was already there. It was way easier than I expected.“

Fixing pipeline issues faster. The team built automation on top of Bruin: whenever an asset failed, their own agent picked it up, ran it on a development server, and opened a pull request with the fix. Bruin has since released a similar capability natively.

A partner, not a vendor

Fabrikatör raised feature requests and problems in a shared Slack channel with Bruin.

“I don't remember a time where we had a problem and no one showed up. They were honest and transparent. We were sleeping better.“

“I count them as a partner, because we were doing the business together. In the end I'm responsible for my customers, and I'm their customer.“

His advice to other founders is to start earlier than feels necessary.

“I'm already advocating Bruin to other founders. If you have any kind of data job, after the second asset you should already be using it, because otherwise it gets complicated. Invest as early as possible. You don't even have to subscribe. Use it as an open-source tool to start.“

Tangible Benefits

• The full pipeline lifecycle in one place. Transformation, orchestration, validation, CI, and observability together, with no stack to assemble around dbt.
• Definitions that power an AI product. Bruin's asset documentation, accepted values, and checks became the semantic layer behind Fabrikatör's customer-facing SQL agent.
• Faster onboarding. A new engineer was productive on the pipeline within about a week, despite the tool being new to them.
• Quicker fixes. Failed assets were picked up by automation and returned as pull requests, a pattern Bruin has since shipped natively.
• Open source at the core. Plain SQL, Python, and YAML the team owns, with no black box, and the reason he tells other founders to start on the open-source tool before subscribing.

Conclusion

Fabrikatör came to Bruin with a dbt prototype that was not ready for production and a clear idea of what was missing around it. Bruin filled that gap, and a new engineer was working on the pipeline within a week. Along the way, the team found a second use nobody had planned for. The column descriptions and checks they wrote in Bruin became the context that let their AI agent write correct SQL for each customer.