I am Dennis Vercauteren.I design technical products, build configurators and make software around engineering.

That combination did not start as a planned specialisation. It grew out of how I work. If something has a lot of variation, I want to understand where that variation comes from. If a model has to be adjusted over and over, I want to know whether that can be done more intelligently. And if existing software does not capture the problem well, I would rather build something that fits.

I like to go deep enough to understand the technique, while still keeping the overview. What does the customer actually want to make? Where is the complexity? Which decisions belong in the product model? What should be automatic, and what should not?

That is usually where my role becomes interesting.

Black-and-white portrait of Dennis Vercauteren, with CAD dimensions over the face.
  1. Now

    building in order to understand

    I tend not only to think an idea through, but also to build it.

    3D Synth came from the question of how you can approach 3D-print toolpaths differently, with more freedom in the Z-axis.

    Openframe started with a simple question: can you 3D-print a bicycle frame, and what then has to change in material and construction?

    Inoxplus brings product configuration, geometry, price and quotation together for configurable stainless worktops.

    And with the geometry / semantics kernel I am looking at how a technical product can be described in a way that goes further than geometry alone.

    Not every experiment has to become a product. Building itself helps me see where an idea is strong, where it fails, and which layer is still missing.

  2. 2025

    Engineering in the browser

    WebGL made another step possible: technical geometry does not have to stay locked inside a CAD package.

    A product model, a configurator and an interactive 3D view can meet directly in a web application.

    That has led, in recent years, to several of my own projects and experiments.

  3. 2023

    Constraint-based CPQ

    With Tacton I went much deeper into constraint-based configuration.

    That was interesting because complex products are not always well captured by a long chain of if/then rules. Constraints, domains and relations give another way to structure that complexity.

    One of the projects I worked on was a highly configurable door system, with different layers, materials, fire requirements, locks, steel frames and specialised executions.

  4. 2019

    Product configuration

    Around 2019 I built my first real industrial product configurator.

    The problem shifted again. It was no longer only about a smart CAD model, but about a product with parameters, dependencies, rules and engineering output.

    The difference looks small, but it changed how I think. You are not just automating a model. You are trying to capture the knowledge behind the product.

  5. Parametric CAD and iLogic

    Autodesk Inventor iLogic changed how I looked at CAD.

    A model did not have to be static. Parameters, rules and logic could become part of the design. That made the step from drawing to automating feel natural.

    I was already experimenting with that before I started building full product configurators.

  6. 2012

    Kubuz

    I started working independently under Kubuz.

    The first years were strongly about mechanical design: stairs, platforms, commercial-kitchen equipment and other technical constructions and machines.

    In the same period, parametric CAD became more important. Not only drawing a model, but thinking about how the model itself could absorb variation.

  7. 2011

    3D printing

    I started with 3D printing while desktop printers were still fairly experimental.

    Then it was almost a discipline on its own. Today I see it mainly as a tool. A fast way to test a shape, make an idea physical, or push a concept further.

  8. 2008

    Mechanical design

    I started professionally as a drafter and CAD designer.

    That is still my technical base: real parts, assemblies, production drawings and designs that eventually have to be made.

That combination did not start as a planned specialisation. It grew out of how I work. If something has a lot of variation, I want to understand where that variation comes from. If a model has to be adjusted over and over, I want to know whether that can be done more intelligently. And if existing software does not capture the problem well, I would rather build something that fits.

I like to go deep enough to understand the technique, while still keeping the overview. What does the customer actually want to make? Where is the complexity? Which decisions belong in the product model? What should be automatic, and what should not?

That is usually where my role becomes interesting.

How I like to work

I like projects where technique, product knowledge and software run through each other.

Often the most useful thing I can do at the start is not coding or drawing, but taking the product and the process apart. Where does the variation come from? Which information already exists? Who takes which decision? What output finally has to come out?

After that the solution can look very different: a parametric CAD model, a configurator, a piece of automation, a web application, or simply a better-built engineering flow.

I try not to build more software than needed.

Work and experience

This site mainly shows projects, ideas and technical pieces that explain how I work.

My full career does not need to sit next to that. LinkedIn is better for that, and I am happy to send a CV when it is relevant.

LinkedIn · CV available on request