Alright, this one is a bit weird.

I’m a product designer.

I don’t know how to code.

And yet, during the last few months, I’ve built a real product from scratch: a learning platform with audiobooks, flashcards, collectibles, achievements, authentication, cloud progress, a custom audio experience and a semi-automated system for producing its content.

It’s live.

People can actually use it.

And no, I didn’t secretly spend the last three years learning software engineering at night.

I built it by working with AI coding tools—mainly Claude Code—as if they were my technical team.

The product is called microverse.

And this is probably the most complete thing I’ve ever created.

So, what the heck is microverse?

The original idea was fairly simple:

What if I created short audiobooks that helped people understand great books without having to spend ten hours listening to each one?

Not exactly revolutionary.

There are already many products offering book summaries.

But the more I thought about it, the more I realised that consuming information wasn’t the real problem.

The problem was remembering it.

You read a book.

You listen to a podcast.

You watch a two-hour interview with an extremely serious person explaining the meaning of life.

A week later, you remember one anecdote, half a quote and perhaps what the person was wearing.

So the idea evolved.

microverse wouldn’t be just a place to listen to book summaries.

It would help people turn what they listen to into knowledge they can actually retain.

The product loop

The experience is organised around a simple loop:

Listen → discover → review → progress.

Users listen to books divided into short chapters.

Their progress is saved, so they can leave and continue later from the same point. The player remains available while they move through the product and can expand into a complete listening experience.

Nothing particularly crazy there.

But listening is only the beginning.

As users complete chapters, they unlock Ideas: important concepts from the book that become part of their personal collection.

Before they’re unlocked, they appear as hidden silhouettes.

Afterwards, they become something the user has discovered and earned.

This adds curiosity and reward to an experience that could otherwise be completely passive.

You’re not simply reaching the end of an audio file.

You’re building a map of what you’ve learned.

Completing chapters also unlocks flashcards.

These enter a review system that adapts to how well the user remembers each concept. Difficult cards return sooner. Easier ones gradually appear less often.

There is a daily review, book-specific practice, learning statistics and streaks.

The objective isn’t to make users feel as if they’re studying for an exam.

It’s to create a lightweight habit that helps the important ideas remain available after the audio finishes.

Finally, listening, learning and reviewing can unlock achievements.

Some are visible.

Others are secret.

Because apparently I’m still unable to design anything without eventually turning part of it into a collection.

That is how the product stopped being an audiobook app.

It became a learning system.

Designing the experience

This was obviously the part where I felt most comfortable.

I wanted the product to feel editorial and slightly magical, but still work like a clear, modern application.

The visual system combines expressive typography, dark surfaces, warm colours and soft atmospheric backgrounds with a more functional layer for navigation, controls and data.

Books are presented as journeys.

Ideas behave like collectibles.

Achievements feel like small discoveries rather than corporate productivity badges.

But underneath that visual personality, I worked hard to make the experience predictable.

Typography, colours, spacing and interface patterns are organised into a consistent design system.

Components reuse the same foundations instead of inventing a new solution every time a screen needs a button, a modal or a heading.

This matters aesthetically.

But it matters even more when you have to keep evolving the product.

I’ve written before about how strong foundations allow products to grow without becoming a collection of disconnected screens.

Apparently, I needed to build an entire application alone to prove the point to myself.

The details that make it feel real

Many of the things I’m proudest of are small.

The navigation shows contextual badges when something new has been unlocked.

Tapping the active section again brings the user back to the top.

The player follows the user around the app without getting in the way.

Headers adapt as you scroll.

Progress maps react visually to each book.

The interface respects reduced-motion preferences.

Keyboard navigation and focus states are considered instead of treated as some distant future problem.

Notifications are coordinated so that achievements, Ideas and other events don’t all appear at once and begin fighting for attention.

That last one sounds trivial.

It isn’t.

A collection of independently designed features can easily produce a terrible experience when several of them happen at the same time.

So instead of designing a few notifications, I had to think about how the product communicates with the user as a whole.

That happened again and again during the project.

The more I built, the more I understood that designing a product alone means going far beyond screens.

Designing what nobody sees

When you work with engineers, you can sometimes focus on the experience and trust that the technical team will decide how everything should behave underneath.

This time, there was no traditional technical team.

Claude could generate code.

But it couldn’t own the product.

So I had to make decisions about things I had never expected to manage directly:

• What happens when a user leaves halfway through a chapter?

• Which behaviours need to remain consistent across devices?

• What information should be private?

• What happens when several systems update at once?

• How can the product eventually become a mobile app?

• How do you prepare monetisation without damaging the learning experience?

• How do you change something important without breaking existing progress?

I didn’t personally write the solutions.

But I had to understand the problems well enough to judge whether Claude’s solutions made sense.

And that became the real work.

Working with AI is not pressing a button

From the outside, AI-assisted development can look a bit like this:

“Build me an app.”

And then, presumably, you make a coffee and return twelve minutes later to find Airbnb.

That wasn’t my experience.

AI can produce code incredibly quickly.

It can also misunderstand the problem, make assumptions, expand the scope or solve the wrong thing beautifully.

So I developed a deliberate process.

Before Claude touched anything important, I asked it to study the product and explain:

• what it believed was happening;

• what the actual problem was;

• what options existed;

• what risks they introduced;

• what it recommended;

• and how it planned to validate the result.

Then I reviewed the plan.

Sometimes I approved it.

Sometimes I adjusted it.

Sometimes I stopped everything because one small assumption made the whole direction questionable.

The most important skill wasn’t writing clever prompts.

It was learning not to approve things by inertia.

AI doesn’t remove the need for judgement. It makes judgement more important.

Building for where the product is going

One of my main concerns was avoiding a product that worked today but became impossible to evolve tomorrow.

The audio system was built so that the experience isn’t permanently tied to one interface or platform.

Authentication was prepared for a future mobile application instead of relying completely on browser behaviour.

The product has already been tested inside early iOS and Android builds to understand what can be reused and what will eventually need native work.

The conclusion was positive:

The current product can become a real mobile app without throwing everything away.

Not with a magical one-click conversion.

Some parts will need adaptation, especially those related to background audio and system behaviour.

But the foundations are there.

The same thinking applies to monetisation.

microverse is intended to become a freemium product, where users can experience the complete learning loop with accessible books and a subscription expands the catalogue.

Billing itself is not finished.

App Store subscriptions, purchase restoration and all the glamorous administrative joy that comes with them still need to be built.

But the product is being prepared so that monetisation doesn’t arrive later like a bulldozer and force everything to be redesigned around it.

That’s the kind of work users never notice.

Which is usually a sign that you did it properly.

The security rabbit hole

This may be the part I least expected to care about as a designer.

The product contains personal progress, unlocked content and learning history.

Audio and premium content also need to be delivered only to the people who are allowed to access them.

So security couldn’t be limited to hiding a few buttons in the interface.

That would be security theatre.

The product was built with private user-level data access, protected content delivery and server-side validation for sensitive actions.

I also worked through security audits, database warnings and dependency reviews instead of simply trying to make the warning icons disappear.

Did I understand every technical detail immediately?

Absolutely not.

There were moments when reading an explanation felt like being handed an ancient legal document written by a database.

But over time, I learned enough to ask better questions, distinguish important risks from noise and avoid approving changes I didn’t understand.

I’m not a security engineer.

But the product is safer because I accepted that security was also part of the product.

Then I realised I was building two products

An audiobook-learning app needs content.

A lot of it.

Each book requires adapted chapters, narration, audio assets, learning cards, collectible concepts, metadata and a consistent relationship between all those elements.

Doing all of that manually would make the product very difficult to operate alone.

So alongside the application, I built a semi-automated content-production system.

It helps transform source books into narration-ready chapters, audio and structured learning material.

There is still human review.

It is not an autonomous publishing creature producing flawless books while I sleep.

Sadly.

But it removes a huge amount of repetitive work and makes the catalogue scalable enough for a solo project.

That said, the catalogue is still at a very early stage.

Right now, only one book has been fully adapted and produced in audio.

The system for creating the rest exists—but the editorial work still needs to happen, book by book.

So the challenge ahead isn’t only continuing to improve the product.

It’s filling it with enough great content to make the whole experience truly valuable.

The factory gives me leverage.

It doesn’t remove the work.

That changed how I understood microverse.

I hadn’t built only the experience users see.

I had built:

1. A consumer learning product

2. The internal system that feeds it

The complete loop became:

A source book enters the production system and eventually becomes a structured learning experience inside the app.

Without that second part, the first product wouldn’t really be sustainable.

The numbers, because people like numbers

During the project, the repository grew to include hundreds of changes, thousands of lines of application code, dozens of database updates and several automated content workflows.

All managed by one product designer using AI tools.

I’m careful with these numbers because more code doesn’t necessarily mean a better product.

Sometimes a large amount of code represents a powerful system.

Sometimes it means someone had a very bad Tuesday.

What matters to me is the breadth of the work:

• product strategy;

• user experience;

• visual design;

• learning mechanics;

• content operations;

• security;

• architecture;

• mobile preparation;

• monetisation foundations;

• quality and monitoring.

I had to connect all those parts into a coherent direction.

What I’ve learned

The obvious conclusion would be:

AI allows designers to build software.

True.

But that isn’t the most interesting part.

The real change is that designers can now participate much more deeply in how a product is structured—not only in how it looks or how users move through it.

But access to implementation doesn’t automatically produce good products.

AI will happily build whatever you ask for.

Including bad ideas.

The most valuable skills were the same ones I’ve used throughout my career:

• understanding the real problem;

• thinking in systems;

• creating strong foundations;

• controlling scope;

• making trade-offs;

• validating assumptions;

• staying close to the intended experience;

• and knowing that a technically correct solution can still be the wrong product decision.

I still don’t consider myself a programmer.

I couldn’t rebuild microverse from memory by sitting in front of an empty code editor.

That isn’t what happened here.

I learned how to lead the construction of a technical product.

That is different.

And for a product designer, potentially much more useful.

Final thought

For years, I’ve believed that design isn’t only about screens.

It’s about creating the foundations that allow people to understand a product, use it confidently and grow with it.

With microverse, I had to apply that idea to almost everything:

• the experience;

• the learning loop;

• the content;

• the underlying systems;

• the future business model;

• and the way the product will eventually reach new platforms.

The result isn’t finished.

There is still a lot to build.

But it is already a real, coherent product that works in production, with its first complete audiobook and a system designed to support everything that comes next.

And somehow, I built it without knowing how to code.

Well.

Without knowing how to code, but with Claude, Make, Supabase, ElevenLabs, an unreasonable number of conversations with artificial intelligence and enough manual validation to develop trust issues with every loading spinner I see.

Not bad for a product designer.

V.