TL;DR:

When a founder asks for "something like Airbnb" in six weeks, they're not describing a product, they're describing three separate products stacked on top of each other, each one a multi-month engineering effort in its own right. The Iron Triangle is not a suggestion. Scope, timeline, and budget are mathematically linked, squeeze one, the others break. The way to serve this client isn't to say yes. It's to show them what they're actually asking for, help them find the version that's actually buildable, and move fast on that. Here's how we think about it.

The call

It started, as these things always do, with a message that felt exciting.

"Hey, I have a great idea for an app. Something like Airbnb, but for dogs. Dog sitters, walkers, boarding. And I'd love it to have a social feed too, like Instagram but for pets. Think community, UGC, viral content. Oh and ideally an AI matching feature. We'd need it live in about six weeks. Budget is flexible."

Budget is flexible. Those three words. We've learned they almost always mean "I have no idea what this costs and I'd prefer not to find out."

We didn't laugh. We've heard this before, not in those exact words, but in that exact shape. The ambition is real. The gap between ambition and the reality of building software is also real. And the painful truth is that most studios either take the brief at face value and fail the client, or they quote an astronomically large number and lose the deal. Neither outcome helps anyone.

So we sat down and did the math. Out loud. With the client. That's where it got interesting.

The problem, by the numbers

Let's take the brief apart.

"Something like Airbnb" is a two-sided marketplace. That means two user types (in this case, dog owners and sitters/walkers), separate onboarding flows, listing creation with geo-search, calendar availability management, in-app booking, payment processing, reviews, trust signals, insurance/liability considerations, and a backend that doesn't fall over when two people try to book the same golden retriever daycare slot simultaneously. According to multiple development cost analyses, a basic Airbnb-like marketplace, one platform, no frills, runs between $40,000 and $150,000, with timelines of 9 to 18 months for a production-ready version. That's the floor, not the ceiling.

"But for dogs" is not a modifier. It's a vertical-specific layer. Breed filtering, pet health records, vaccination uploads, emergency vet contacts, pet profiles with photo management. Each of those is a feature sprint. Each sprint is weeks, not days.

"Also a social network" is a separate product. Building a social feed with user profiles, follows, content creation, commenting, notifications, moderation, and algorithmic ranking costs between $60,000 and $300,000 and typically takes 6 to 12 months for even a stripped-back version. A full-scale social product, think Instagram's feature surface, can exceed $200,000 and 18 months. This isn't agency markup. It's engineering reality: real-time feeds, content storage, push notification infrastructure, content moderation logic, abuse prevention. These are entire systems, not features you bolt on.

"And an AI matching feature" is a model training problem. You need data to train it. You don't have data yet because the product doesn't exist yet.

"In six weeks." At two senior developers working full-time, that's roughly 480 hours of engineering capacity. The combined scope described above represents, conservatively, 4,000 to 8,000 hours of work.

That's not a gap. That's a different universe.

Why this conversation keeps happening

This isn't a story about a naive client. It's a story about a structural failure in how software gets sold and bought.

Most founders don't have engineering backgrounds. They use apps every day, beautifully designed, seamlessly functional apps, and they absorb a deeply misleading signal: that software is fast and cheap to build, because it's fast and cheap to use. Airbnb loads in under a second. That second represents ten years and hundreds of millions of dollars of engineering.

The problem compounds when studios play along. A client asks for something big and vague, the studio quotes a number that seems "reasonable" (i.e., the number they think won't scare the client away), the project begins, and then reality hits about six weeks in. Scope creep, the gradual, often invisible expansion of what's being built, kicks in. According to PMI research, 78% of software projects experience scope creep. Only 31% of projects successfully meet all three constraints of on-time, on-budget, and on-scope delivery. For small companies specifically, the average cost overrun is 214% and the average time overrun is 239%. Scope creep, left unchecked, can cost up to four times the initially estimated development budget.

This is the Iron Triangle. It's been a known concept in project management since the 1950s. It says: you can control scope, time, or cost, but you cannot compress all three simultaneously without quality collapsing. Want it fast and cheap? Cut scope. Want it big and fast? Spend significantly more. Want it big and cheap? Accept a much longer timeline. There is no fourth option. There never was.

The reason the Iron Triangle keeps being violated isn't ignorance. It's optimism bias, the very human tendency to believe that this project will be the exception. It won't.

Meanwhile, the market context is actually exciting. The pet tech industry is booming: the global pet tech market was valued at $15.6 billion in 2025, with dogs representing over 65% of that market, a segment projected to grow from $6 billion in 2024 to $30 billion by 2035. The demand is real. The opportunity is real. That's precisely why building something half-finished and running out of runway before finding product-market fit would be such a waste. Forty-two percent of startups fail not because of bad execution, but because they built the wrong thing, or too much of the right thing, too soon.

What we actually do in this situation

We don't say no. We also don't say yes to the original brief. We say: let's figure out what you're actually trying to validate first.

The question underneath "Airbnb for dogs with a social network" is usually simpler than the product description suggests. In most cases, the founder is trying to validate one of the following: Can I get supply? (sitters, walkers, boarders who want to list.) Can I get demand? (dog owners who will pay for this.) Do people actually want a community around their dogs, or is it a nice-to-have they said yes to in a survey?

These are three different hypotheses. They can be tested without building all three products simultaneously.

In our discovery process, we push founders toward what we call the single-bet MVP: the smallest possible product that tests the single most important assumption, the one that, if wrong, means the whole business model falls apart. Not the most exciting feature. Not the feature they'd be most proud to show at a dinner party. The one that carries the most existential risk.

For this client, that meant a focused conversation about which side of the marketplace was actually harder to build: supply or demand. In most marketplace businesses, supply is the constraint. A curated database of verified sitters in a specific city, a simple booking flow, a Stripe integration, and a clean landing page, that's a six-week build. That's a real MVP. The social feed? That's version two, after you've confirmed that dog owners will actually pay for a booking and return to do it again.

This matters because AI-accelerated development has genuinely compressed some timelines. We can move faster than a traditional agency at every layer, rapid prototyping, AI-assisted code generation, design system reuse, but physics still applies. What used to take 6 months can now take 2. What used to take 6 weeks still cannot take 6 weeks if it's three months of work.

The biggest service a studio can provide is not saying yes faster. It's giving a founder an honest map of the territory so they can make a real decision about where to go first.

The honest math

Six weeks. That's 42 days. In the context of software, here's what 42 days can build, if scoped correctly, with the right team, moving at speed: one clean user type, one core user journey, one payment integration, one polished onboarding flow. Deployed, tested, live, and ready to acquire your first 100 users.

That's not a compromise. That's a strategy. Airbnb's first version was three air mattresses in a San Francisco apartment and a website with photos. It wasn't a social network. It didn't have AI matching. It had one bet, placed clearly, on one hypothesis: will strangers pay to sleep in someone else's house?

They found out the answer was yes. Then they built everything else.

The clients who win aren't the ones who try to build the whole vision at once. They're the ones willing to get embarrassingly specific about what they're testing next.

Conclusion

The market for dog-adjacent apps is genuinely large and genuinely underserved. The instinct behind "Airbnb for dogs with a social layer" isn't wrong, it's early. And early, in the hands of the right team with the right scope discipline, is an advantage, not a problem.

But scope discipline requires honesty. It requires someone in the room to say: here is what you're actually asking for, here is what it costs and how long it takes, and here is the version of this that you can actually ship this quarter and learn from.

Most studios won't have that conversation because they're afraid of losing the deal. We've found the opposite is true. Founders respect honesty. They've often felt something was off about the brief themselves, they just needed someone to confirm it and redirect the energy productively.

Here's the question worth sitting with: If you could only test one thing about your product in the next six weeks, just one, what would it be? Because that's your actual MVP. Everything else is a future sprint.

What's yours?