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 can wait for version two
- 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.
Advice before code
If existing tools can already test your hypothesis, that's the advice you get: cheaper for you, and a faster start on the question that matters.
Straightforward pricing
Cash pricing, quoted slice by slice before any work starts. For the right fit, we're open to a blended rate that includes a small equity component.
Not technical, and paying someone else to build it?
Then a second pair of eyes is cheap insurance before you approve the next invoice — it's how founders avoid 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. Take the findings anywhere you like, and if the work is good, we'll tell you so.
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
- Room to push back when a feature can wait for later
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.
Built to hand over
A conventional stack and conventional patterns, on public, well-known tools. Any competent developer can pick it up, which is the point. We run our own company on an operations app built and run in-house the same way.
An investor can read it
Clean commit history, a written architecture note, and every third-party library accounted for. Technical diligence goes faster when everything is already explained.
We stay reachable
After handover you can still call with a question. The five-minute kind is on us, and we'll still know the codebase when you call.
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, in fixed, time-boxed slices, so you always know the number. For the right fit we are open to a blended rate: mostly cash, with a small equity component alongside it.
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 hand off cleanly and stay a friendly reference for whoever comes next.
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 that would otherwise eat their weeks — 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 the final call stays with them.
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 a call would help, we book one. From the first reply on, you're talking to the people who'd do the work.