Beyond Figma: Designing, Building and Shipping My Own Products

I designed it. I built it. I shipped it. Now what?

What happened when I stopped handing over designs and started taking ownership of the entire product development process.

For most of my career as a Product Designer, there's been a familiar point in the process where my work changes hands.

I've spent weeks understanding a problem, speaking to customers, exploring solutions and refining designs in Figma. I've considered the edge cases, documented interactions and worked closely with engineers to bring the experience to life.

And then, at some point, I hand it over.

Of course, good product design has never been about throwing designs over the fence. I've always worked collaboratively with engineers and stayed involved throughout development.

But there's a difference between influencing how something gets built and having the ability to build it yourself.

Recently, I've been experimenting with that difference.

Using Claude Code, I've started building my own products. Not just clickable prototypes, but working applications with their own repositories, deployment pipelines and a more structured approach to development.

I've been setting up Git, connecting Cloudflare and pushing my own deployments.

And somewhere along the way, I've found myself becoming not just the designer, but also the Product Manager, QA tester and, with the help of AI, something resembling an engineering team.

It's been a fascinating shift in how I think about my role.

The first time I pushed my own deployment

There's something incredibly satisfying about seeing a design you've created in Figma become a working product.

Not a clickable prototype. Something real.

I've recently been working on personal projects, including Tangle & Twine, a knitting and crochet companion, and Kerb, a property discovery concept.

These have given me the opportunity to take ownership of the development process, from understanding how Git manages changes to deploying my applications through Cloudflare.

They're things I've understood conceptually through years of working alongside engineers, but actually doing them myself has been a completely different experience.

And the most exciting part?

I'm no longer limited to imagining how my designs should behave. I can experience them, change them and immediately see the results.

If an interaction doesn't feel right, I can refine it. If the spacing looks different from Figma, I can fix it. If a journey feels unnecessarily complicated once I'm using it, I can rethink the approach.

That doesn't mean engineering is suddenly easy, or that AI removes the complexity of building good software.

But it has significantly reduced the distance between having an idea and testing it in something functional.

And as a designer, that feels incredibly powerful.

Suddenly, I'm also the Product Manager

One unexpected part of building my own products is how quickly I've had to switch from thinking like a designer to thinking like a Product Manager.

When you're working on your own idea, there's a temptation to build everything.

Every feature feels exciting, and with AI making implementation more accessible, it's easy to keep adding to the scope.

But just because you can build something doesn't mean you should.

I've found myself returning to the same questions I ask when working on commercial products.

What problem are we solving? What's the smallest useful version of this experience? Which requirements are essential, and which can wait?

With Tangle & Twine, for example, the ambition goes beyond storing knitting and crochet patterns. There's potential to help people organise projects, track progress, manage their yarn collection and discover what to make next.

But delivering everything at once would make it harder to understand whether the core experience is useful.

So I've approached it in phases, establishing an MVP and creating a prioritisation framework for what comes next, considering user value, effort, dependencies and confidence.

It's a useful reminder that product thinking isn't about how many features you can deliver. It's about deciding which problems are worth solving first.

AI might make building faster, but it doesn't make those decisions for you.

Building my own engineering team, one agent at a time

Perhaps the biggest learning curve has been understanding what it means to build something properly.

As a designer, I can describe how I want an experience to work. But that doesn't automatically mean I know the best way to architect the application behind it.

Which technologies should I use? How should components be structured? What's reusable? How do I avoid unnecessary complexity as the product grows?

These are questions I'd normally explore with engineers.

So rather than expecting one AI conversation to solve everything, I've started exploring specialist engineering agents.

The idea is to give agents clearer responsibilities: reviewing architectural decisions, recommending implementation approaches, identifying performance improvements and challenging technical choices.

It's an interesting shift because I don't necessarily need to write every line of code, but I do need to understand what I'm asking for and whether the recommendations are appropriate.

An AI agent can suggest an approach, but that doesn't automatically make it the right one.

I'm learning that asking better technical questions is becoming just as valuable as being able to describe a design.

Figma is still my starting point. Just not my finishing point.

Despite experimenting with AI-assisted development, I haven't abandoned Figma.

It's still where I explore information architecture, interaction patterns and visual design without immediately worrying about implementation.

But what has changed is how I validate those decisions.

Rather than treating Figma as the final representation of an experience, I'm increasingly using the working product as another design environment.

Once something is built, I can compare it against my original designs.

Does the typography feel right? Are the spacing and component behaviours consistent? Have the intended interactions survived implementation? What happens on smaller screens?

I'm introducing more structured design checks to identify inconsistencies between what I've designed and what's actually been built.

It's a familiar part of my role at thortful, where reviewing implementation and working through QA with engineers has always been important.

The difference is that I can now make those refinements much more directly.

A screen can look perfectly balanced in Figma but feel completely different when you're navigating it with real content.

Being able to experience those moments earlier is helping me become more critical of my own work.

Making quality part of the process, not the final step

One thing I've become particularly conscious of is how easy it is to mistake a successful build for a successful product.

Just because an AI coding tool tells me something is complete doesn't mean it's ready to use.

A feature might look correct but contain broken interactions. A new change might introduce problems elsewhere.

That's why I've been exploring a more structured QA process using reusable AI skills.

Rather than simply asking whether a feature has been built, I want a basic quality check to happen before I'm presented with the latest release.

Does the application build successfully? Are there obvious errors? Do the main journeys work? Have any critical interactions stopped functioning?

The intention is to establish a minimum quality threshold, so obvious problems are identified before I spend time reviewing the experience myself.

It doesn't replace proper testing, and I wouldn't trust an AI-generated QA report as proof that everything works.

But it introduces an important principle:

The job isn't finished when the code has been written. It's finished when the experience works as intended.

From there, I can focus on the things that still need human judgement.

Does it make sense? Is it intuitive? Have we actually solved the original problem?

So, does this make me an engineer?

No. And I don't think it needs to.

If anything, working with AI has made me more appreciative of the knowledge and experience good engineers bring to product development.

Generating code isn't the same as understanding architecture, security, scalability or the long-term consequences of technical decisions.

There's still a huge amount I don't know.

But I don't think the most interesting outcome of AI-assisted development is turning every designer into an engineer.

For me, it's about removing some of the boundaries between disciplines.

I'm becoming more comfortable discussing technical decisions because I'm encountering them firsthand. I'm thinking more critically about requirements because I'm responsible for deciding what gets built next.

And I'm developing a better appreciation of what it takes to turn a polished design into a reliable product.

It's making me a more rounded product thinker.

The part I'm most excited about

What excites me most isn't necessarily the technology itself.

It's the freedom to experiment.

For years, I've had ideas for products I'd love to create. Previously, taking those ideas beyond Figma would have required significantly more technical support.

Now, I can start building, learn from using the product, make changes and keep improving it.

There's something incredibly motivating about that level of ownership.

But the fundamentals of good product design haven't changed.

I still need to understand the problem, make decisions based on user needs, prioritise, test assumptions and challenge whether what I'm building is genuinely useful.

AI hasn't removed those responsibilities. It's simply given me more opportunities to put them into practice.

The future of our role might not be about designing more screens. It might be about having greater ownership of what happens after we've designed them.

I'm still early in this journey, and I'm certainly not getting everything right.

But being able to go from an idea in Figma to a working product I've deployed myself?

That's a pretty exciting place to start.