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 pocket, and you’re the only one connecting them.

That assumption made sense for a long time. Software couldn’t understand plain language, so you had to speak its language instead. Learn where the buttons were. Follow the flows it prescribed. Adapt yourself to the tool. The interface was a layer you had to master before the software could help you.

That layer is now disappearing.

Why every app looks the same

Every piece of software ever built shares the same flaw: it was designed for everyone, which means it was designed for no one. The same buttons, the same flows, the same onboarding - for the enterprise buyer and the solo freelancer and the student, all at once. Building software was expensive, so companies spread that cost across as many users as possible and hoped people would adapt.

Adapting meant learning. Learning took time. Every piece of software you’ve ever used started out costing you something before it gave you anything back.

That was the deal and you accepted it because there was no alternative. Now there is.

What a generative interface is

For most of software’s history, an interface was something designed in advance - fixed menus, set flows, predetermined options. You opened an app and found a structure someone else had decided on. Your job was to navigate it.

A generative interface has no predetermined rules. It assembles itself from context, in the moment, for this person and this task. The smarter the system, the less UI you need.

Think about booking a flight. Today: open the app, search by date, filter by price, scroll through options, click through to seat selection, enter payment, confirm. Twelve steps, if nothing goes wrong.

A generative interface knows your calendar. It knows your preferences. It knows who you’re traveling with and whether you prefer aisle or window. You say “I need to get to Stockholm for a Lovable event” and it comes back with three options, pre-filtered, ordered by what actually matters to you. You pick one. Done. The interface generates itself around the task and vanishes when the task is complete.

The app of the future isn’t a place you go. It’s the response that appears when you need it.

The app store era is ending

When Steve Jobs announced the App Store in 2008, the model felt inevitable: every function in its own container, discoverable in a marketplace, downloaded to your device. Each app was a specialist you hired for a specific job. The problem with specialists is that they don’t talk to each other - and you’re the only one doing all the coordination.

Generative interfaces change that. You don’t need fifty separate apps. You need one system with enough context about you to surface the right thing at the right moment. The capabilities remain but the different containers dissolve.

There’s a second disruption happening alongside this one. People aren’t just navigating apps differently - they’re skipping them entirely. AI can now turn a plain language description into working software in minutes. You don’t need to know how to code. You describe what you need, and the software gets built.

I see this happening at Lovable every day. Users aren’t primarily technical founders. Many are individuals solving personal problems - workflows they couldn’t find apps for in random marketplaces. A custom CRM shaped to how their sales process works. A tracker for one metric no existing dashboard exposes. They basically just build it, use it, and move on.

The distance between “I need something” and “I have a something” is fundamentally collapsing. Downloading someone else’s app - with all its compromises and onboarding flows and pricing tiers - is starting to feel like the slower option.

I don’t think apps will disappear overnight. But there’s some real change happening and the more I think about it the more I get excited about these two directions. Interfaces are becoming generative on demand and users are becoming builders instead of consumers.

The patience problem

There’s also a psychological shift happening alongside the technical one, and it might be the more consequential.

Every time software gets faster and more responsive, our tolerance for friction shrinks. It happened with page load times. It happened with streaming. Each improvement in convenience doesn’t just satisfy us but radically recalibrates what we’re willing to put up with.

Think about it. Generative interfaces are doing this at a different scale. When software can understand what you need and handle it directly, navigating a ten-step flow doesn’t just feel inefficient. It feels completely broken. The baseline and expectation of people is different now.

And it compounds. The more capable generative interfaces become, the more impatient users get. The more impatient users get, the less forgiving they are of anything that makes them do unnecessary work. It’s a one-way street. Expectations do not reset.

For anyone building software today, this is something you need to take into consideration: you’re not just competing with other apps in your category. You’re competing with the experience of software that simply understands you. It’s a moving target, and it’s moving fast.

What comes next

It seems like building apps for everyone was always a workaround. We built containers because software couldn’t meet us where we were. Now it can.

What’s interesting about this moment is not just the technology but also the timing. Interfaces are becoming generative at exactly the same moment users are running out of patience or building products simply themselves.

Most companies won’t see this coming, but I can promise you all of these observations are happening already today. Don’t optimize onboarding flows or debate about navigation structures. Go figure out how you can build a system around context so you are perfectly equipped for the new era of generative interfaces.

When I think about this long-term it’s pretty clear to me that interfaces assemble themselves on demand, around a task, and disappear when it’s done. But the short-term implication is just as important, and more perhaps even actionable: you need to deliver value before the user has time to lose patience.

I call this instant value. Strip everything that doesn’t directly serve the reason someone showed up. No lengthy onboarding. No tutorial screens. No warming up. The first moment a user touches your product should already be giving something back. Not promising value but delivering it.

There’s a tension worth naming here. Instant value gets people in. But trust is what keeps them. And trust is harder to build when the interface is generated on demand. In a world of generative interfaces, trust will have to come from somewhere else: from consistency of outcomes, from transparency about what the system knows and how it’s using it, from the feeling that the AI is working for you and not around you. It’s a design problem nobody has fully solved yet. But it’s the right problem to be working on.

Interfaces aren’t going away. They’re just no longer designed in advance -they’re generated on demand, for you, in the moment you need them.

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

Over the past weeks I collected my favorite prompts and turned them into one "master directory" so you can just copy + paste what you need.

Prompts you'll find:
👉 Foundation (auth, users, settings)
👉 Core UX & UI (dashboards, file uploads, realtime)
👉 Collaboration & Growth (teams, invites, notifications)
👉 Monetization (Stripe, PayPal, billing)
👉 Integ…

Read more

After 100 hours of prompting AI for UI design, I discovered most designers are doing it completely wrong.

The difference between getting generic templates vs. production-ready components comes down to 10 specific techniques.

Here’s what I learned:

Lesson 1: Specificity beats creativity
Bad prompt: "Design a dashboard"
Good prompt: "SaaS analytics dashboard, …

Read more