How long does a web app, an MVP or a full product take?
Small features 1–2 weeks, an MVP 4–8, a full production app 8–16. Where those ranges come from, how each is delivered, and what makes one of them slip.
Small features 1–2 weeks, an MVP 4–8 weeks, a full production app 8–16 weeks. Those are ranges I have hit on work of that shape before. Something I have genuinely not built before gets a range and a spike, not a confident date.
That is the whole answer. A spike is a short piece of work with one output: a better estimate. It is agreed as a milestone like any other.
My name is Ahsan Mahmood and I work alone: one person, one React and TypeScript codebase, web and Android out of the same repository.
Why does every timeline answer sound like a dodge or a lie?
Because two of the common answers are unusable. One is a refusal to give a number at all. The other is a confident date for work nobody has done before, which holds right up until the first thing nobody accounted for.
Both cost you the same thing. You cannot plan a launch, a hire or a marketing date around either of them, so you end up guessing on top of somebody else's guess.
A fixed number attached to an unscoped brief is a number one of us is going to be unhappy about.
How do you know how long a web app or an MVP will take?
From work of the same shape. Small features 1–2 weeks, an MVP 4–8 weeks and a full production app 8–16 weeks are bands I have hit before on projects that looked like this one. That is a different claim from a promise about yours.
The unit is a shipped thing rather than a sprint count. Started is not shipped. A range I have hit on work of that shape before is the strongest thing I am willing to say before a scoping call, and it is still a range rather than a date.
You can open the products. FilesHub, LifeWell and ZTools each have a page on this site with the live URL that resolves it. Those pages prove the things shipped. They do not carry how long each one took, so the spans below are my own account of that.
LifeWell took me about eight months. Not eight months of a scoped engagement: a v1 that worked, then a full redevelopment of the UI, the UX and the backend flows.
The redevelopment is the part worth understanding. A v1 that works is not the same artefact as a product whose interface, flow and backend hold together. It cost months no estimate of the v1 could have contained, because the thing being estimated did not exist yet.
ZTools ran longer. It started as a web app with 20 tools and became a redesigned product with 550+, with an Android app, a browser extension and a docs site behind it. That took me about two years. FilesHub, at the other end, took me about five months to a fully working, integrated utility.
Those spans are the reason the three bands are quoted the way they are. They are product lifetimes: my own products, carried through a v1 and a rebuild while other products were being built beside them. A band describes something much narrower — a scoped client engagement worked to one milestone plan, with a demo every week.
That difference is also why a range is quoted only after scope, and never before it.
Something I have not built before does not get a date. It gets a range and a spike, and what comes back from the spike is a narrower range plus whatever it found on the way.
That is not a hedge. An estimate with evidence behind it gets narrower as the work goes on. One without evidence does not.
What counts as a small feature, an MVP, or a full production app?
What already exists, mostly. A small feature is one feature, integration or fix on a codebase that already exists, with thirty days of bug fixes after delivery. That is the only one of the three I can define on a page rather than on a call.
The other two are scope questions wearing time labels. The services page carries the same three ranges beside the work they apply to, and where the line falls between an MVP and a full production app gets settled on the scoping call, in writing, before anything is quoted.
What moves that line is scope. How much of the product has to survive real users, real data and a store reviewer.
What adds time to a Play Store submission?
Four things people forget: the merged manifest audit, the Data Safety form, the ten App-content declarations and a listing written to pass review rather than to sell. The surprise is rarely the build, because Google Play listings are packaged with Capacitor from the same web codebase rather than rewritten. Those four add more than most plans allow for.
Not one of those is optional.
I start with the merged manifest. The permission list a reviewer reads is the merged one rather than the one you wrote. The Android build behind this site carries 26 permissions in its merged manifest, and 21 of them were injected by a single plugin.
Finding that at submission is expensive. The queue itself is not mine: a submission waits on a reviewer I do not employ, and no amount of planning on my side moves that.
What do you get to see each week?
A working demo against the milestone every week. Most projects start within 48 hours of acceptance, and after that the demo replaces the status update. If something slipped, you hear it that week, while there is still time to change what we do about it.
You watch the thing run.
That start is the easiest date in this post to keep, because starting is the part that only needs me. The rest needs both of us.
A milestone you can watch run is also a date that has already been tested, and estimating the next one from a demo beats estimating it from a brief.
What makes a software timeline slip?
Three things. Only one of them is mine: work nobody has done before, which is what the spike exists to shrink. A decision on your side that a milestone cannot start without. And a queue at a store or a third party that neither of us owns.
My own estimate is the one I can act on, and the spike is how I act on it. The other two are yours and the world's, and pretending otherwise is how a plan quietly becomes a story about who is to blame for a week nobody named at the time.
The demo is where all three become visible, and where a slipped week is traced to one of them.
A slipped week is said in the week it slips.
That is not a comfortable discipline. A demo showing less than last week's plan is a worse meeting than a status email, and it is the only version of the meeting that leaves you time to decide something.
What ends an engagement is a scope agreed at the start, and my own products never had one. Trizlink took about two years to finish every flow. ClearHire took about ten months. HabitForge is seven-plus months in and still going.
All three are live. None of them was a scoped engagement, and none is what the three bands describe.
Two limits belong here. The first: I do not quote a date from a brief alone, so the range you get before a call is the published one and nothing narrower. The second is money. $800 is the floor for a small, well-defined feature rather than an estimate of yours; the rest of the ladder sits on pricing.
Tell me through the contact form what you are building and roughly when you need it. The first call is thirty minutes and costs nothing, and it is the call where I say whether I am the right person for the work. If the Android half is what your calendar turns on, what Capacitor actually costs is the next thing to read.
Every range on this page was hit on work I had already done. Yours gets one after the call.
Can you add one feature to an app someone else built?
Yes. One feature, integration or fix on a codebase that already exists, with thirty days of bug fixes after delivery. That is the shape the 1–2-week band describes, and it is the only one of the three sizes I can define without a call. What decides where it lands inside the band is how much of the existing codebase the change has to touch, and how much of it I have to understand before touching anything.
How long does Google Play review add to a launch?
I do not publish a number for it, because the review queue is the store's and not mine. What I can size is the work in front of it: the merged manifest audit, the Data Safety form, the ten App-content declarations and a listing written to pass review rather than to sell. Those sit inside the estimate. The queue does not.
Can you commit to a fixed launch date?
No. What replaces it is a range, a milestone plan and a working demo every week, so a date gets corrected by something you watched rather than by an email in month two. If a date is genuinely immovable, the scoping call is where we work out what fits inside it, and it is also where I say whether I am the right person for the work.
What is a spike, and when would you use one?
A spike is a short piece of work whose only output is a better estimate. It is for the part of a project nobody involved has built before, where a range is the honest answer and a date is not. It is agreed as a milestone like any other, and what comes back is a narrower range plus whatever it found on the way.
Why are your own products measured in months when the bands are measured in weeks?
Because my own products are lifetimes rather than scoped engagements: a v1, then a redevelopment, built while other products were being built beside them. LifeWell took me about eight months that way and ZTools about two years, from 20 tools to 550+ across web, Android and a browser extension. The bands describe a scoped client engagement worked to one milestone plan with a demo every week, which is the only shape I will attach a number to before the work starts.
https://aoneahsan.com/blog/how-long-a-web-app-mvp-or-full-product-takes