MVP development: every feature you cut before it's built is free.
An MVP isn't a cheap version of the real product — it's the smallest thing that answers the question you're actually betting on. Our first job is usually to argue your feature list down until it does that, and only that.
What a first version should include
One core workflow that works end to end, for real users, with real data. Everything else is a distraction until that one thing is being used.
- The single workflow your business model depends on, working properly
- Real accounts and permissions — not a demo login
- Payments if money is part of the hypothesis, skipped if it isn't
- Enough analytics to know whether anyone is actually using it
- Deployment that you can ship to without ceremony
- Tests around the paths that would embarrass you if they broke
And what it shouldn't
- An admin panel for a customer base you don't have yet
- Microservices, multi-region, and scale planning for imaginary traffic
- Native mobile apps when a responsive Web app tests the same idea
- Six roles and a permissions matrix before you have six users
- A design system for a product whose shape will change in a month
Four to eight weeks
Typical for a focused first version. The variable is almost never engineering speed — it's how fast the scope gets cut.
Handover-ready from day one
Conventional stack — TypeScript or Python on a SQL database — readable code, documented setup. Your first engineer inherits a codebase, not an archaeology project.
We'll tell you not to build it
If existing tools already test your hypothesis, that's the advice you get. Cheaper for you, and we'd rather be the honest referral.
No equity-only builds
We price in cash. We'll discuss a blended rate for the right fit, but we won't pretend a small shop can fund itself on upside.
Not technical, and paying someone else to build it?
Then you're being asked to approve work you can't evaluate — which is how founders end up with a demo that can't be extended. A few paid hours gets you a straight read on the code, the architecture, or the quote in front of you: what's solid, what's a real risk, and which questions to put to your developer next. No obligation to hire us for the fix, and we'll say so plainly if the work is good.
Scope down, build, hand over
-
1
Find the bet
What assumption is this version testing? Everything that doesn't serve it goes on a "later" list rather than into the build.
-
2
Fixed first slice
A quoted, time-boxed first version so you know the number and the date before you commit any money.
-
3
Weekly working demo
Something clickable every week. Direction changes are cheap while the thing is still small.
-
4
Ship & hand off
Live, documented, and transferable — to your engineer, another shop, or a retainer with us. Your call, not ours.
What we need from you
The builds that go badly almost never fail on engineering. They fail because the founder was too busy to answer, or because nobody could say what the thing was supposed to prove. Four weeks is fast only if the other side of the conversation moves at the same speed.
- One founder who can make a call without a committee
- The bet written down in a sentence — what has to be true for this to work
- Two or three real potential users we can put the thing in front of
- A reply inside a day when we're blocked on a decision
- Whatever accounts and API keys the product depends on, early
- Permission to tell you a feature isn't worth building
What you'll own at the end
Everything. The repository, the hosting accounts, the domain, the analytics property, the app-store listings if there are any — registered to your company from day one, not transferred later on good behavior. Founders who skip this step discover the problem at the worst possible moment, which is due diligence.
No lock-in by design
Conventional stack, conventional patterns, no in-house framework of ours. Any competent developer can pick it up, which is the point.
An investor can read it
Clean commit history, a written architecture note, and no undisclosed third-party code. Technical diligence goes faster when there's nothing to explain away.
We stay reachable
After handover you can still call with a question. We don't charge for the five-minute kind, and we won't pretend the codebase is a mystery to us.
Three honest outcomes, and what each one costs you next
An MVP is an experiment. Experiments are allowed to come back negative — that's the result you paid for, and it's the cheapest one on this list.
It works
Real users, real usage, and a reason to spend more. Now the questions change: what breaks at ten times the load, what has to be hardened before you take money seriously, and who you hire first. We'll hand it to your engineer, keep building on a retainer, or do both while they ramp — and we'll tell you when in-house is cheaper than us.
It doesn't
Nobody uses it, or they use it and don't pay. That's a real answer, and you got it for the price of one small build instead of a year. We'll write up what the data actually showed — which assumption failed, and whether anything in the codebase is worth keeping for the next idea. No upsell attached.
It half-works
The most common outcome by a wide margin. One part of the workflow gets used constantly and the rest is dead weight. The move is to cut hard toward the part that's alive rather than to add features around it — which is usually a smaller second build than founders expect, because you're deleting more than you're writing.
Straight answers
How fast can we get an MVP in front of users?
For a focused first version — one core workflow, real logins, real data — typically four to eight weeks. The variable is rarely engineering speed; it is how quickly the feature list can be cut down to what actually tests your assumption.
Will you take equity instead of cash?
We price in cash — we are a small shop and cannot bank on an exit. For the right fit we will talk about a blended rate with a small equity component, but we will not build for equity alone.
What happens when we hire our first engineer?
They inherit something readable: your repo, conventional tooling, tests around the important paths, and a written architecture walkthrough. We would rather hand off cleanly and stay a friendly reference than become a dependency you cannot remove.
Can you review a build somebody else is doing for us?
Yes — a short paid technical review of the code, the architecture, or the quote. Founders paying an offshore team without a technical person in the room ask for this a lot, and it is cheap insurance.
Do you help decide what to build, or just build it?
Both, and we will push back. Every feature you cut before it is built is free. Our job in the first week is usually to argue the scope down to the smallest thing that still answers your question.
Who owns the code, the accounts, and the domain?
You do, from day one rather than on handover. The repository, hosting, domain, analytics property, and any app-store listings are registered to your company and we work inside them. This matters more than founders expect: the first time most people discover their contractor owns the production account is during technical due diligence, which is the worst possible moment to find out.
What stack do you build an MVP in, and why does it matter?
Usually TypeScript or Python against a SQL database, deployed somewhere ordinary. It matters because your next engineer has to be hireable. A first version written in something fashionable narrows the pool of people who can maintain it and gives you nothing in return at MVP scale — you are not going to outgrow PostgreSQL while you are still proving anyone wants the product.
We already have a technical co-founder. Where do you fit?
Usually as extra hands on the parts they do not want to spend their weeks on — integrations, infrastructure, the admin side — so their time goes into the product itself. Some teams also use us for a second opinion on architecture before they commit to it. We work inside their repo and conventions, and we are comfortable being the ones who do not make the final call.
What if we run out of money halfway through?
Then you stop, and what has been paid for is finished and yours. We work in fixed, time-boxed slices specifically so there is a clean stopping point every few weeks rather than one big invoice at an unfinished end. We will also say plainly during scoping when the runway you have described does not cover the thing you are describing, because finding that out in week six helps nobody.
What are you actually testing?
Tell us the bet and we'll tell you the smallest thing that settles it — and what that costs.
Prefer to talk?
Call 832-598-8234 or email msco@stoneagesoftware.com. Houston, Texas — serving Houston, The Woodlands, Conroe, Sugar Land, Katy, Pearland, and the Greater Houston metro.
What happens next
We read your message, an engineer replies with questions or a straight answer, and if it's worth a call we book one. No drip campaign, no handoff to sales.