AI finally lets designers ship the things they always wanted to build

For most of my career, the furthest my own ideas ever got was a Figma file. A few frames, a flow that looked convincing, sometimes a prototype I’d click through once or twice. Then real work picked up again, and the file slid down the recents list until I forgot it existed.

I’ve been designing for almost eight years. I’ve been a Staff Designer at SQB Bank and a Product Designer at GovDash, and since March I’ve been leading product design at Mutolaa. I like that work a lot. But for most of those years, if you’d asked me to show you something I made simply because I wanted it to exist, I wouldn’t have had much to open.

That’s changed, and I want to write down what it’s been like while it still feels new. Mostly for other designers who are sitting on a pile of their own.

The pile in the Figma file

Every designer I know keeps some version of a list. It might be a page called “someday” in a Figma file, or it might only live in their head. It’s full of small apps and tools that would make one corner of life a bit nicer, things nobody else is going to build because nobody else noticed the problem.

Mine has been growing the whole time I’ve been designing.

Coming up with ideas is something designers are good at, and we’re even better at making them look real. The trouble starts after the mockup. At work, getting something built means a handoff, a ticket, a spot on the roadmap and an engineer who already has a full plate. That’s fair, and it’s how good teams protect their focus. A personal idea has none of that. There’s no roadmap and no engineer, just you and a design that can’t actually do anything. So the ideas stay in the file, and I have a lot of those files.

Framer was where that started to change. For about three years I built client websites in it, and for the first time I could take a design all the way to a live URL by myself. That mattered. But a website was as far as it went. As soon as an idea needed accounts or data that changes, I was back to waiting on someone who could write the code.

The first time nobody had to say yes

Coding agents are what finally closed the gap for me. What made it click was that I could work the way I already work on a design: describe what I want, look at what comes back, point at what’s wrong, and try again. The difference was that the thing on the screen now actually ran.

I remember the first time something I designed went live without me asking anyone for anything. No ticket, no “can we squeeze this into next sprint,” no hoping a developer friend had a free weekend. I built it, put it on the internet, and people I’d never met could use it.

It’s hard to describe how strange that felt. For years, “done” had meant done on my side: the file was clean, the specs were written, and the rest was out of my hands. This time, done meant a link I could send to anyone, and they could open it on their phone and it would work. Mostly I felt relieved, like I’d been waiting for permission for years and only then noticed I didn’t need any.

Since then I’ve kept building small independent apps and tools on the side. This site is one of those things. It’s built with Astro and Tailwind and deployed on Cloudflare, and I put it together with an agent doing a lot of the typing while I did the deciding.

What designers already bring

What surprised me is that once code stopped being the thing in the way, the hardest parts of building turned out to be things designers practice every day.

An agent will build pretty much whatever you ask for. It has no opinion on whether the idea is worth building. It won’t notice that the empty state feels cold or that the flow has one step too many. It’ll give you something that works, and making it something people want to come back to is still your job.

That’s where years of design work pay off in a way I didn’t see coming. Deciding what to build, and more often what to leave out, is a real skill. So is looking at a screen that technically works and knowing it isn’t right yet. Designers train those instincts for years, usually while waiting on someone else to ship, and now they turn out to be most of the work.

Running Anabios has taught me a version of this too. When you sell Framer templates to creative studios, photographers and filmmakers, the details are the product. A template can have every page a studio needs and still feel wrong for their work, and people can tell within seconds of scrolling. I bring that same fussiness to the apps I build, and it’s the part I’d least want to hand over to an agent.

The parts that are still hard

I don’t want to make this sound easier than it is.

Knowing when something is good is harder alone. On a team there’s a review, and there’s usually an engineer pushing back on the edge case you missed. Building with an agent, nobody pushes back unless you do. The agent will happily tell you it’s finished. It’s on you to open it on a real phone and try to break it.

Scope is the other trap. When building gets cheap, adding things gets cheap too, and it’s easy to start with a tiny tool and end up with half of a big product where nothing works quite well enough. What helps is writing down the one thing the app has to do before you start, then being stubborn about it every time a shiny extra shows up.

And you do have to learn some code. You need enough to steer, which is a lot less than an engineer knows. When the agent goes in circles or picks a strange approach, you have to be able to read what it did, roughly, and say “no, not like that.” For me that meant learning how a project is laid out, what a component really is, where the data lives and how deploying works. I’m still learning it. Each project leaves me understanding a bit more, and I’ve slowly become someone who can read the code even when I wouldn’t want to write all of it by hand.

If you’ve been waiting

If you’re a designer with a pile of your own, I want to nudge you a little. Pick the smallest idea on it, the tiny tool that would make one part of your week easier, and leave the big dream app for later. Open a coding agent, describe what you want the way you’d explain it to a developer you trust, and see what comes back.

The first version will be rough. Parts of it will look worse than your mockups, and that will bother you more than it should. Keep going. The space between the mockup and the working thing is where you’ll learn the most, and it shrinks faster than you’d expect.

I still keep my list. These days, when I add something to it, I catch myself thinking about what the smallest first version would be, and whether I could have it running by the weekend.