Stock trading app development: what Jio's 1.39 crore tests

Stock trading app development gets tested on days like 21 October 2026, when Jio Platforms' IPO drew roughly 1.39 crore applications and was fully subscribed in about 95 to 100 minutes. By the end of this post you will know which systems sat on that critical path, why most of them are outside your app, and what that means for your build-or-white-label decision.

The short version: the order screen is the cheap part. The cost and the risk sit in the UPI mandate flow, the exchange bid book, the registrar's basis of allotment and the depository credit, all of which your app has to track, reconcile and explain to the user on a three-working-day clock. This is an engineering post for founders and CTOs, not investment advice, and it says nothing about whether any stock is worth buying.

Jio Platforms IPO step	Date (2026)	Source
Issue opens	Wed 21 October	Chittorgarh
Issue closes (T)	Fri 23 October	Chittorgarh
Basis of allotment	Mon 26 October	Chittorgarh
Refunds initiated and shares credited to demat	Tue 27 October	Chittorgarh
Listing on BSE and NSE	Wed 28 October	Chittorgarh; Upstox

One IPO drew more applications than 24 earlier IPOs combined

Chittorgarh's issue page records 1,38,65,863 total applications for the Jio Platforms IPO, a fresh issue of 27 crore shares in a price band of ₹1,065 to ₹1,119, with a lot of 12 shares. Upstox puts the figure the same way in words: applications "approached a world-beating 1.39 crore".

For scale, SEBI's July 2023 board memorandum on the T+3 timeline analysed 24 public issues that opened from September 2022. Across all 24, the total was 1,36,22,513 applications, and the largest single issue in that sample took 26,51,241. One IPO in October 2026 cleared the combined count of that whole sample, and took roughly five times the biggest issue in it.

The sources do not agree on the other headline numbers, and you should not pick one silently:

Figure	Chittorgarh	CNBC	Upstox
Time to full subscription	Not stated	Within 95 minutes, per MD Akash Ambani	Within 100 minutes
Overall subscription	21.36x (Day 3, 7:28 PM)	More than 22x, per BSE data	22.19x
Retail / QIB	2.76x / 67.15x	2.72x / 70.55x	Not stated
Issue size	Up to ₹30,188 Cr	₹302 billion ($3.2 billion)	₹30,213 crore

The CNBC report calls it the country's largest-ever IPO. For product planning, notice which number matters. The subscription multiple measures money against shares on offer, and retail was under 3x on both sources that report it. The application count measures how many mandates, bids, allotment decisions and notifications the system had to process. That is the load your app inherits.

How IPO allotment works in India on the T+3 timeline

IPO allotment in India now runs on a three-working-day clock from issue close to listing. SEBI's circular SEBI/HO/CFD/TPD1/CIR/P/2023/140 of 9 August 2023 is titled "Reduction of timeline for listing of shares in Public Issue from existing T+6 days to T+3 days", with T being the issue closing date. Jio's dates fit it exactly: close on Friday, allotment Monday, demat credit Tuesday, listing Wednesday, with the weekend not counted.

The day-by-day timetable below is the one SEBI's July 2023 board memorandum put forward after consultation. We read the memorandum, not the final circular's annexure, so treat the clock times as the proposed schedule and check the current master circular before you hard-code any of them.

Day	What happens (per SEBI's T+3 memorandum)	Who runs it
T, 5 PM	UPI mandate acceptance closes; retail bidding closes (QIB and NII close at 4 PM)	Investor's UPI app, NPCI, sponsor bank, exchanges
T, 9:30 PM	Sponsor bank submits the final certificate for UPI applications	Sponsor bank
T+1, 9:30 AM	Third-party check on UPI applications	Registrar, through sponsor bank APIs
T+1, 6 PM / 9 PM	Rejections and basis of allotment finalised; exchange approves the basis	Registrar, stock exchange
T+2, from 9:30 AM	Fund transfer and unblock instructions; debits by 2 PM, unblocking by 4 PM	Registrar, sponsor bank, banks
T+2, by 6 PM	Corporate action credits shares to demat accounts	Registrar, depositories (NSDL, CDSL)
T+3	Trading starts	NSE, BSE

For Jio, the registrar running the middle of that table was KFin Technologies. None of these steps belong to the app the investor applied through.

Where stock trading app development actually spends its budget

The budget in stock trading app development goes to the states between "bid placed" and "shares in demat", not to the bid form. The money side runs on ASBA, where funds are blocked in the investor's bank account rather than paid up front. SEBI's investor portal describes the UPI version: the exchange shares the bid and the investor's UPI ID with the issuer's sponsor bank, which "will request the investor to authorize blocking of funds"; funds are blocked once the investor validates, and debited only after allotment.

Two rules from SEBI's memorandum shape your state machine directly. First, the exchange bid book includes only UPI applications with the amount successfully blocked in full, so "bid submitted" in your app is not the same as "bid in the book". Second, the mandate window closes at 5 PM on T day, so an unapproved mandate at that moment is a lapsed application your user will want an explanation for. The same SEBI investor page puts the UPI limit for IPO applications at ₹5 lakh per transaction.

Map that to what your app has to model per application: bid created, mandate requested, mandate approved or declined, mandate lapsed, bid confirmed in the book, allotted or not allotted, funds debited or unblocked, shares credited, listed. Each transition is reported by a different party, through your broker or exchange connection, often hours apart. SEBI itself requires a daily three-way reconciliation between the stock exchanges, sponsor banks, NPCI and the UPI apps on its network (PSPs and TPAPs); your backend needs its own version of that, because your support queue will be built from the mismatches.

This is why we treat the integration layer as the main line item when we scope these builds, and why the price ranges you see online usually miss it. We covered that gap in API integration cost and what the price ranges leave out.

How do trading apps handle IPO traffic?

Trading apps handle IPO traffic by keeping the user-facing path short and pushing everything slow into queues. What follows is general engineering practice, not a description of any broker's system:

1. Accept fast, process asynchronously. Write the bid to a durable queue and acknowledge it; forward to the exchange or broker API from workers you can scale and rate-limit.
2. Make every submission idempotent. A user on a slow network will tap twice. An idempotency key per application stops the second tap from becoming a second bid that you then have to unwind.
3. Model status as a state machine fed by both webhooks and polling. Callbacks get missed on heavy days; a reconciliation job that polls the source of truth closes the gap.
4. Budget for notification fan-out. Every state change above is a push notification candidate, and allotment arrives for everyone at once. Batch and throttle sends through a service like Firebase FCM.
5. Cache what is read-heavy. Subscription figures and issue details are read far more than they change; serve them from Redis rather than your primary PostgreSQL database.
6. Load-test the opening window, not the average. Jio's book filled in 95 to 100 minutes on the sources' own accounts, so the first hours of day one are the test case.

The market infrastructure did this work before T+3 went live. SEBI's memorandum lists API-based processing, more web and database servers, load distribution and slicing of files among the enhancements, followed by back-testing and simulations by exchanges, sponsor banks, NPCI and registrars. Your app sits in front of all of that, and the weakest link the user sees is yours. Automated load and regression testing of these flows is part of our QA and automation work.

Build vs white-label a trading app: the honest case for each

The strongest case for white-labelling is that the integration chain above already exists in a broker's stack and has already been through IPO days. You inherit tested connections to the exchanges, the UPI mandate flow and depository credit, and your team ships a branded front end instead of a reconciliation engine. If your goal is to add IPO applications as one feature inside a wealth or banking app, that is a reasonable trade.

The case for building is control over the parts users judge you on: the status timeline, the explanations when a mandate lapses, the notification timing, and the data you keep about your own customers. A white-label front end shows what the partner's APIs expose, and on a heavy day you wait on their queue.

Question	White-label a broker's stack	Build your own app on a broker or exchange connection
Time to first IPO	Shorter; integrations already exist	Longer; you build and test the state machine
Status and notification UX	Limited to what the partner exposes	Yours to design and reconcile
Load on an IPO day	Partner's capacity, shared with their other clients	Your capacity, plus your upstream connection
Customer data and cross-sell	Depends on the contract	Held in your own systems
Ongoing engineering cost	Licence or revenue share	A team that owns the integrations

Building is the wrong choice if trading is a side feature, if you do not plan to staff the integration layer after launch, or if your compliance position for handling bids is not settled. Which registrations you hold, or rely on through a partner, decides what your app is allowed to do itself; that is a question for your compliance counsel before it is an engineering one. We looked at how SEBI's rules shape this kind of product in custom investment software development under SEBI's 2026 draft.

Trading app development cost in India: what moves the number

Trading app development cost in India is set less by screen count than by four things: how many upstream parties you integrate with, how many application states you show the user, how much load you test for, and how much compliance review each release needs. We won't quote a range here, because a figure without those four answers is a guess. As a reference point from our own delivery, a focused MVP typically takes 6-10 weeks, and larger enterprise platforms 3-6 months depending on complexity, integrations and scope.

The client framework matters less than people expect for this kind of app. Both React Native and Flutter handle the front end well; the harder part is the backend in Node.js, PostgreSQL and Redis, plus WebSockets if you show live subscription figures. If you are choosing a framework anyway, our React Native vs Flutter verdict covers when we pick each. We have not built a broking or IPO platform, and we would scope one as a new domain, not a repeat project.

What to settle before you scope the build

Before any estimate, write down three things: who holds the exchange connection and the regulatory registrations, which of the states from issue open to listing your app will show, and what your app does at 5 PM on T day when a user's mandate is still pending. Those answers decide whether you are building a front end on a partner's stack or an integration platform of your own, and they move the cost more than any screen.

If you are weighing whether to build that IPO and trading flow yourself or white-label it, our mobile app development team will map the integration chain against your partner's APIs and tell you which parts are worth owning before you commit to either path.