Where MVP Timelines Stretch

Settle One Thing Before You Ask About Weeks

Anyone commissioning an MVP wants the timeline first. Send the same feature list to five builders, though, and five different durations come back. Feature count is not what sets the schedule. An MVP is a tool for testing one belief, not a shrunken copy of the finished product, and the distance between “enough to find out whether anyone will pay” and “a first release we would be comfortable putting our name on” is measured in months of work.

Settle this instead: what is this version supposed to tell you. Name the thing you want to learn and a builder can argue the scope down, because for that question these four screens are enough. Leave it open and the feature list keeps growing. The schedule follows the list.

Decide What Version One Leaves Out

Go back through the list and a surprising amount of it can wait. The admin panel is the standard example. Early on, orders and applications can land in a spreadsheet and get handled by a person. Email sign-in alone will do; three social providers can come later. Extra languages, automated notifications, automated payouts, all of it runs on human hands until the volume makes that painful.

Cutting features is not the same as building something sloppy. If the screens and flows a user touches are rough, the test tells you nothing. What gets trimmed is operational convenience and just-in-case work. Anything a person can do by hand stays manual, and the time that buys goes into the surface users actually meet.

Once Work Starts, Reply Speed Sets the Schedule

Schedules slip on decisions more than on code. Three days waiting on a design sign-off, four more waiting for final copy, and a week is gone. The builder cannot start the next screen without an answer, and every idle day is billed as part of the build.

Fix a review rhythm, name one decision maker, and most of that disappears. Same day each week, look at what was built, decide in the room. Feedback stops piling up. With three people signing off, reconciling notes that pull in different directions becomes its own workstream. At this stage a fast decision is worth more to the calendar than a perfect one.

Store Review and Payment Contracts Run on Someone Else’s Calendar

Sometimes the build is finished and the product still cannot open. An app has to clear store review, and a rejection means fixing it and rejoining the queue. Taking money means a payment provider’s onboarding, its compliance check, and business documents to match. Count those weeks as part of the development window and the launch date you announce comes out wrong.

None of those clocks speed up because your developer asks nicely.

Which is why they get started in week one, alongside the screen work: the provider application, the store accounts, the paperwork. Third-party integrations belong in the same batch. If you know which services you want wired in, name them while the quote is being written. A service with thin documentation or an approval process of its own is a schedule risk before a line of code exists.

If the Launch Date Is Already Fixed

If the date is set, lead with the date. It is also fine if the thing you want to learn is not yet one clean sentence. Weple’s MVP work starts by agreeing on what this version has to prove, then fixes the timeline and builds the scope to fit inside it. Bring a feature list and we go through it picking out what version one can live without. Our rates and what they cover sit on the pricing page, and the first schedule we draw puts the store and payment queues on the calendar next to the build.