This website uses cookies

Read our Privacy policy and Terms of use for more information.

The barrier to building a software product just disappeared. A weekend, some coffee, and the right no-code stack—and you've shipped something functional. Elena Verna (Growth at Lovable) caught this early and called it the mom-and-pop SaaS era. She's right. But she's wrong about who wins.

You've probably read her piece. It's a smart observation: tooling has gotten cheap enough, APIs are accessible enough, and no-code platforms are mature enough that a solo founder with a weekend and some coffee can now build a functional software product. No cloud infrastructure expertise required. No 18-month development timeline. No $500K fundraise. The magic happened quietly, and Elena caught it.

But there's something her piece gets right on timing and completely wrong on the implications for who actually wins. The agencies she mentions as tomorrow's SaaS builders do have repeatable methodologies. The people I work with at Agency Focus have IP that could be implemented in software. One particular company could productize its revenue methodology. Another client could package its client playbooks. A third could turn its prospect research motion into a tool. And yeah, they could probably prototype a functional SaaS this weekend.

Here's where the real story starts: having a product is not a business. It never has been. But it's especially not a business when you're an agency founder who just spent a weekend building software and assumes the hard part is over.

The technical win is the easiest part.

Let's be direct about what's happened. No-code tools like Zapier, Make, and Bubble. APIs that you can bolt together with a few SDK calls. ChatGPT can write your first backend code. Cloud infrastructure costs pennies. The technical barrier to shipping a minimum viable product is gone.

This is definitely good news. That means talented domain experts can now translate their expertise into software without learning to code or burning cash on engineering teams. An agency founder with a repeatable process can test whether that process generalizes beyond their own walls in a matter of days rather than months.

But here's the problem: founders mistake speed at the technical layer for readiness at every other layer.

A founder who codes a working SaaS in 48 hours usually stops there. They've shipped something functional, something that actually works. Then they assume that market fit is built in. After all, they use it every day. It solves a real problem. It's clean. It's faster than the manual way they used to do it.

So they tell three friends, post about it on LinkedIn, and wait for the inbound.

Six months later, they have a product that works and a business that doesn't.

The issue isn't the product. The issue is that they've never been forced to answer the questions that separate a tool from a business. What is the unit of sale? Who is the actual buyer? How do you find them repeatedly? What's your pricing model? How much does it cost to support? What's your churn? At what CAC does the math break?

An agency founder can avoid these questions because they already have a business. The agency is paying the bills. The software is a side project, a future bet, a hedge. They can afford to learn slowly.

But that learning generally occurs at precisely the wrong time—once they've already built the product the wrong way.

The Generalizability Problem No One Sees Coming

Here's a sharper version of the trap: most agency methodologies don't actually generalize.

This is the distinction that kills almost every agency founder who tries to productize. Their Hidden Pipeline Playbook works. Their Plinko pricing framework works. Their ICP Scoring Rubric works. But it works inside the context of their specific agency, with their specific clients, solving their specific vertical. The work is repeatable for them. It's not repeatable at scale.

Take the ICP Scoring Rubric. For a manufacturing-focused agency, the rubric scores are based on company size, geography, industry certification, buyer title, and budget authority. Clean, methodical. But an ICP scoring rubric for a fintech-focused agency looks completely different. Different buyer titles. Different budget thresholds. Different certifications that matter. A SaaS founder looks at this and thinks, "Easy. I'll just make the scoring configurable."

Configurable means custom. "Custom" means every customer has to set it up themselves. Setup requires training, support, documentation, and a sales conversation in which you've stopped being a product company and become a services company again. At that point, you're not selling software. You're selling onboarding. Your margins are gone before you've signed your second customer.

The successful path requires a brutal choice: what are the truly universal parts of your methodology, and what are the parts that only work for people exactly like you?

Most founders never make this choice. They ship a flexible product, try to sell it to multiple verticals, and then spend the next year customizing it for each customer. The SaaS business dies because it was always consulting in disguise.

The Sales Motion Trap

Founders revert to the sales motion they know.

When the product ships, agencies expect consulting-style sales to work. Land a meeting with a prospect, deeply understand their needs, position the software as a solution to their specific problem, customize some features, and negotiate the deal. Land and customize. White-glove. One-off pricing for high-value customers.

This works great for consulting. It's how they've built their entire business. It's what they're good at.

But it's the exact opposite of how software scales.

SaaS sales are different. It's a repeatable motion. Standard pricing. Land and expand, not land and customize. The product should work out of the box for 80% of users. The remaining 20% probably shouldn't be customers, or they should pay more for services to implement their custom use case. Every feature request is the beginning of a conversation about whether this is a product to build or a service to sell.

When software sales don't immediately work — and they won't, because the product was built for their use case, not a generalized one — founders fall back on what they know. They start customizing. They take the product back to being a service. The margins collapse because now you're supporting everyone's one-off configuration. Support costs spike. The business looks exactly like it would have looked if they'd just hired a contractor and skipped the SaaS fiction entirely.

This usually happens at month three or four. By then, they've already sunk time and attention into the agency that should have gone into the agency. The worst-case scenario is that they're now running two businesses poorly instead of one well.

The Opportunity Cost Nobody Quantifies

Here's the angle that doesn't make it into pitch decks: building a SaaS business costs attention.

An agency founder already has a business. It's paying them. It has clients, team members, and problems that need to be solved today. Building SaaS on top of that — even a SaaS that you're doing on nights and weekends — requires context switching. It requires you to be good at two completely different things: one-on-one client relationships and one-to-many product relationships.

Most founders are not good at both. They're usually great at one.

The attention cost of building a bad SaaS business can destroy a good agency business. You spend months building a product that doesn't generalize. You spend more months trying to sell it, like consulting. By the time you realize the model doesn't work, you've diverted your best thinking away from the business that's actually working. Your team notices the distraction. Your agency growth slows.

Then you have to make a choice: kill the SaaS and commit to the agency, or push harder on SaaS and let the agency coast. Both are losses at that point.

The right time to build a SaaS business is when you have absolute clarity on three things: which parts of your methodology actually generalize, whether you can build a repeatable sales motion that's different from consulting sales, and whether you can operate two businesses at the same time without one poisoning the other. Most founders don't have that clarity until they've already built the product.

What This Actually Requires

If the barrier to building a SaaS product is gone, the barrier to building a SaaS business is now everything else.

The clarity work: mapping which ops are truly repeatable versus which are just "how we work." Understanding your unit economics before you code anything. Modeling what CAC, LTV, and churn actually look like for a software business selling to your market. Deciding whether you want a SaaS business or just want to own your own IP — these are different things.

The sales work: building a repeatable, scalable go-to-market that doesn't require white-glove customization. Understanding that most of your potential customers probably shouldn't be your customers. Pricing for software, not consulting.

The hard choice: sometimes the right answer is "We should not build a SaaS. Our competitive advantage is the methodology, and we should own that through the agency model and the bodies and the relationships." That's a legitimate conclusion. Most founders don't get there because they're too excited about the technical novelty of shipping a product. And that excitement costs them.

What Changes For Growth Consultancies

The agencies that will win this moment are not the ones that build the prettiest software in a weekend. They'll be the ones who understand that having a product is not a business—and they'll be disciplined about answering that before they code.

For consultancies helping agency founders navigate this, the mandate shifts.

It used to be "Help them build a SaaS." Now it's "Help them figure out if they should build a SaaS, and if they do, help them understand what it actually takes to sell it without collapsing their agency."

That's a different job. It's messier. It's a conversation about the business model, not the product. It's mapping which parts of their ops generalize and which don't. It's modeling unit economics before code is written. It's building a separate sales motion that looks nothing like how they sell consulting. It's deciding whether the SaaS business is a hedge against agency volatility, a path to higher margins, an exit strategy, or a distraction.

The founders who figure this out will have the advantage. They'll know whether to build. They'll know what to build. They'll know how to sell it. And they'll know how to operate it without destroying what's actually working.

Everyone else will spend the next year shipping a nice-looking product that solves all the wrong problems, only to wonder why it doesn't sell.

The weekend to build a SaaS is over. The hard part — the business part — is just beginning.

Reply

Avatar

or to participate

Keep Reading