Our Manifesto

Why "SaaS is dead" gets it half-right

SaaS isn't dead. Generic SaaS is.

The dominant narrative says SaaS is dead. Scroll any tech feed and you'll find another eulogy for the subscription model, another prediction that AI will eat every incumbent. It makes for good content. It also gets the diagnosis wrong.

The SaaS commercial model works fine. Recurring revenue, hosted software, an ongoing relationship between maker and buyer. That's a sound business structure. What's broken is the product inside the wrapper: software designed by committee for the universe of customers, then forced to fit each buyer afterward.

You know the symptoms. Feature requests that enter a queue and never ship, or ship a year later in a form that doesn't match what you actually needed. Roadmaps driven by whatever the largest customer demands, leaving everyone else underserved. "Best practices" baked in that may not be best for your business.

The alive thing isn't the death of SaaS. It's the death of generic SaaS, and the rise of software shaped to the business that uses it. Bespoke. Yours. Shipped fast enough that you don't have to wait for someone else's roadmap to catch up with your reality.

The end of off-the-shelf

What "designed by committee for the universe of customers" actually produces.

Off-the-shelf software starts with a reasonable ambition: build once, serve many. But "serve many" inevitably becomes "satisfy none." The product committee adds toggles, the settings panel grows another tab, and the thing that was supposed to save you time now requires a three-day onboarding just to configure.

This is what "designed by committee for the universe of customers" actually produces. A bloated middle ground where no single customer gets what they need, but every customer pays for features they'll never use. The mediocrity of one-size-fits-all isn't a failure of execution. It's the logical outcome of the model.

Every business is different. The workflows that make a dental practice hum have nothing in common with those of a logistics company. Yet generic SaaS asks both to bend their operations to the same template, then calls it "industry best practice."

The end of off-the-shelf isn't a prediction. It's already happening. AI has collapsed the cost of building custom software to the point where bespoke is no longer a luxury reserved for enterprises with seven-figure IT budgets. The question isn't whether off-the-shelf will be replaced. It's how fast.

Your business shouldn't bend to your software

You already know how to run your business. We codify it into software.

The traditional SaaS pitch tells you to adopt their best practices. Import their templates. Follow their workflow. Reshape your operations to fit their product. The implicit message: we know how to run your business better than you do.

We invert that entirely. You are the expert on your business. The way you already work, the processes you've built, the shortcuts you've discovered, the judgment calls you make every day: that's not something to be replaced. It's something to be respected.

Pebble House builds software that fits the business, not the other way around. We call it fidelity-to-workflow: the principle that the customer's existing process is usually right, and our job is to remove friction from it rather than teach them a new way.

This isn't a semantic distinction. It changes what we build, how we build it, and who we listen to. The customer is the domain expert. We're the technical partner who codifies their expertise into software that's only theirs.

Stop waiting for the feature request

Stop waiting for the feature request.

You know the feeling. You open a support ticket. You describe exactly what you need: the integration, the report, the workflow adjustment that would save your team hours every week. The response comes back: "Thanks for the feedback! We've added it to our roadmap."

And then nothing. Or worse, something ships eighteen months later that's been committee-reviewed into a shape that no longer solves your original problem. You're paying monthly for software that doesn't do what you need, and being told to wait for a roadmap you have no control over.

"In days, not next year" isn't a slogan. It's what happens when you remove the committee, the roadmap negotiations, and the universal-customer constraint. When the software is built for you, features ship when you need them — because there's no queue of ten thousand other customers ahead of you.

Stop waiting for the feature request. Stop compromising on what your business actually needs. The technology to build exactly what you want, exactly when you need it, already exists. The only question is whether you keep waiting or start building.

The software you wished existed

We build the software you wished existed.

Everyone who's used business software has had the same thought: "Why can't it just do this?" You can picture the version that would actually work for you. The dashboard that shows what matters to your business, not what matters to the average business. The workflow that matches how your team actually operates.

That gap between the software that exists and the software that should exist used to be something you just lived with. Custom meant expensive. Custom meant slow. Custom meant a six-month consulting engagement before a single line of code got written.

That's no longer true. AI hasn't just changed what software can do. It's changed how fast software can be built. The version you imagined, the one that fits your business like it was made for you, can exist in days. Not because corners were cut, but because the building itself got faster.

We build the software you wished existed. Not an approximation. Not a "close enough" configuration of someone else's product. The actual thing, shaped to your workflow, owned by you, maintained for you.

We're not anti-contract. We're anti-generic.

The contract gets you bespoke software, not generic software.

There's a narrative in tech right now that the subscription model itself is the problem, that contracts are inherently exploitative, that recurring revenue means the vendor stops caring after the sale. That's not our position.

Pebble House sells contracts. Customers pay for engagements, for builds, for ongoing maintenance and operation. The commercial structure of SaaS (recurring revenue, hosted software, an ongoing relationship) is fine. What matters is what the contract gets you.

In generic SaaS, the contract gets you access to the same product everyone else has, with the same limitations everyone else faces. In our model, the contract gets you bespoke software, shaped to your business, only yours, maintained and evolved for you. Same financial commitment, dramatically better outcome.

We're not anti-contract. We're anti-generic. The commercial model isn't the problem. The product is. Fix the product, and the model works the way it was always supposed to.

How a pebble earns its place

Not everything Pebble House builds starts with a customer contract. We also build pebbles, our own products that live alongside our engagement business. But we're honest about where they come from.

Some pebbles are demand-born: they started as bespoke builds for real customers. We observed the same problem repeating across a tight niche, then productized the solution. These pebbles are crystallized from custom work, niche-native by design, not retrofitted from a generic starting point.

Others are lab-born: curiosity-driven experiments we built to test a hypothesis or play with an idea. Whether they convert to commercial products is genuinely uncertain. We ship them because we're builders, and builders build.

This honesty matters. It prevents the apparent contradiction of preaching anti-generic SaaS while also shipping products. Demand-born pebbles are productized bespoke, the opposite of generic SaaS in DNA, even if similar in form. Lab-born pebbles are honest experiments, clearly framed. Current pebbles include Willit, Atlas, Luma, and Task, each with its own origin story and its own reason for existing.

Practitioners, not pundits.

We have the experience of building stuff in production, not just coming in as consultants and telling you how to run a business.

There's a version of consulting where a team of analysts arrives with frameworks, runs workshops, delivers a slide deck, and leaves. The recommendations look sharp on paper. Whether they work in practice is someone else's problem.

That's not what we do. Pebble House advises from the operator's chair, not from the consultant's podium. We've built and shipped production software repeatedly, across industries, under real constraints. When we tell you something works, it's because we've done it, not because a framework says it should.

This is the line between practitioners and pundits. Pundits theorize. Practitioners ship. Most management consultants are career analysts who've never run a company, claiming to know how to run yours. We've been in the chair. We've dealt with the prod outage at 2 AM, the customer escalation that rewrites priorities, the build that needs to ship before the demo.

Advisory and Build are two modes of the same relationship at Pebble House. Clients flow between them: we figure out the right approach, then build it. Or we build it, then help your team operate it. The credibility in our advice comes from the same source as the quality in our builds: real production experience.

What Pebble House does

No best practices. Just your practices, codified into software that's only yours.

Pebble House operates across two surfaces. The Studio is where relationships live: Build mode for custom software shaped to your business, Advisory mode for operator-led guidance on thinking AI-native. Clients flow between both modes within a single engagement, strategy and execution under one roof.

Then there are the Pebbles, our own products, born from customer demand or from the lab, each with a clear origin story and a specific niche it serves. They're a separate product line, not the headline offer, but they demonstrate what we believe: that software should be built for the business that uses it.

This is not a pitch for the future. It's a description of what already exists. The tools to build custom software at SaaS speed are here. The economics work. The only thing that changes is the decision: do you keep waiting for generic software to eventually add the feature you need, or do you build the thing that fits?

No best practices. Just your practices, codified into software that's only yours. That's what Pebble House does.