MVP development
We help you decide what to cut, agree a fixed written plan with milestones, price and dates, and send you a build to try every week until real people are using it.
Zoftaa is a small MVP development company in Lahore, Pakistan. We build first versions of apps and web products for founders in the US, the UK, Europe, the Gulf and Pakistan. A first version here means the smallest product that shows you, through real users, whether the idea works.
Working software that people can install or open. Usually one or more of these:
Every MVP we build also gets crash reporting, plus analytics on the one action that proves the idea, so the first weeks of real use give you numbers to decide with.
These examples show the shape of the work. They are not past projects:
A good MVP does one job for one kind of user, well enough that they come back. On the scope call we work backwards from that job and question everything else. These are the cuts we look at first:
Some things look cuttable and aren't, because the stores check them (rules checked 1 November 2026):
Scoping ends with two short lists, what is in version one and what is not, and both go into the plan.
New ideas come up once people use the builds. We write each one down, and you decide, with the effect on price and dates in front of you, whether it goes into this version or the next.
Put the stores into the schedule from week 1, because some of the waiting is set by Apple and Google. The published rules (checked 1 November 2026):
| Step | What the store says | What it means for your plan |
|---|---|---|
| Google Play, new personal account | Personal accounts created after 13 November 2023 must run a closed test with at least 12 testers "opted in continuously for at least 14 days", then apply for production. That review "usually takes seven days or less" (Play Console Help). | 14 days of testing plus up to 7 days of review is about 3 weeks from the first closed test to a public listing, so the closed test starts while the build is still going. |
| Google Play, organisation account | "To create a developer account for an organization, you must provide a D-U-N-S number" (Play Console Help). | Request the D-U-N-S number in week 1. |
| Apple TestFlight | Up to 10,000 external testers, but only once your first build is "approved by App Review for TestFlight" (TestFlight). | Leave time for one review before the first invites. |
| Apple App Store | "typically reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours" (App Review). | Usually quick, but each rejection costs a fix and another review, so we check the guidelines before submitting. |
The closed test is also your first real feedback. We set up Firebase Analytics before it starts, so you can see whether testers reach the core action and come back the next day.
A web MVP has no store review. It runs on a preview link during the build and moves to your domain at release.
An AI feature brings its own risks: answers in the wrong shape, costs that grow with every user, and providers that retire models. In the AI apps we've shipped, these rules held up:
For a chatbot that answers from your own documents, see our AI chatbot development work.
Everything, and most of it is in your name from day one:
Because it all sits in your accounts and uses common tools, another team can pick the product up later without starting again.
These are the ranges we plan around. They are estimates, and your written plan gives your real dates.
| What you are building | Typical build time |
|---|---|
| A clickable prototype to test with users before any code | 1 to 2 weeks |
| A web MVP with one core flow, sign-in and an admin panel | 4 to 8 weeks |
| A Flutter app for Android and iOS with a backend and an admin panel | 6 to 10 weeks |
| The same app with an AI feature at its core, subscriptions or a second type of user | 8 to 12 weeks |
| Store release for a new personal Google Play account | About 3 weeks (14 days of closed testing, then up to 7 days of review), mostly overlapped with the end of the build |
What moves a project within those ranges, or past them:
Pakistan Standard Time is UTC+5 all year, with no daylight saving since 2009 (Wikipedia, checked 1 November 2026), so the gap only changes when your own clocks do. Our hours are Monday to Friday, 10am to 7pm PKT:
| Where you are | Our hours in your time | Overlap with your 9am to 5pm |
|---|---|---|
| London, winter (GMT) | 5am to 2pm | 5 hours |
| London, summer (BST) | 6am to 3pm | 6 hours |
| Berlin or Paris, winter (CET) | 6am to 3pm | 6 hours |
| Berlin or Paris, summer (CEST) | 7am to 4pm | 7 hours |
| Dubai (UTC+4) | 9am to 6pm | Your whole day |
| Riyadh (UTC+3) | 8am to 5pm | Your whole day |
| New York, winter (EST) | Midnight to 9am | None |
| New York, summer (EDT) | 1am to 10am | 1 hour |
For US clients we also take calls from 6pm to 10pm PKT, Monday to Friday. In New York that's 8am to 12pm in winter (EST) and 9am to 1pm in summer (EDT).
With the Gulf we share the whole day. With the UK and Europe there is a shared morning and early afternoon, which is when the weekly call happens. With the US, live calls and urgent replies happen in your morning, through that 6pm to 10pm PKT window. Notes you leave later in your day are waiting for us when we start. If you need live calls outside that window, say so on the scope call and we'll tell you whether the hours work.
Email, WhatsApp and the contact form all reach the engineers who write the code, and we usually reply within one business day.
Usually 4 to 8 weeks of building for a web MVP and 6 to 12 weeks for a Flutter app. A new personal Google Play account adds about 3 weeks of store time, most of it overlapped with the build. The written plan gives your dates before any code is written.
We don't publish prices. You get a fixed price in the written plan, before any code, with exactly what it covers. The same things that move the timeline move the price.
An app, if users will open it on their phones several times a week or it needs the camera, location or notifications. The web, if they use it at a desk or rarely, or you mainly want to see whether anyone signs up. More on our mobile app development page.
Yes. Send the code or a link before the scope call. Sometimes building on it is quicker; sometimes sign-in, data and the store release are easier to do properly from scratch. The plan says which, and why.
Yes, in your name or your company's from the start, so your app is never stuck in someone else's account.
You have the code, accounts, keys and documentation. If you want us to keep building, a monthly product retainer keeps the same engineers on it. If you'd rather hire your own team, the handover documents are written for them.
We have no public case studies yet. On the scope call you talk to the engineers who would write your code, and the first weekly builds show you how we work early in the project. To start, send us a few lines about your idea.
Costs and hiring1 November 2026
Fixed price vs time and materials, for founders hiring an app or MVP team: who carries which risk, why an idea-stage estimate can be 4x out, and a sample change request.
Contact
Tell us about the problem in a few lines. An engineer will reply, usually within one business day.