👋 Welcome to today’s edition of Build & lead (formerly the CTO blueprint), a newsletter by Appolica. Every two weeks, we dive deep into the tech, product, and leadership challenges that keep founders up at night.
For most of my career as a designer, the process looked the same everywhere. You design screens in Figma. You present them to the client. Get feedback (lots of rounds of “can we make the logo bigger?”), then spend hours building out a prototype and you finally get the approval. You hand off everything to the developers, cross your fingers, and hope for the best.
What came back rarely looked like what you designed.
So you’d leave feedback. The developers would open up tasks and work on them. You’d review again. More feedback. More tasks. Eventually, after weeks of back-and-forth, you’d get something that looked right on the surface but never quite felt the way you intended. The details were always a little off. Then you’d move on to the next project and do it all over again.
This process wasn’t broken in the traditional sense. It had its benefits and most importantly, it worked. Products got built. Clients got their deliverables. But it was slow, frustrating, and full of friction that nobody questioned because everyone assumed it was just how things worked.
At Appolica, we stopped assuming that about a year ago. And the way we design now looks nothing like what I just described.
Let me be specific about what the traditional design workflow actually looked like, because I think a lot of teams still live in it without realizing how much time it costs them.
Step 1: Design. The designer creates screens, flows, and components in Figma. This takes days, sometimes weeks or months, depending on scope. Let’s not forget the prototyping afterwards, when the client wants to “feel the design.”
Step 2: Client approval. The client reviews the designs. There’s feedback. Revisions. Another review. More revisions. This alone can take a week or more.
Step 3: Handoff to developers. The approved designs go to the tech team. The designer cleans the file, writes annotations, explains interactions. The developers interpret all of this and start building.
Step 4: Designer feedback. The first build comes back. It doesn’t match. The spacing is off. The animations feel wrong. A component behaves differently than intended. The designer flags everything.
Step 5: Tasks and fixes. The feedback turns into tickets. Developers work through the list. Some fixes are quick. Others require going back to the designer for clarification.
Step 6: Final review. The designer does a last pass. There are still a few things. Another round. And then, eventually, it ships.
This process isn’t terrible. It’s just slow. And the core problem is structural: the designer and the developer are working in completely different mediums. One thinks in pixels, the other in code. Every handoff is a translation, and every translation loses something.
And it’s not just that. Once you put yourself in somebody else’s shoes, you understand how your design decisions impact not just the end users, but there’s another story, a feasibility one - which we’ve been ignoring for a long time.
About a year ago, we flipped the process. Not gradually - we just changed it.
Now, the engineers build first. They create the structure, the layout, the core functionality. They ship working features using established components and design system patterns. The code exists, it runs, it works. Think of it like prototyped high-fidelity wireframes. All the functionality is there and we just need to style it.
Then the designers come in.
Not with a Figma file and nice prototypes. They come in with Claude Code, with Cursor, with Figma’s MCP and they work directly in the codebase. They apply the overall brand styling. Improve UX patterns. They refine animations. They polish transitions. They push their changes to the same repository the engineers use.
No handoff. No translation. No game of telephone.
I introduced this process about a year ago and I won’t pretend it was easy to convince everyone. Designers aren’t trained to think about code, our main focus was always: solve the problem, make it pretty, and if the devs are lucky, not too hard to implement. But I knew the old way was holding us back, so we tried it. The first few commits were nerve-wracking for the team. But the tools have gotten to a point where the gap between “designer” and “someone who can ship visual changes” is almost gone. Claude Code doesn’t care that our designers don’t know React’s lifecycle methods by heart. It cares that they can describe what they want the interface to feel like, and it helps them get there.
Now every designer on the team does this daily. It’s not just my process anymore. It’s theirs.
Let me walk you through what a typical scenario looks like now.
An engineer finishes building a new dashboard view. The feature works, the data loads, the filters respond, the layout is there. But it looks like an engineer built it (no offense to engineers, but you know what I mean). The spacing is inconsistent. The font weights don’t follow the design system. The loading state is just a spinner with no context. Input fields are different in every single modal screen - still not sure how that even happens.
In the old world, the designer would open Figma, design the whole thing and send it to the devs to deal with the changes.
Now, one of our designers opens the project in Cursor or Zed (or another code editor). We define the major changes that need to be done like fonts, colors, spacing. Usually those are changed at a global level within the whole file. Then we move to a component level, we align the navigation components, headers, input fields. Afterwards we focus on case-by-case UI/UX improvements. Finally, animations are tweaked. All those changes are done with Claude via prompting, split into multiple commits and pushed into the same places we had never set foot before.
Don’t get me wrong, we still need our play area. We still use Figma, but for defining the initial style, vision and direction of the product. Sometimes hard concepts need to be designed on a blank canvas where you can do the visual thinking. And this whole process still takes 3x less time than before. And the result is better, because we’re working with the real product, not a static representation of it.
I want to be honest about the tooling, because I know a lot of designers are skeptical. I was too.
Claude Code is the biggest shift. It’s not a design tool - it’s a coding agent that understands what you’re trying to do. I describe a visual change in plain language, and it writes the code. If something breaks, I tell it what went wrong, and it fixes it. It’s like pair-programming with someone who has infinite patience and never judges you for not knowing what a useEffect does.
Cursor, Zed or Conductor is the editor we work in. It’s fast, it has great AI integration, and it doesn’t feel like it was built exclusively for engineers. The interface is clean, the file navigation makes sense, and we don’t feel like we’re lost in someone else’s workspace. The setup can be a bit challenging, at least for me (ask half of the Appolica devs, who were on constant support).
Figma’s MCP server connects the design world and the code world in a way that finally makes sense. I can reference design tokens, pull component specs, and keep the codebase aligned with the design system without manually copying values back and forth. It has its minuses - like the additional token cost from Figma, but there are workarounds for that as well. And to be honest, sometimes even a screenshot works well if you just want to explain your idea better.
Git was the scariest part, honestly. The idea of pushing code to a shared repository felt like entering someone else’s territory. But once you get past the initial fear, it’s actually empowering. Your changes are tracked. They can be reviewed. They can be reverted if something breaks. It’s a safety net, not a minefield.
These tools don’t replace design thinking. They replace the translation layer. Instead of designing something and then explaining it to someone who builds it, I design by building it myself.
The biggest change isn’t technical. It’s cultural.
When the designers started pushing code, the engineers didn’t know how to react. Some were skeptical. Some were relieved. A few were worried things would break (fair concern). But after a few weeks, everyone realized something important: the back-and-forth had almost disappeared.
Engineers could focus on architecture, logic, and performance - the things they’re actually best at. They stopped spending time on pixel-level adjustments that frustrated them anyway. And the designers stopped spending time trying to find a common language and advocating for design decisions.
The whole team moves faster now. Not because anyone is working harder, but because we removed an entire category of friction. When the designer can touch the code directly, there’s no waiting, no misinterpretation, no lost context. The product gets polished in real time.
Our entire design team at Appolica has been doing this for close to a year now. Every designer pushes code. Not as a side experiment, not as a “nice to have.” It’s how we work. And none of us want to go back.
Yeah, the thought that sometimes you just need to explain your idea with 4+ prompts, rather than just moving some things in Figma, can be very frustrating. But if you’re able to make that mindset shift, you’re in.
I want to be clear about something, because I know this idea makes some people uncomfortable.
Our designers aren’t writing backend logic. They’re not architecting databases. They’re not debugging memory leaks. That’s not their job, and it shouldn’t be.
What they are doing is taking ownership of the final layer of the product - the part that users actually see and touch. The visual quality. The micro-interactions. The spacing, typography, and motion that make a product feel considered versus thrown together.
The industry is starting to call this role a “design engineer.” Vercel has been championing it. Companies like Linear and Raycast, even Claude itself, have built their products around this mindset. But you don’t need a fancy title to start. You just need to be willing to work in the medium your users experience.
Figma is a tool for thinking. The browser is where products live. The closer I work to where the product actually exists, the better the result.
You don’t need to learn computer science. You don’t need to understand algorithms or data structures. Here’s what actually helps:
Start with your design system. If your team uses a component library, learn how it’s organized in code. Read the component files. You’ll recognize the patterns — they map directly to what you’ve been building in Figma.
Use AI as your pairing partner. Claude Code, Cursor, Copilot — pick one. Describe what you want to change in plain language. The AI writes the code. You review it visually. If it doesn’t look right, you tell it what’s off. This loop is faster than you think.
Make your first change small. Fix a color. Adjust some padding. Update a font weight. Push it. See it live. That first commit is the hardest one. Everything after that gets easier.
Don’t be afraid of breaking things. Git has your back. If your change breaks something, it can be reverted in seconds. The engineers on your team deal with broken code every day. You’ll be fine.
Talk to your engineers. Tell them you want to try this. Most will be supportive. Some will be excited. The key is to start with low-risk changes and build confidence gradually.
It is not 2020 anymore. The world is changing and your process should too. Now we have better tools, and the excuse to keep doing things the old way is gone.
At Appolica, our designers push code to production every week. Not because we have to. Because it makes the product better, the team faster, and the work more satisfying. The gap between design and development used to be measured in sprints. Now it’s measured in commits.
If you’re a designer still using only Figma and hoping for the best - try the other side. It’s not as scary as it looks.
Got feedback or just want to get in touch? Reply to this email and we’ll get back to you.
Want to see more of us? Have a look at our LinkedIn account. Interested in what we do? Visit appolica.com.
Thanks for reading & until next time.
Best,
Bianka & the Appolica team
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.