Why Steve Ruiz Didn't Build Lovable — And Why Infrastructure Wins

In 2024, Steve Ruiz shipped Make Real: a tool that turned sketches into working HTML code using GPT-4 Vision. It was genuinely mind-bending. You’d draw a button. Click a button. Get code. The internet broke. Founders everywhere asked the obvious question: “Why aren’t you selling this as a product?”

Two years later, Lovable and Bolt did exactly that — turned sketch-to-code into a direct-to-consumer product. They raised millions. They’re making money. And Ruiz is still running tldraw, the infrastructure underneath.

When Angelina asked him directly, his answer wasn’t defensive. It was architectural.

“I mean, you sound like my investors,” he laughed. Then he laid out the argument that separates infrastructure founders from product founders.

The Timing Problem

First, the practical constraint: when Make Real launched, the GPT-4 Vision APIs were so fresh that the only way to let people use them was to have users bring their own API keys. Ruiz couldn’t have built a business model around it even if he’d wanted to.

“Each API key only had whatever 30 responses per day allowed. And when I did eventually get on the phone with OpenAI, they’re like, how are you doing this? Are you account sharding? Are you registering multiple? I’m like, no, but kind of. It’s just everyone’s bringing their own account.”

But there’s a second layer to the timing problem that’s more interesting: Make Real felt like a pattern, not a product.

“Teal Draw, this did not feel like a product, this felt like a pattern, right? This idea of taking drawings and diagrams and using them as input into AI models felt like 1,000 products, 1,000 applications rather than just one.”

That distinction is everything. A pattern is something you build once and let others build on. A product is something you optimize for a specific user and use case.

Why 1,000 Products Are Better Than One

Once Ruiz recognized Make Real as a pattern, the strategic question became: do I own the pattern, or do I own the applications built on top of the pattern?

Lovable chose the applications path. They own the product. They control the UI, the pricing model, the feature roadmap. It’s a venture-scale business if it works.

But there’s a ceiling. Lovable is great at turning sketches into React websites. It’s not great at turning sketches into circuit diagrams, or product specs, or data visualization workflows, or any of the thousand other things you might want to sketch into existence.

“I think it’s a bigger opportunity, like long term,” Steve says. “I do think that there’s going to be and there’s going to continue to be a big expansion of apps that want to take advantage of this type of software. And I want to be the software that they build on.”

This is the infrastructure thesis: instead of owning one application of the pattern (Lovable), own the layer that all applications need. Let the market discover the thousand products. You provide the foundation.

The Evidence Is Hiding in Plain Sight

The strongest evidence for Ruiz’s bet is that it’s already working. tldraw is generating revenue from dozens of companies building dozens of products. UX Pilot uses tldraw to let designers generate UI. Variant.ai operationalized Make Real’s concept for a different use case. Magic Path does something else entirely. Observable created a spatial data notebook. Shopify built internal tools.

Those companies didn’t choose tldraw because they wanted to use a whiteboard. They chose tldraw because they wanted to build something that required a canvas, and tldraw was the only game in town.

“We don’t sell to individuals. We sell to teams,” Ruiz explains. “We have one price. If you’re under 10 people and then if you’re more than 10 people, we negotiate a price.”

That’s the infrastructure pricing model. You’re not selling seats or usage. You’re selling the layer that your customers’ entire product is built on. That’s higher price power and deeper lock-in than any individual product could achieve.

The Evangelism Problem Lovable Never Had

Here’s what’s interesting: Lovable had to solve a hard evangelism problem. They had to convince non-technical founders, designers, and PMs that sketch-to-code was worth using. They spent marketing budget proving the concept over and over.

tldraw solved a different problem: building such a compelling platform that product teams had to evangelize for them. The community built 800+ projects. Developers discovered tldraw because they saw what you could do with it, not because they saw a TikTok ad.

“My bet has always been that by making the canvas available, people will do really interesting things with the canvas,” Steve says. “And that’s what we’ve seen.”

Grant Cōte built a liquid simulation. Designers started using it for tutoring. Data engineers embedded it into Jupyter-style notebooks. A Chinese Bible study community uses it for collaborative markup. None of those were planned feature launches. They were discovery. They were people finding unexpected value in an open foundation.

Lovable has to market to designers and product managers. tldraw gets marketed by the developers, designers, data engineers, and AI researchers who build on it.

The AI Timing Advantage

There’s one more angle: AI is moving so fast that betting on a fixed product (Lovable) means you’re constantly chasing. Bet on a foundation (tldraw) and the market brings the use cases to you.

When Make Real launched, nobody knew what it would be used for. Lovable bet it would be sold to non-technical founders doing UI design. That’s probably 30% of the actual value. The other 70% is PMs using multi-stage prompting, marketers building campaign generators, data engineers embedding it in notebooks, and a hundred things that Lovable can’t pivot to without rebuilding the company.

tldraw, by contrast, is still tldraw. It works for all of those use cases because it never specialized for one.

“Even though I know, Lovable and Bolt and everything are making a lot of money, you know, we’re making money too, but not vibe coding up money, although we probably spend a lot less on credit or on tokens,” Steve says. “I think it’s a bigger opportunity, like long term.”

The Founder’s Constraint

This argument only works if you have the conviction to stick with infrastructure when the market is screaming for you to build a product. Investors want to see 10x revenue. You don’t get that from an SDK. You get it from a product with viral growth.

Ruiz chose a longer, deeper bet. It’s the infrastructure founder’s version of the red Mars thesis that he cited in the closing: if you have time, you can afford to go deep on a problem no one else is touching.

“I think I can sell to this market as well and I think I can go so deep on the problem of how do you build the undifferentiated part of a canvas, build the engine for a canvas that it becomes an obvious choice for companies and teams to do this.”

Not the most exciting product story. But it’s the truest one.

FAQ

Did Steve regret not building Lovable once he saw them succeed?

No. His comments were positive about Lovable’s success, but he genuinely believes the long-term value of infrastructure is higher. He’s making money, his team is small and sustainable, and the market is validating the bet every quarter with new products built on tldraw.

Is the infrastructure vs. product decision just about risk tolerance?

Partly, but it’s also about what you believe is a bigger market. Lovable is fighting for a slice of the design-to-code market. tldraw is powering dozens of different markets (data viz, tutoring, AI agents, internal tools). If you think markets fragment, infrastructure wins. If you think one product dominates, product wins.

Could tldraw have built Lovable as a feature?

Theoretically yes, but it would have distracted from the core mission. tldraw would become a design tool company with a canvas product, not a canvas company with design tool customers. That’s a fundamental identity shift.

Why does Steve say he spends less on tokens than Lovable?

Lovable has to generate code for every sketch, so they’re spending on API calls for every user. tldraw lets third-party builders decide when and how to call APIs. Less volume means lower infrastructure costs, which means better unit economics.

Will tldraw eventually face competition from “better” infrastructure layers?

Possibly. But the advantage of going deep first is that you solve the hard problems (collaboration, multi-agent coordination, synchronization) before someone else. By the time a competitor arrives, tldraw’s customers depend on it too much to switch.

What about product + infrastructure hybrid models?

Some companies do both (Figma has an API and also makes plugins). But that requires different org structures and incentives. Ruiz’s point is that if you’re an infrastructure founder, go deep on infrastructure. Don’t half-ass the product layer.

Is this strategy only viable for technical founders?

Mostly yes. You need to understand what other builders need, what problems they’re solving, and how your layer fits. Non-technical founders tend to think in terms of features and end users, not in terms of platforms and developer workflows.

Why do investors often push infrastructure founders to build products?

Products have clearer unit economics, faster revenue growth, and more obvious exit opportunities. Infrastructure is slow, compound growth — harder to show a hockey stick on a pitch deck. But the eventual outcome can be larger.

Has the rise of AI changed whether infrastructure or products is the better bet?

If anything, it reinforces infrastructure. AI moves so fast that betting on a specific product (Lovable for sketches) means you’re constantly adapting. Infrastructure that’s flexible (canvas for anything) compounds better across the rapid shifts.

What’s the lesson for builders choosing between infrastructure and product?

If you believe your insight is bigger than one product, go infrastructure. If you believe product excellence matters more than market size, go product. Ruiz clearly believes the canvas pattern is worth betting the company on, and the market is proving him right.