Recently I’ve spent a lot of time thinking about interfaces, about AI, about what it means to design something for humans. And somewhere in all of that, I keep asking myself: why do some products feel like they’re on your side, and most don’t?

It’s not about aesthetics, though aesthetics carry it. It’s not about simplicity, though simplicity helps. It’s …

Read more

Most people don’t know what to get out of Lovable and what’s actually possible.

That comes down to prompting. Prompting is basically the new designing when using AI products. You need to be really good at it.

Most prompts describe what to build like the product, the pages, the features. But the prompts that produce exceptional results describe the feeling and vision. The output quality doesn’t come from Lovable working harder but from the model having a clearer creative brief from you.

I’ve been experimenting with this extensively, and so has my friend Damien. Here’s the formula we’ve landed on.

Some of these tips will sound a little strange. “The site should sound good on mute” is not a normal thing to write in a prompt. But trust me anyway. The unconventional ones are often the most effective, because they communicate something no spec ever could.

One more thing before we start: Don’t just copy this prompt verbatim and swap in your product name. Everyone using the same template ends up with sites that look the same. The goal is to understand the logic well enough to write something that’s genuinely yours.

PS: You can also use these prompt rules to build your own prompt agent (Might publish one soon), where you can just tell the agent what you want and it produces the perfect prompt for you, based on the following rules.

1. Reframe the product immediately

This is important. Don’t just name what you’re building. You have to say what it is at a higher level of abstraction before you dive too quickly into technical details.

Why it works: This move changes every decision that follows. Layout, photography treatment, typographic hierarchy, use of negative space. All of it shifts when Lovable understands the product’s identity, not just its category.

Bad: “Build a speaker website.”
Good: “The product is a sculpture. Present it like one.”

2. Name your tech stack explicitly

Lovable makes sensible default choices but it won’t reach for premium motion libraries unless you ask for them by name.

Why it works: Naming Framer Motion isn’t just a technical instruction. It’s a signal that animation is a first-class citizen in this build, not an afterthought. It changes how Lovable approaches every interactive element on the page.

Bad: “Make it animated.”
Good: “Use React, Tailwind CSS, Framer Motion for all animations.”

3. Give interaction a philosophy, not a spec

Don’t list the animations you want. Describe what interaction means in the context of this specific product.

Why it works: Philosophy-level prompting produces coherent design decisions across the whole site. Spec-level prompting produces a checklist of features that don’t necessarily add up to anything.

Bad: “Add scroll animations and hover effects.”
Good: “Sound visualized through interaction, not gimmicks. Materials and engineering explored through scroll.”

Read more

Apps were built for a world where software couldn’t understand you. That world is over.

Open your phone and count the apps on your home screen. Every single one was built around the same assumption: you need a dedicated place to do a specific thing. Travel in one container. Money in another. Calendar separate. Notes separate. Fifty specialists in your po…

Read more

Hi, I’m Felix. A designer, founder, and investor. Over the last few years I’ve worked inside Lovable, made angel investments in 30+ companies, and spent most of my time thinking about one question: what does it actually take to build something people love?

Early in my career, a design mentor introduced me to a framework that changed how I think about products. It’s called the Hierarchy of User Needs. A pyramid, originally conceived by designer Aaron Walter, that describes the four levels every product moves through on its way from existing to being loved.

At the base: Functional. Does the product work? Above that: Reliable. Does the product work consistently? Then: Usable. Is the product easy to use? And at the top, the hardest and rarest layer: Pleasurable. Does it make people feel something?

Most products never make it past the first two levels. They work, more or less, but they don’t delight. They don’t get recommended. They don’t get missed when they’re gone. The reason is almost never technical. It’s that the people who built them stopped once things worked and never asked what it would take to make someone actually love it.

For most of startup history, even reaching “functional” was hard. It took a lot of time, tons of engineers, and initial capital most founders didn’t have. The pyramid felt like a luxury, something you thought about once the product was stable, the team was in place, the funding was secured. Well, today with AI, that has changed completely.

AI has erased the cost of the bottom three layers: functional, reliable, usable. A first-time founder with a clear idea can reach all three in a day. The technical barrier is basically gone, which means the only layer left that actually differentiates a product is the one at the top.

Pleasurable. The layer that turns users into fans, and fans into the people who tell everyone they know.

That layer has a name now. It’s called Lovable.

This playbook is about building all the way to the top of that pyramid. It’s written for first-time founders, but also for anyone who has an idea and has been waiting for the right moment to start. That moment is now, and it’s closer than you think.

Read more

I see a lot of founders making the same mistake.

They hire the wrong branding partner.
Usually a big agency that takes way too long.

The best brands I’ve seen don’t come from big agencies.

They come from small, sharp teams with super strong taste.
Teams that move fast and build with you, not for you.

So I curated my go-to list of studios I’d recommend t…

Read more

I recently built an internal brand agent for Lovable and a lot of people asked how I did it, so here's the exact guide:

1/ Build a brand environment first:
I asked Lovable to create a web app where you can view our logo, colors, typography, and all brand assets. This became the database, a single source of truth for everything brand-related.

Prompt: "Buil…

Read more

I’ve seen a lot of founders and agency owners recently build their slide decks with Lovable, so I created a guide for you to do the same.

Here’s how it works:

1/ Start by giving Lovable the full picture

Before you touch a single slide, tell Lovable who you are, who you’re pitching, and what you want them to feel by the end.

→ Prompt: “I’m building a pitch d…

Read more

There’s a new interaction pattern emerging in software, and I don’t think we’ve named it yet.

It started with Pinterest.

Back in the days when guided search launched, it felt like a small UX trick. You’d type one word, e.g. “living room”, and instead of a singular results page, you’d see a row of suggested refinements. “Cozy.” “Minimalist.” “Scandinavian.” Once you’d click one, new suggestions would appear instantly. You’d click again, and within a few steps, you’d arrived somewhere specific and beautiful without ever typing a second word. The whole UX was basically based on one single input. Everything else was just clicking “next.”

At the time, we called it guided search. What it really was, though, was something more fundamental: the interface had learned to meet you halfway. You didn’t need to know exactly what you wanted. You just needed to start.

I’m watching the same pattern evolve into something much more powerful at the moment.

At Lovable, I see this interaction pattern happen pretty much every day. A user types a single prompt, sometimes just a few words, and something gets built based on that. Once you see a first “result,” a suggestion appears that the AI has already anticipated based on your initial input. What I find interesting is that most users don’t ignore them but actually click them. The AI simply proposes the next action and all the user has to do is approve. And this loops all the time. Something else gets built → new suggestions pop up → they approve again.

If we zoom out, the product gets built almost entirely through a sequence of approvals.

And it’s not unique to Lovable. Look at how people use Cursor, ChatGPT, Notion AI, or any of the new wave of AI-native products. The interaction loop keeps compressing. The user’s job is less and less about constructing inputs and more and more about evaluating outputs. The interface runs slightly ahead of you, and you follow or you redirect.

Instead of initiating, we’re moving towards approving.

It’s a genuinely new interaction primitive, and I think it matters.

Read more

I see a lot of founders still building websites the same way they did ten years ago. But if they don’t adapt, they’ll loose customers. Here’s why:

The best converting websites in the age of AI aren’t websites at all. They’re the product.

Historically, websites were marketing billboards. Hero sections, feature lists, testimonials, pricing tables. You’d scr…

Read more

I recently posted a slide deck that I built fully with AI on LinkedIn and it took completely off.

So I created a guide to create animated, web-based presentations using Lovable.

Intro

Here’s what you do:

1. Copy the full prompt below (everything from “You are a senior product designer...” to “Build the full presentation now.”)

2. Open Lovable and create a new project

3. Paste the entire prompt in one message and hit send

4. Wait 1-2 minutes while Lovable builds your complete deck

5. See your presentation live — All slides, animations, and mobile responsiveness ready

6. Refine with simple messages like:

   • “Make the headlines bigger”

   • “Change slide 3’s background color”

   • “Speed up the transitions”

That’s it. One comprehensive prompt creates the entire app. Then you iterate naturally.

Why Build Slide Decks as Web Apps?

Traditional slide decks are static and constrained. By building presentations as web apps, you have:

• Full creative control — Custom animations, interactions, and layouts

• Premium aesthetics — Think Apple keynotes, not PowerPoint templates

• Native responsiveness — Perfect on desktop, tablet, and mobile

• Easy sharing — Just send a link, no downloads required

The key insight: AI can now handle both the design thinking and the technical implementation. You just need to guide it with clear constraints.

The Prompt (Copy this into Lovable)

You are a senior product designer and front-end engineer.

Your task is to design and build a premium, client-facing presentation as a web app — not a traditional slide deck.

Quality bar:
- Apple keynote level restraint
- Stripe / Linear / Arc aesthetic
- Designed, not templated
- Confident, calm, modern
- Strong typography and spacing
- Minimal text, high signal

GOAL
Create a 6-slide presentation that introduces a modern AI product to design-savvy clients.

APP MODEL
- Single-page React app
- Each slide is a full-screen view (100vh / 100vw)
- Only one slide visible at a time
- Navigation via keyboard and mobile gestures

NAVIGATION
- Arrow keys / Space to advance
- Swipe left/right on mobile
- Subtle progress indicator at the bottom
- No visible clutter

DESIGN SYSTEM
- Dark theme
- Background: near-black / deep navy
- Typography is the hero
- Large headlines (60–72px desktop, responsive)
- Minimal supporting text
- Intentional negative space
- Accent color used sparingly

MOTION
- Subtle, intentional animations only
- Opacity + translateY
- Ease-out
- Max 0.4s desktop, 0.3s mobile
- Motion should guide attention, never decorate

MOBILE
- Fully mobile-optimized
- Swipe is primary navigation
- No slide should scroll
- Titles ~36–40px on mobile
- Body text ~16–18px
- Touch targets at least 44px

SLIDES (CONTENT + INTENT)

Slide 1 — Opening
Single bold statement that sets the tone. No explanation. This slide should feel confident and calm.

Slide 2 — The problem
One clear tension modern teams feel today. Minimal copy. Let the typography do the work.

Slide 3 — The shift
A reframing moment. Introduce how AI changes the way teams work. This slide can use a slightly more expressive layout.

Slide 4 — The product
What the product enables. Not features — outcomes. Use a structured but minimal layout.

Slide 5 — Proof
Social proof or credibility. Metrics, logos, or a quote. Elegant, not salesy.

Slide 6 — Closing
Strong closing line. Clear call to action. Feels like a natural conclusion, not a push.

PROCESS
- Design the full deck end-to-end in one pass
- Prioritize design quality over speed
- Make opinionated decisions
- Apply a consistent visual and motion system across slides

Build the full presentation now.

Understanding the Prompt Structure

Now that you know how to use it, here’s why it’s structured this way:

Read more

The Three-Tool Stack

1. ChatGPT (or Claude) - Your Thinking Partner

Role: Vision, strategy, logic, flows, copy (everything before I design)
When to use: Start of every project, competitive analysis, feature prioritization

2. Lovable - Your Technical Co-Founder

Role: Turn prompts into real, working products (frontend + backend)
When to use: Building UI, adding auth & databases, deploying live apps

3. Figma - Design Precision & Systems

Role: Layout exploration, design systems, visual rules, component libraries
When to use: When brand matters, when you need consistency, or for specific visuals

Choose Your Workflow

Speed-First Workflow (Ship in Hours)

Best for: MVPs, testing ideas, rapid validation, solo founders

ChatGPT → Lovable → (Optional: Figma for polish)

Philosophy: Build fast, iterate based on user feedback, polish afterwards

Design-First Workflow (Pixel-Perfect from Day One)

Best for: Consumer products, brand-driven apps, design as competitive advantage

ChatGPT → Figma → Lovable

Philosophy: Define the brand system first, then build with consistency

Speed-First Workflow

Perfect for non-technical founders who need to ship fast and validate ideas.

Phase 1: Strategy & Logic (ChatGPT)

Start with Three Questions:

1. Who’s it for?

2. What problem does it solve?

3. What makes it feel magical?

What to use ChatGPT for:

• Brainstorm product ideas

• Map user journeys and flows

• Define core features and prioritization

• Write onboarding, error states, and microcopy

• Challenge your assumptions

Key Prompts:

“I’m building a [product type]. What are the 5 key screens 
and what components do they need?”

“Map out a daily flow for [your product] — from open to 
[key action]. Include decisions and transitions.”

“List 5 edge cases that could break this flow, and how 
to handle each one.”

“Suggest 3 UX flows to reduce friction and increase 
activation in [your product type].”

The Handoff:

“Turn this into a Lovable-ready prompt with all the details 
needed to build the UI and backend.”

Phase 2: Build Everything (Lovable)

Go from prompt to working product in one conversation.

Read more

There’s a seductive idea going around that speed is the new quality. Ship fast, test everything, let the data decide. In the age of AI, when you can generate a thousand variations in the time it used to take to make one, this seems not just reasonable but obvious. Why spend weeks agonizing over details when you could be learning from real users?

I think this is mostly right, but dangerously incomplete.

The people saying “speed is quality” are reacting to something real: the old world of design-by-committee, where products died in conference rooms before anyone outside the building ever saw them. They’re right that you learn more from shipping than from planning. They’re right that perfect is the enemy of good. They’re right that many decisions don’t matter as much as we think they do.

But there’s a category error happening. They’re conflating the process of finding what matters with the act of making it matter.

The best designers I know are incredibly fast, until they’re not. They’ll blast through a dozen concepts in an afternoon, testing wildly different approaches with a speed that looks almost careless. But then they find something. Some small moment in the experience that could be special. And suddenly they’re spending two days on an animation that 90% of users won’t consciously notice.

This looks inconsistent if you think quality is uniformly distributed. But quality isn’t uniformly distributed. It’s spiky. Most decisions genuinely don’t matter. A few matter enormously. And this is the part that’s hard to explain to someone who hasn’t felt it. You often don’t know which is which until you’re deep in the details.

The craft is knowing where to look.

What’s happened in the AI age is that the cost of “good enough” has collapsed. You can generate competent marketing copy, decent UI designs, functional code. The floor has risen dramatically. This is genuinely miraculous, I’m not being sarcastic. It’s made many things possible that weren’t before.

But here’s what hasn’t changed: the distance between good enough and magical is still exactly as far as it always was. Maybe further, actually, because now everyone can reach good enough.

That distance is measured in caring.

I was talking to a designer recently who was working on a file upload interface. She’d shipped the basic functionality quickly, drag and drop, progress indicator, the basic stuff. It worked fine. But she kept thinking about the moment right after you drop a file. That little pause before the upload starts. Most people just show a spinner.

She added this tiny moment where the file kind of “settles” into place with a subtle bounce, like it has weight. Then the progress bar grows out from underneath it, as if the file is sitting on a surface that’s filling up with data. The whole thing takes maybe 800 milliseconds.

When I asked her why she spent extra hours on this, she said something interesting: “I wanted uploading a file to feel like placing a physical object on a desk, not like sending data into the void.”

She nailed it. She understood that in order to design something beyond pure functionality, she needed to go the extra mile.

You can’t A/B test your way to this kind of quality. I mean, you probably could measure that users with the fancy animation have slightly higher completion rates or whatever. But that’s backwards. The point isn’t that it performs better. The point is that someone cared enough to make it delightful.

Read more

I’ve been quietly building something I wish existed when I started designing with AI.

A complete UI design prompt library that helps you master different visual styles: expressive, cinematic, minimal, premium, nostalgic, warm, technical (20+ design styles in total).

Each style includes:
👉 When to use it
👉 Key vocabulary that trigger the style
👉 Copy-paste prompts for real UI work
👉 Pro tips for next-level results

Read more

Something has changed in the last few years. You see it in the cap tables: designers with real equity, joining at single-digit employee numbers. Not as the person who makes the logo. As a founder.

This would have seemed odd in 2010. Back then, startups had founding engineers and maybe a business co-founder. Designers came later, after product-market fit, after the Series A. They were hired, not founding.

Now some of the most successful startups have designers in the founding team. And it’s not a coincidence.

What Changed

The obvious answer is that design matters more now. Products are more competitive, users are more sophisticated, the bar for “good enough” has risen. All true, but not the real reason.

The real reason is that the nature of product differentiation has changed.

In the early 2000s, if you could build something that worked at all, you had a shot. Just getting the technology to function was hard enough that execution barriers protected you. If you built a web app that didn’t crash, you were ahead of most people.

Now everyone can build. The tools are better, the knowledge is distributed, there’s an open source library for everything. Technical execution alone doesn’t protect you anymore.

So what does? How users feel about your product. Whether they understand it. Whether it fits into their mental model of how things should work. These aren’t secondary concerns anymore. They’re primary.

And that’s what designers are trained to think about.

The Founding Designer Advantage

When a designer is there from day one, something interesting happens. The product doesn’t just look different. It’s conceived differently.

A founding designer doesn’t arrive to a spec and make it pretty. They’re in the room when you’re deciding what to build. They’re asking “why would someone do this?” before you write any code. They’re thinking about the user’s mental model while you’re thinking about the data model.

This isn’t the same as having a designer you hire early. There’s a psychological difference between someone who joins a company and someone who co-creates it. Founding designers have the standing to push back. They can say “this entire feature is solving the wrong problem” without it being a career-limiting move.

I’ve seen founding teams with designers make better architectural decisions. Not because designers understand databases, but because they won’t let you build something users won’t comprehend. That constraint forces clarity.

The Pattern

Here’s what I notice in startups with founding designers: the product does fewer things, but each thing makes more sense.

Teams without designers in the founding stage tend to build in an accretive way. Engineer thinks of a feature, it gets built, it goes in the product. Six months later you have 30 features and users can’t figure out how to do the basic thing.

Teams with founding designers are more disciplined. Not because designers are against building features, but because they’re constantly modeling how this looks from the outside. They’re thinking about the new user’s first five minutes, which forces you to prioritize ruthlessly.

This matters more than it used to. When you could grow through sheer technical innovation, feature sprawl was forgivable. Now, when users have infinite alternatives, confusion is death.

What Founding Designers Actually Do

The best founding designers I know don’t think of themselves as “the design person.” They think of themselves as co-founders who happen to use design as their tool.

Read more

Here are my favorite design hacks from building 100+ Lovable projects:

𝟭/ 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗮 𝗰𝗹𝗲𝗮𝗿 𝘃𝗶𝘀𝗶𝗼𝗻
Tell Lovable exactly what you’re building. Keep it high-level but outcome-driven.
Example: “Design a mobile-first habit app for busy creatives.”

𝟮/ 𝗗𝗲𝗳𝗶𝗻𝗲 𝗹𝗼𝗼𝗸 & 𝗳𝗲𝗲𝗹
Use emotional language to set the tone.
Example: “Ultra-m…

Read more

Something different is happening in software teams right now. Designers are shipping code. Engineers are making design decisions. And the boundaries that used to define these roles are dissolving.

AI is transforming how we build software, and in doing so, it’s blurring the lines between designers, engineers, and product managers. As tools like Codex, Cla…

Read more

There’s a pattern I keep noticing in the most successful founders, and it’s not what I expected. It’s not that they’re engineers or designers, it’s that the best ones think like designers, regardless of their background.

This matters because it contradicts the conventional wisdom about what makes a good founder. For decades, the archetypal founder was an engineer. There were good reasons for this. Starting a company meant building something, and engineers were the people who could build things. But I think we’ve been confusing a historical accident with a law of nature.

The thing about historical accidents is that they persist long after the conditions that created them disappear. And the conditions that made engineering the obvious path to founding are disappearing faster than most people realize.

What’s actually hard now

Here’s what’s really happening: the bottleneck in startups is shifting from “can you build it” to “do you know what to build.” That might sound like a subtle distinction, but it changes everything.

When the bottleneck was building, engineers had an obvious advantage. They could turn ideas into reality without the coordination cost of explaining what they wanted to someone else. Speed mattered more than precision. You needed to iterate fast, and iteration was fastest when you could code.

But as tools improve (and they’re improving exponentially now), the ability to build is becoming less of a constraint. It’s not that building is easy, it’s that the gap between having a clear vision and manifesting it is shrinking. What’s becoming more valuable is the clarity of vision itself.

This is where something interesting reveals itself. The engineers who succeed aren’t just good at building - they’re good at knowing what to build. They think about user experience. They obsess over details. They have strong opinions about how things should feel. In other words, they think like designers, even if they came up through engineering.

I’m seeing this strongly at Lovable. Both founders are engineers. But what makes them effective isn’t just their technical ability but the way they’re deeply involved in every product decision. They care about the experience, not just the functionality. They can build anything, but more importantly, they know what’s worth building.

Experience as product

The designer mindset is becoming the founder mindset. Not design as in making things pretty, but design as in deeply understanding what something should be before you build it.

There’s a reason this matters now more than before. As markets mature, the bar for “good enough” keeps rising. In 2008, if your product worked at all, that was notable. In 2024, working is the baseline. The question is: does it feel inevitable? Does it feel like it was made for me?

Thinking about how products make us feel, not just what they do, used to be considered optional. Something you’d add later, after the “real work” of building was done. But I think we’re realizing that’s backwards. The experience is the product. Everything else is just implementation detail.

This is where the traditional division between design and engineering starts to break down. The best founders don’t hand off a spec and wait for it to come back. They’re in the details. They’re making decisions about interaction patterns and information hierarchy and the hundred tiny choices that add up to something feeling right or wrong.

Brian Chesky talks about this with Airbnb. In the early days, they obsessed over details that most people dismissed as cosmetic. The quality of photos. The booking flow. The tone of emails. All of these “details” were foundational decisions that shaped what Airbnb became. You couldn’t get people to stay in strangers’ homes without building trust, and trust was built through a thousand tiny signals of care.

The conventional wisdom said: build something that works, then make it pretty. But Airbnb’s insight was that for their product, those things were inseparable. The “pretty” was the “works.”

I think this pattern is becoming universal. The products that break through aren’t just functional, they feel different. They have a point of view. And having a point of view about experience is increasingly what separates success from failure.

Why this matters now

Here’s why this matters right now: we’re at a moment where the technical barrier to building is collapsing. AI tools are making it possible for more people to turn vision into reality. But that doesn’t mean building is becoming easy. It means the constraint is shifting. If everyone can build something that works, the winners will be the people who know what’s worth building.

Read more

Why do so many products feel soulless?

The next wave of great products won’t be defined by what they do, but by how they make us feel.

We made technology powerful. Now it’s time to make it kind.

We Optimized Ourselves Into a Corner

For the past decade, design has worshipped at the altar of efficiency. Make it faster. Remove every ounce of friction. Optimize…

Read more

The best companies aren’t run by people doing jobs. They’re run by people acting like the company is theirs. High urgency. Deep customer obsession. A willingness to push far beyond any job description.

I realized this early at Lovable. From the start it was obvious that everyone cared about the product and the company vision with an intensity I hadn’t se…

Read more