Matik exists because customer-facing teams spend too much time assembling things rather than deciding what they should say. Thirty decks with the same structure every quarter, and very little time left for what each of those customers actually needs to hear.
The answer was always to make that work deterministic: build the template once, connect it to real data, and the thirty decks produce themselves. AI came in where determinism runs out, getting a template built in the first place, and the parts that call for judgment rather than repetition. But only so far. What can be made reliable should be, so the person is left deciding and reviewing rather than producing.
That belief is easy to hold about other people's workflows. It is harder to apply to your own.
Over the past several months, I rebuilt how design and engineering work together at Matik, using the same reasoning we apply to our customers' problems. This is what happened.
Every software company has the same seam running through it: designers decide how the product should look and behave, engineers build it, and something has to carry the intent between them.
That something is the handoff. Design files, written specs, annotated prototypes, review documents. An enormous amount of effort goes into making the translation faithful.
And the industry has spent decades improving it. Better tools. Tighter specs. Smarter integrations. Even Figma's most recent announcements are, at their core, another attempt to make the translation smoother.
But a translation can never be as good as speaking the same language.
This was never a problem I had stopped noticing, and I was not the only one. Engineering felt it too, and said so.
The cost showed up in specific places. Engineers spent cycles interpreting design intent instead of building product logic. We had design guidelines alongside the Figma files and it still fell short, partly because Figma was never their environment. Several found it hard to navigate even in dev mode, which is fair enough.
Details drifted between what was designed and what shipped. I wrote design review documents describing fixes I could have made myself in less time. And our component library, the thing that should have kept the product coherent, had no owner, because every engineering hour was already spoken for.
There was a subtler cost too. We had a component library in Figma and a component library in code. Two systems, meant to mirror each other, drifting apart a little more with every sprint. I kept the Figma one in good shape, which honestly made things worse: the gap between the two was visible every time something shipped.
Designing in code has always been possible in theory. In practice it required a level of technical fluency most designers do not have time to maintain alongside research, strategy, systems work, and everything else the role demands.
That is exactly the kind of barrier AI is good at lowering.
I had always been drawn to the frontend, I started my career when teams were still writing pixel values on static mocks, but never had the capacity to make the switch on my own. AI-assisted tooling changed that. You do not need to write perfect code to start. You need enough judgment to know what good looks like, and a way in.
So I stopped opening Figma and started designing directly in Storybook, in our real codebase, with our real components.
The important part is not that I learned to work in code. It is what stopped. My version of producing was translating: files, specs, prototypes, review documents, all of it describing a product that did not exist yet so someone else could build it. Now the deciding and the making are the same act, and the translating step is gone.
Exploration did not change. Analysing feedback and the data we already have, writing, pen and paper, quick AI prototyping tools to feel out ideas. No components, no branding, just thinking about the problem. This is still where most of the design work happens, and it should be.
Building moved into the codebase. When it is time to make something real, I open Cursor and build in Storybook using our actual frontend components, extending existing ones or creating new ones as needed. Real components, real data, one source of truth.
The prototype became the handoff. This is the part that changed everything. I build the interface where the product actually lives, so there is nothing to translate. For smaller work, I open a pull request directly and it ships after code review. For larger features, I build the interface in Storybook, validate it with users and stakeholders, and then hand the branch to an engineer who wires it to the backend.
Designing in the codebase also forces better thinking. Component structure, technical constraints, edge cases, accessibility, you cannot defer them to a later phase when the later phase is the same phase.
They also become much more obvious. In a design file you have to remember to think about the empty state, the long name, the slow response. In something working, you run into them.
I spend more time deciding and less time producing. This is the result that matters most and the one people find hardest to believe. Removing the translation work did not turn me into an engineer, it gave me back the hours that used to go into describing things. More research, more strategy, more exploration. The implementation loop got shorter, so the thinking loop got longer.
Engineering ships faster. Not because anyone works harder, but because an entire category of work left their plate. UI implementation is done before the branch reaches them. They connect it to real systems, which is what they are best at anyway.
"Life changing."
"Ever since you started designing directly in Storybook, the app has been feeling increasingly more polished and more joyful to use."
The component library has an owner. For the first time, someone can refactor architecture, polish interactions, and extend components without competing for engineering resources. The effect compounds, every improvement makes the next feature easier.
"Developing with your components has been such a dream, and the app feels so good and cohesive lately."
Validation got faster and more honest. Early on this is not even our codebase. A quick AI builder gets me something working the same day, which is closer to pen and paper than to a prototype: disposable, unconstrained, good enough to see how an idea behaves. Later, when it matters, the thing people react to is built from our real components and behaves like the shipped product.
What I design is what ships. Not approximately. Exactly. There is no gap between the design and the implementation because they are the same artefact, which means no drift, no compromises made under time pressure by someone else, and no list of small things we agreed to live with.
None of this was free, and most write-ups on the subject skip that part.
Preparing the ground took longer than the switch itself. Our component library had been neglected for years, which is exactly why nobody had capacity to fix it. Getting it into a clean state, and then into a state an agent could work with reliably, meant writing down rules and conventions that had only ever lived in my head. That work came before any of the benefits did.
I had to learn the mechanics, and some of them the hard way. Git, branching, pushing, merging, enough terminal to be dangerous. Cursor made a lot of this easier than it would have been. What it did not teach me was how to structure work sensibly. Keeping branches small and scoped is obvious to any engineer and was not obvious to me. I learned it by making a mess first.
Some things a design tool simply gave me, I had to rebuild. Sharing work with external stakeholders. Letting someone leave a comment on a specific part of a screen. Sending a link to a person who does not have a dev environment. Figma solved all of that years ago, and going without it means solving it again, usually less elegantly.
None of these changed my mind. But anyone considering this should know the first months are an investment, not a saving.
I am not writing this because designing in code is the right answer for every company. It is not. It requires genuine frontend interest, some foundational fluency, and a team small enough to move without ceremony.
I am writing it because of what it demonstrates. The handoff existed for a good reason. It was the practical solution to a real constraint. When the constraint disappeared, the process should have changed with it, but processes are sticky. Most organizations keep optimizing the workflow they have instead of asking whether it still needs to exist.
And when a step like that goes, what is left is judgment. That is the same shift we build for at Matik. An admin no longer starts a template from a blank page, they sharpen what AI drafts. A CSM decides whether the output is worth sending rather than assembling it. The work that survives is the work that needed a person in the first place.
We ask that about our customers' workflows every day. It seemed only fair to ask it about my own.
Matik exists because customer-facing teams spend too much time assembling things rather than deciding what they should say. Thirty decks with the same structure every quarter, and very little time left for what each of those customers actually needs to hear.
The answer was always to make that work deterministic: build the template once, connect it to real data, and the thirty decks produce themselves. AI came in where determinism runs out, getting a template built in the first place, and the parts that call for judgment rather than repetition. But only so far. What can be made reliable should be, so the person is left deciding and reviewing rather than producing.
That belief is easy to hold about other people's workflows. It is harder to apply to your own.
Over the past several months, I rebuilt how design and engineering work together at Matik, using the same reasoning we apply to our customers' problems. This is what happened.
Every software company has the same seam running through it: designers decide how the product should look and behave, engineers build it, and something has to carry the intent between them.
That something is the handoff. Design files, written specs, annotated prototypes, review documents. An enormous amount of effort goes into making the translation faithful.
And the industry has spent decades improving it. Better tools. Tighter specs. Smarter integrations. Even Figma's most recent announcements are, at their core, another attempt to make the translation smoother.
But a translation can never be as good as speaking the same language.
This was never a problem I had stopped noticing, and I was not the only one. Engineering felt it too, and said so.
The cost showed up in specific places. Engineers spent cycles interpreting design intent instead of building product logic. We had design guidelines alongside the Figma files and it still fell short, partly because Figma was never their environment. Several found it hard to navigate even in dev mode, which is fair enough.
Details drifted between what was designed and what shipped. I wrote design review documents describing fixes I could have made myself in less time. And our component library, the thing that should have kept the product coherent, had no owner, because every engineering hour was already spoken for.
There was a subtler cost too. We had a component library in Figma and a component library in code. Two systems, meant to mirror each other, drifting apart a little more with every sprint. I kept the Figma one in good shape, which honestly made things worse: the gap between the two was visible every time something shipped.
Designing in code has always been possible in theory. In practice it required a level of technical fluency most designers do not have time to maintain alongside research, strategy, systems work, and everything else the role demands.
That is exactly the kind of barrier AI is good at lowering.
I had always been drawn to the frontend, I started my career when teams were still writing pixel values on static mocks, but never had the capacity to make the switch on my own. AI-assisted tooling changed that. You do not need to write perfect code to start. You need enough judgment to know what good looks like, and a way in.
So I stopped opening Figma and started designing directly in Storybook, in our real codebase, with our real components.
The important part is not that I learned to work in code. It is what stopped. My version of producing was translating: files, specs, prototypes, review documents, all of it describing a product that did not exist yet so someone else could build it. Now the deciding and the making are the same act, and the translating step is gone.
Exploration did not change. Analysing feedback and the data we already have, writing, pen and paper, quick AI prototyping tools to feel out ideas. No components, no branding, just thinking about the problem. This is still where most of the design work happens, and it should be.
Building moved into the codebase. When it is time to make something real, I open Cursor and build in Storybook using our actual frontend components, extending existing ones or creating new ones as needed. Real components, real data, one source of truth.
The prototype became the handoff. This is the part that changed everything. I build the interface where the product actually lives, so there is nothing to translate. For smaller work, I open a pull request directly and it ships after code review. For larger features, I build the interface in Storybook, validate it with users and stakeholders, and then hand the branch to an engineer who wires it to the backend.
Designing in the codebase also forces better thinking. Component structure, technical constraints, edge cases, accessibility, you cannot defer them to a later phase when the later phase is the same phase.
They also become much more obvious. In a design file you have to remember to think about the empty state, the long name, the slow response. In something working, you run into them.
I spend more time deciding and less time producing. This is the result that matters most and the one people find hardest to believe. Removing the translation work did not turn me into an engineer, it gave me back the hours that used to go into describing things. More research, more strategy, more exploration. The implementation loop got shorter, so the thinking loop got longer.
Engineering ships faster. Not because anyone works harder, but because an entire category of work left their plate. UI implementation is done before the branch reaches them. They connect it to real systems, which is what they are best at anyway.
"Life changing."
"Ever since you started designing directly in Storybook, the app has been feeling increasingly more polished and more joyful to use."
The component library has an owner. For the first time, someone can refactor architecture, polish interactions, and extend components without competing for engineering resources. The effect compounds, every improvement makes the next feature easier.
"Developing with your components has been such a dream, and the app feels so good and cohesive lately."
Validation got faster and more honest. Early on this is not even our codebase. A quick AI builder gets me something working the same day, which is closer to pen and paper than to a prototype: disposable, unconstrained, good enough to see how an idea behaves. Later, when it matters, the thing people react to is built from our real components and behaves like the shipped product.
What I design is what ships. Not approximately. Exactly. There is no gap between the design and the implementation because they are the same artefact, which means no drift, no compromises made under time pressure by someone else, and no list of small things we agreed to live with.
None of this was free, and most write-ups on the subject skip that part.
Preparing the ground took longer than the switch itself. Our component library had been neglected for years, which is exactly why nobody had capacity to fix it. Getting it into a clean state, and then into a state an agent could work with reliably, meant writing down rules and conventions that had only ever lived in my head. That work came before any of the benefits did.
I had to learn the mechanics, and some of them the hard way. Git, branching, pushing, merging, enough terminal to be dangerous. Cursor made a lot of this easier than it would have been. What it did not teach me was how to structure work sensibly. Keeping branches small and scoped is obvious to any engineer and was not obvious to me. I learned it by making a mess first.
Some things a design tool simply gave me, I had to rebuild. Sharing work with external stakeholders. Letting someone leave a comment on a specific part of a screen. Sending a link to a person who does not have a dev environment. Figma solved all of that years ago, and going without it means solving it again, usually less elegantly.
None of these changed my mind. But anyone considering this should know the first months are an investment, not a saving.
I am not writing this because designing in code is the right answer for every company. It is not. It requires genuine frontend interest, some foundational fluency, and a team small enough to move without ceremony.
I am writing it because of what it demonstrates. The handoff existed for a good reason. It was the practical solution to a real constraint. When the constraint disappeared, the process should have changed with it, but processes are sticky. Most organizations keep optimizing the workflow they have instead of asking whether it still needs to exist.
And when a step like that goes, what is left is judgment. That is the same shift we build for at Matik. An admin no longer starts a template from a blank page, they sharpen what AI drafts. A CSM decides whether the output is worth sending rather than assembling it. The work that survives is the work that needed a person in the first place.
We ask that about our customers' workflows every day. It seemed only fair to ask it about my own.
