A few years ago I raised $100,000 to build a product.
I burned $90,000 on development.
We shipped. It was fine. And then almost nobody found it, because we had $10,000 left and no audience, no channel, and no plan to reach the people who actually needed what we’d built.
When someone asked me recently what I’d do differently, the answer came immediately: 60% marketing and RevOps. 40% dev. Not because building doesn’t matter — it does — but because I had the ratio catastrophically backwards. I’d treated distribution as the thing you figure out after you build. I was wrong. Most founders are wrong about this. And the economics of software development in 2026 have made being wrong about this significantly more expensive.
Here’s why.
Building Got Cheap. Distribution Didn’t.
The cost of writing software has been in freefall for three years. This is not opinion. It is documented and directional.
A controlled MIT study found developers using AI coding tools completed tasks 55% faster. GitHub Copilot now generates close to half of a developer’s code across 15 million users. API costs to process a million tokens collapsed from roughly $12 in 2022 to under $2 by 2024 — and the price war between model providers is still active. Gartner projects 70% of new enterprise applications will be built using low-code or no-code tooling by 2026, up from less than 25% in 2020.
The summary version: what took a team of ten engineers two years to build in 2015 can now be done by two people in three months. That is not hype. That is where the market already is.
What does this mean? It means your ability to build is no longer a differentiator. It is table stakes. Every AI-native studio that launched in the last 18 months leads with “we build fast and cheap.” They are all right. They are also all saying the same thing.
The question the market is now sorting on is not can you build it — it is do I know you, trust you, and believe you will still be here when something breaks.
That is a distribution problem. Not a technical one.
The Distribution Vacuum Nobody Is Talking About
When the barrier to building drops to near zero, the scarce resource becomes attention and trust.
GTMfund — a VC firm that has backed dozens of software startups — put it plainly: “We see companies with solid products get beaten by competitors with superior distribution all the time. A superior distribution strategy can beat a comparable or even slightly better product.”
This is not a new principle. Marc Andreessen said it a decade ago: the general model for successful tech companies is that they become distribution-centric rather than product-centric. What’s new is the urgency. AI is simultaneously making it easier to ship products and harder to get them in front of anyone. Traditional SEO — the free distribution channel that powered a generation of software companies — is being hollowed out. HubSpot, one of the best-funded content machines in the industry, saw organic traffic reportedly drop by as much as 80% in 2025. When AI answers the question instead of sending the user to your article, the old playbook breaks.
As one analyst noted: “Building a software product isn’t the hard part. It never really was for most companies. But the importance of distribution has never been more important than it is today.”
The studios and founders who will win are not the ones who ship the fastest. They are the ones who already have the relationships, the reputation, and the audience when the client is ready to buy.
What We Did About It — And Why We Shut Down 40 People to Do It
In 2022, we ran Beta Launch — a 40-person software consultancy with clients across five countries. USAID. Takso. MetJip. HAL Capital. 120+ products shipped over a decade.
By any traditional measure, we were succeeding. By our own, we could see the model dying. A large team is a high fixed cost. A high fixed cost means you sell to pay salaries, not because you’ve found the right client. You take projects at the edge of your scope. You hire to fill gaps. You grow the thing that’s eating you.
We shut it down on purpose.
Not because the business failed. Because we understood what was coming: when building gets cheap, the margin lives in trust and process — not headcount. The clients who need you will pay a premium for certainty, speed, and not being burned again by a dev team that disappeared after invoicing them. They will not pay extra simply because you have more people.
So we built specshop.dev as a two-person studio with our own toolchain — spec2web — that lets us maintain at scale what used to need a team. We kept the 9 years of relationships. We kept the track record. We cut everything else.
The unfair advantage was never the technical capability. It was always the distribution: the people who already know us, the reputation earned across 120+ projects, the honesty about what we will and will not take on.
The Question You Should Be Asking Every Studio
If you’re a founder evaluating a dev partner, the conversation has shifted. “Can you build it?” is the wrong question. Almost everyone can build it now.
The right questions are:
- What have you shipped that’s similar to what I need? Not as a credential exercise — as a proxy for whether they understand your user’s problem, not just the technical spec.
- Who else have you built this for, and what happened after launch? Because the build is 30% of the risk. The other 70% is whether it gets used, iterated on, and maintained by someone who still answers their email in six months.
- What is your process before a single line of code is written? Spec-first development — where a client approves the exact behaviour of the product before any code exists — is not a gimmick. It is the only way to prevent the $90,000 lesson I described at the top of this post.
The Ratio
If I were starting again with $100,000:
Enough for an MVP that works, with a process that ensures what gets built is actually what was needed. The spec comes first. The build follows from it.
The channel, the content, the outreach, the CRM, the follow-up sequences, the referral mechanics, the relationships that compound over time.
Not because the product doesn’t matter. It does. But a well-distributed mediocre product beats an exceptional product that nobody can find. The market has proven this repeatedly, and the AI era is accelerating it.
The barrier to building software dropped to near zero. The barrier to trust didn’t move.
That is where the game is now.
Janaka Ediriweera is co-founder of specshop.dev — a two-person AI-native software studio built on a decade of shipping products that reach people. If you’re building something and wondering where to start, the answer is probably not the code.
Sources
Ready to build something that reaches people?
We take on a small number of projects each month. The first step is a 30-minute discovery call — no pitch, no pressure. Just a conversation about whether this is the right fit.
Book a discovery callQuestions we get after people read this
Yes — that is exactly who The Spec is designed for.
Most founders come to us with a concept, a few wireframe sketches, or a deck that describes what they want to build. That is enough to start. The Spec is a five-day engagement where we turn that into a precise, documented blueprint — every screen, every user action, every edge case — that you own and can take to any developer.
You do not need a spec to start. The Spec is the start.
The Spec ($5K, ~5 days): We produce the complete specification document for your product. You get a detailed blueprint of what to build, in what order, and why. You own it. You can take it anywhere — including to another developer if you choose.
Spec + Build ($10–15K, ~2–3 weeks): Everything in The Spec, plus we build it. Same fixed price, same ownership model. The spec is created first, you approve it, then we build exactly what was approved — nothing more, nothing less.
The reason we separate them: some founders need the spec to get investor sign-off before committing to the build. Some already have funding and want both in one engagement. Either is fine.
Fixed price means what it says. We agree the scope in writing before any work starts. That scope is the spec. If the spec changes — meaning you want to add features or change functionality after approval — we discuss it before building, not after. There are no surprise invoices.
If you change your mind after the spec is approved and before the build starts, we have a conversation about what that means for the timeline and price. We will always tell you the real number before we proceed.
What we will not do: bill you for scope creep on work we did not agree to do together. That is the agency model we left behind.
We are stack-agnostic on the specification side — the spec documents what the product does, not how it’s built, which means it is portable regardless of technology.
On the build side, we use modern web technologies and our own toolchain (spec2web) for web applications. We do not build native mobile apps (iOS/Android). If your product requires a mobile-first native experience, we will tell you that in the first discovery call and point you in the right direction.
No. The Maintain track exists specifically because most dev teams do disappear after the invoice.
If you want ongoing support after a build project, we offer product retainers starting at $595/month. These cover proactive monitoring, regular updates, and direct access — no ticket queue, no mystery about who is looking after your product.
You can also start on the Maintain track without a build project. If you have a live website that works but needs consistent attention, website retainers start at $600/year.
We plan for this. We do not take on more projects than we can service at the quality level we’ve committed to. That is one of the structural reasons we stayed at two people — not a cost decision, a quality decision.
If there is ever a situation where availability affects your project, we will tell you proactively, not reactively. We will not go dark. That is a promise we make to every client at onboarding.
The honest answer to “what if you get hit by a bus” is: we have processes, documentation, and codebase access that means your product does not depend on any single person’s presence. That is also what spec-first development enables — the spec is the insurance policy.
No — and we want to be precise about this.
The 120+ products were built under Beta Launch, the studio we ran for the nine years before specshop.dev. The founders of specshop.dev are the same people. The track record is real and verifiable. But we will not present Beta Launch clients as specshop.dev clients — that would be inaccurate.
What the Beta Launch history gives you: evidence that we can ship, that we understand complexity, that we work across industries and geographies, and that clients come back. The names (USAID, Takso, MetJip, HAL Capital) are the proof. You can ask us about any of them on a discovery call.
The short answer is in the post above.
The longer answer: the agency model was not breaking because of bad management or bad clients. It was breaking because the value proposition of headcount was eroding faster than we could see in the numbers. We had 40 people doing work that AI tooling now assists two people to do. The moment we understood that clearly, keeping the structure alive felt dishonest — to our clients, to our team, and to ourselves.
Shutting it down was the hardest decision we made. It was also the correct one. The alternative was growing something we knew was fragile, because the revenue was comfortable.
We are building specshop.dev to last. That required starting with a model we actually believed in.
A few quick filters:
You’re likely a good fit if: You’re building a web application with 2–3 core user workflows. You have a budget of $5–15K for the build and a real timeline driving it. You’ve been burned by a dev team before and want a different process. You have a live website or product that needs consistent care and no internal dev capacity.
You’re probably not a good fit (yet) if: You need a native mobile app as the primary product. You’re at idea stage with no budget clarity. You need enterprise procurement, legal review, and a 6-month sales cycle. You need someone available 24/7 across all time zones.
If you’re not sure, book the call anyway. We will tell you honestly if we’re the wrong fit — and if we are, we’ll try to point you somewhere better.
It’s 30 minutes. You talk first — we want to understand what you’re building, what’s driving your timeline, and whether you’ve worked with a dev team before.
Then we ask three questions: What does this need to do — what are the 2–3 things a user does in this product? What’s your timeline, and what’s driving it? Have you worked with a development team before? What happened?
Then we explain the specshop.dev process and tell you honestly which track fits your situation — and at what price.
If it’s a fit, we send a proposal within 24 hours. If it’s not, we tell you that on the call. No follow-up pressure. No hard sell.
Book a 30-minute call →