What I Learned from Building a Dev Tool
Reflections from building Configurator from scratch, balancing developer instincts with product ownership and user feedback.
This article was originally published on LinkedIn.
What do you learn when you build a developer tool from scratch—with no roadmap, no users, and no idea if anyone even needs it?
Last week, we announced Configurator in a blog post on saleor.io. If you’re curious about the tool itself, you’ll find the details there. This post isn’t about Configurator—it’s about what the process of building it taught me.
It’s been one of the most satisfying projects I’ve worked on, because it stretched me in ways I didn’t expect:
- I’d never built a CLI before, let alone a greenfield developer tool.
- I don’t know what Terraform is, and apparently we draw inspiration from it.
- I had to wear both the developer’s and the product owner’s shoes at the same time.
Here are the lessons I’m taking away:
Inside me, there are two wolves
I like to think of myself as a product-minded engineer, but Configurator was my humbling experience.
Building a tool that represents a new paradigm (managing commerce layer through code) —and has to find its place in the market—is both a creative person’s dream and a pragmatic person’s nightmare. You can go in almost any direction, and that freedom is exhausting.
As a developer, I wanted to shape Configurator exactly the way I would like to use it, forgetting that I wasn’t the target user—or that we didn’t even know who the target user was yet.
As a product owner, I wanted to avoid overcommitting. I wanted to serve real users. But how do you show value when there isn’t much substance yet? Navigating that tension was messy, but it taught me a lot.
Usually, I pick up a task that someone else has already decided is worth doing. With Configurator, there was no such safety net. We had to decide for ourselves whether it was worth building.
We should be talking about a human context window
Once the project structure was in place, a lot of the work came down to adding support for Saleor operations—mutations to create, edit, and manage data models. Repetitive work. Perfect for AI.
So we leaned on it. But Configurator was never anyone’s full-time focus, and we often came back to it after weeks away. With AI, you can generate a flood of code in hours. But what good is shipping a mountain of code you can’t confidently sign off on?
We had to slow down and resist the whisper: “just one more feature, bro—just one more prompt, bro”.
”As Code” ergonomics are forged in pain
Every product builder has a “before and after” moment: before you watch someone try your product in real time, and after.
When I saw the first user try Configurator, I felt like Cooper in Interstellar, knocking books off the shelf to point at the obvious.
It’s tempting to think, “I’m a developer, so I know what developers need.” But a CLI forces a thousand choices you can’t hand-wave away. What’s intuitive? What’s distracting? Where do you guide the user, and where do you get out of the way?
User testing gave us some answers, but boy, would I rather have my fingernails ripped out than go through it again.
Still, that tension—between product and developer instincts—is where the real lessons came from.
In the end, neither wolf won. They just merged into main.