On this page · 11 sections
Summary. Three fixed dates now control how fast a first release can reach users, and none of them are negotiable by working harder. From 31 August 2026, new apps and updates on Google Play must target Android 16, API level 36. A Play developer account opened after 13 November 2023 cannot unlock production at all until 12 testers have been opted into a closed test for 14 continuous days. Apple has required builds made with Xcode 26 and the iOS 26 SDK since 28 April 2026. Add Play's 7-day production review and the store gate alone eats roughly 3 weeks of a 12-week plan. CB Insights, analysing 431 shut-down companies in March 2026, found 43% cited poor product-market fit and 70% ran out of capital, with a median of 22 months between the last raise and the shutdown. The scope question is not what to build. It is what to cut so the 9 weeks before the store gate buy real evidence.
An MVP engagement is bought for one reason: to convert an assumption into evidence before the money runs out. Everything below is organised around that, and around the dates a 2026 release actually has to hit.
The three gates a 2026 first release has to clear
Most MVP plans are drawn as a feature list against a calendar. That misses the part of the schedule nobody controls.
| Gate | Requirement | Effective date | Schedule cost |
|---|---|---|---|
| Google Play target API | New apps and updates must target Android 16 (API 36) | 31 August 2026 | Build-time only, if planned |
| Play closed testing | 12 testers opted in for 14 continuous days, personal accounts opened after 13 Nov 2023 | In force | 14 days minimum |
| Play production review | Application reviewed after the closed test | In force | "Seven days or less, but can occasionally take longer" |
| Apple SDK floor | Uploads built with Xcode 26 and the iOS 26 SDK | 28 April 2026 | Build-time only |
| India DPDP obligations | Notice, consent, safeguards, breach reporting, erasure | 13 March 2027 | Design-time, not launch-blocking |
Google's target API level policy states that existing apps must target Android 15 (API 35) or higher by 31 August 2026 or "they will stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app's target API level". A new app is held to the higher bar of API 36. Google will accept extension requests to 1 November 2026, but only through the Policy status page in Play Console and only for apps already flagged non-compliant. That is a remedy for an existing app, not a plan for a new one.
The closed-testing rule is the one that reliably surprises founders. Google's requirement is exact: developers with personal accounts created after 13 November 2023 "must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days". Continuity is enforced. Google states that testers "who opt in, test for fewer than 14 days, and then opt out do not count", and that a tester who opts out and back in must complete 14 consecutive days. Production and pre-registration stay disabled in Play Console until the requirement is met. If engagement is judged insufficient, you test again and reapply.
Note the qualifier: personal accounts. Google's published requirement does not impose the 12-tester closed test on organisation accounts. For a funded company this is the single cheapest schedule lever available, and it costs a company registration rather than engineering time.
Apple is currently the simpler side. Since 28 April 2026, uploads to App Store Connect must be built with Xcode 26 or later using the iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26 SDK. As of August 2026 Apple's upcoming requirements page lists no future-dated deadline at all. The Apple Developer Program costs $99 a year, the Enterprise Program $299, and TestFlight carries up to 10,000 external testers, so beta distribution is not the constraint on iOS. Play's $25 one-time registration fee is cheaper and the gate behind it is far more expensive.
What the failure data says to cut
CB Insights published "The top 9 reasons startups fail" on 5 March 2026, drawn from 431 venture-backed companies that shut down publicly since 2023, with reasons identifiable for 385 of them.
| Reason cited | Share of analysed companies |
|---|---|
| Ran out of capital | 70% |
| Poor product-market fit | 43% |
| Bad timing or macro conditions | 29% |
| Unsustainable unit economics | 19% |
Percentages exceed 100 because companies cited more than one cause. CB Insights is explicit that the headline number is a symptom: "'Ran out of capital' tops the list at 70%, but it's almost always the final cause of death, not the root problem." The companies in the sample raised $17.5bn between them, a median of $11m each, and died a median of 22 months after their last raise. Two-thirds of the product-market-fit failures were early-stage companies that never found a market at all.
Twenty-two months is the number that should set MVP scope. It is not a long runway, and a first release that consumes 6 months of it to answer a question a 12-week release could have answered has spent a quarter of the company's remaining life on engineering rather than evidence.
Marc Andreessen, co-founder of Netscape and general partner at Andreessen Horowitz, put the priority plainly in 2007, in a post he still credits to Andy Rachleff: "The only thing that matters is getting to product/market fit." His description of its absence is the more useful half: "The customers aren't quite getting value out of the product, word of mouth isn't spreading, usage isn't growing that fast, press reviews are kind of 'blah', the sales cycle takes too long, and lots of deals never close."
Steve Blank, the Stanford adjunct professor who originated Customer Development, is blunter about what an MVP is for. Writing in July 2013, he warned that "a minimum viable product (MVP) is not always a smaller/cheaper version of your final product", and described a team that "confused the goal of the MVP with the process of getting to the goal. They had the right goal but the wrong MVP to test it."
That distinction decides scope. A smaller version of the finished product is a demo. An MVP is an instrument built to return a specific reading.
What we build in a 12-week MVP
We scope every MVP against one written hypothesis and one metric that would falsify it. Anything that does not move that metric is documented and deferred, not argued about weekly.
A typical build contains:
- One primary user journey, complete and instrumented end to end, including the failure paths.
- Authentication, and only the account states the hypothesis needs. No organisation hierarchies, no role matrices, no invitation flows unless the hypothesis is about teams.
- Payments only when the hypothesis is about willingness to pay. When it is, the payment path ships first, not last.
- Analytics defined before the first screen is designed, with the falsifying metric named in the event schema.
- An admin surface for the operators, usually the fastest thing to under-build and the fastest to cause a support crisis.
- Store-ready builds on API 36 for Android and the iOS 26 SDK, produced in week 1 rather than week 11.
What we deliberately leave out of a first release: multi-tenant architecture, offline data synchronization, granular role-based access control, localisation beyond one language, and any integration that exists to satisfy a customer who has not yet been named. Each of those is real engineering that can be added later against a real requirement.
The five-step delivery process
We run MVP work in five stages against a 12-week calendar, with the store gate placed where it actually falls rather than at the end.
- Discovery, week 1. The hypothesis, the falsifying metric, the single journey, and the cut list. We write the cut list down and both sides sign it. This is a fixed-scope stage with a fixed fee, and it produces a document you own whether or not you continue.
- Architecture and instrumentation, weeks 2 to 3. Data model, event schema, environments, CI, and the store accounts. If the Play account is personal, we open the organisation account here, not in week 10. Target API 36 and the iOS 26 SDK are set in the first build.
- Build, weeks 4 to 8. Two-week increments, each ending in a build on a real device in the founder's hands. Application portfolio analysis and technical-debt quantification are explicitly out of scope at this stage; there is no portfolio yet.
- Closed test, weeks 9 to 10. The 12 testers are recruited in week 8 so the 14-day continuous clock starts on day one of week 9. Server-side logging and crash reporting are watched daily. This period is for stability, not features.
- Submission and launch, weeks 11 to 12. Production access application, Play review, App Store review, and the first cohort. Feature work stops. The buffer here exists because Google's own guidance says review is "seven days or less, but can occasionally take longer".
The honest version of this calendar is that weeks 9 to 12 are largely waiting, and the discipline is not adding features into the wait.
The stack
We choose the stack to protect the 12 weeks, not to be interesting.
| Layer | Default | When we change it |
|---|---|---|
| Mobile | React Native or Flutter, one codebase | Native when the hypothesis depends on a platform capability |
| Web | Server-side rendering on Next.js | A progressive web app when installability matters more than reach |
| API | Node.js or Python, one service | Never more than one service in an MVP |
| Data | Managed PostgreSQL | Managed document store when the schema is genuinely unknown |
| Infrastructure | One managed cloud, one region | Multi-region only when residency requires it |
One service, one database, one region. The cost of a distributed architecture in an MVP is paid immediately in debugging time and returned only if the product survives. Teams choosing between frameworks can compare our notes on React Native app development and Flutter app development; either is a defensible default, and the choice rarely decides the outcome.
India-specific considerations
India's Digital Personal Data Protection Rules were notified on 14 November 2025. The Press Information Bureau states that the rules "introduce an eighteen-month period for phased compliance", and the substantive obligations for a consumer product collecting personal data, notice, consent, security safeguards, breach notification, retention and erasure, and verifiable consent for children, take effect on 13 March 2027. Encryption, masking and tokenisation are named as minimum safeguards, breaches must be reported to the Data Protection Board with full detail within 72 hours, and logs must be retained for one year. Penalties reach ₹250 crore for a failure of security safeguards, ₹200 crore for failing to notify a breach or for children's-data violations, and ₹50 crore otherwise.
March 2027 does not block a launch in 2026. It does decide the data model, because consent state, retention windows and erasure are cheap to design in and expensive to retrofit across a live user base. We build first releases aligned with DPDP requirements from the schema up. Founders costing this work should read our analysis of DPDP compliance cost for Indian startups.
The funding climate sets the runway that the 22-month median implies. Inc42's H1 2026 report puts Indian startup funding at $5.2bn across 501 deals for January to June 2026, down 9% year on year in value while deal count rose 7%. Only 4 rounds exceeded $100m, against 11 mega-deals in H1 2025, and the median ticket held flat at $3m. AI was the exception, at $676m across 57 deals. Note that Entrackr reports a materially higher figure for the same period, so this is Inc42's count rather than a settled number.
Vikram Gupta, managing partner at IvyCap Ventures, reads it this way: "The decline in overall funding quantum in H1 2026 reflects a genuine macro-driven recalibration, a higher cost of capital globally, LP caution on emerging markets, and a natural correction after the exuberance of 2021-22. But beneath that, the rise in deal volume tells a different story: more companies are getting funded, at more rational valuations, with stronger fundamentals."
More deals at a flat $3m median is a market that funds evidence rather than ambition. That is an argument for the 12-week release, not against it.
How we engage
We run MVP work in two commercial stages rather than one large fixed bid. Discovery is a fixed-scope, fixed-fee week that ends with the hypothesis, the cut list, the architecture note and a costed build plan. You keep that document regardless of what happens next. The build then runs as a dedicated senior-led squad on a monthly basis, sized to the plan, with the scope controlled by the cut list rather than by change requests.
We do not quote a single figure for "an MVP" before discovery, because the honest range is wide enough to be useless as a number and the store gates, the compliance surface and the integration count move it more than the feature list does. For comparative context on the market, see our breakdown of app development cost in India.
Why eCorpIT
eCorp Information Technologies Private Limited has been building software from Gurugram since 2021. We are assessed at CMMI Level 5, MSME certified, and ISO 27001:2022 certified, and we work as AWS, Microsoft, Google and Shopify partners. Teams are senior-led and multi-disciplinary, which for a 12-week engagement matters more than headcount: there is no time for a first release to be a training exercise.
The work sits alongside our custom software development and software development in India practices, and first releases that grow into products move into software testing and maintenance rather than being rebuilt. For founders whose first release is a mobile app specifically, our guide to mobile app development for startups covers the same ground from the platform side.
FAQ
How eCorpIT can help
We scope and build first releases as fixed-scope discovery followed by a senior-led build squad, with the store gates and the DPDP data model planned into week 1 rather than discovered in week 10. If you have a hypothesis, a runway number and a date, we can tell you within a week whether 12 weeks is realistic and what has to come out of scope to make it so. Talk to us at /contact-us/ with the assumption you most need tested.
References
Last updated: 17 August 2026.
