Here’s what actually happened, what makes it credible rather than hype, and why the “closed AI has a permanent moat” argument just got harder to make with a straight face.

What Moonshot AI Actually Shipped

Kimi K3 is Moonshot AI’s new flagship model — 2.8 trillion parameters, built as a Mixture-of-Experts (MoE) system. The key detail that makes that number less intimidating than it sounds: only 16 of its 896 “experts” activate for any given token. That architecture is what lets a model with genuinely massive parameter count keep real inference cost far below what a dense model of the same size would demand.

Moonshot is calling it the first “open 3T-class” model, edging past DeepSeek’s 1.6T V4 Pro for that particular title. Alongside the scale, K3 ships with a 1-million-token context window, native vision support, and a new attention mechanism — Kimi Delta Attention (KDA) — that the team reports delivers up to roughly 6x faster decoding at long context lengths. Most models slow down noticeably as context grows; KDA is specifically engineered to fight that.

The headline result: on Arena’s Frontend Code leaderboard — where real developers vote on blind, head-to-head matchups between model outputs — K3 landed at #1. That’s a 17-place jump over its own predecessor, Kimi K2.6, and it placed ahead of Anthropic’s Claude Fable 5 in that specific comparison.

The Part That Makes This Credible, Not Hype

Here’s the detail that separates this from the usual “new model claims to beat everything” launch post: Moonshot’s own materials openly admit that K3 trails both Claude Fable 5 and GPT-5.6 Sol on general intelligence benchmarks.

It is not, by Moonshot’s own account, the smartest model available. What it won was one specific, real-world-relevant contest — front-end code that actual developers preferred, in blind evaluation. That’s a narrower claim than “best AI model,” and a far more believable one.

The moat closed AI labs have isn’t “we’re smarter.” It’s “we’re smarter at everything, all the time.” Kimi K3 just showed that gap can close fast, on the tasks people actually care about.

Framed that way, this isn’t really a “China beats America” story, even though that’s the framing a lot of coverage has reached for. It’s a more precise and more interesting one: an open model caught up on a specific task that matters commercially, while still openly trailing on general capability. That’s exactly the kind of gap that tends to narrow over successive model generations rather than widen — which is the actual reason this is worth paying attention to.

What Makes K3 Technically Different

Two things are doing the real work under the hood, beyond the raw parameter count:

• Kimi Delta Attention (KDA). A hybrid linear attention mechanism built specifically to keep long-context performance from degrading. At a 1-million-token context window, this matters a lot in practice — it’s the difference between a model that’s usable on a large real codebase and one that’s only fast on toy examples.
• Sparse Mixture-of-Experts routing. Activating only 16 of 896 experts per token is what makes a 2.8T-parameter model economically viable to serve at all. This is the same broad architectural family used by other recent frontier models, but Moonshot has pushed the expert count and routing design further than most public releases.

Pricing

K3 is priced at roughly $0.30 per million tokens for cache-hit input, up to $3 per million tokens for cache-miss input, and $15 per million tokens for output. That’s meaningfully cheaper than most closed frontier models — not free, but a real and relevant gap for any team weighing cost against capability.

How to Actually Use It

• Via API. Model ID kimi-k3, available through Moonshot’s own platform in an OpenAI-compatible API format — low-friction to try if your stack already calls GPT-style endpoints.
• Via the Kimi app. Available directly through kimi.com for casual, non-developer use.
• Self-hosting. Not yet available. Full open weights were promised by July 27, 2026; until that lands, access is limited to the hosted API.
• Practical recommendation from early adopters. Several development teams evaluating K3 are treating it as a candidate default-plus-fallback model rather than a wholesale production swap — trialling it against real diffs, tests, and builds before committing meaningful traffic to it.

One more data point worth including for balance: Moonshot briefly paused new K3 subscriptions on July 20, citing GPU capacity limits after unexpectedly high demand. That’s a good signal of genuine interest in the model, and also a fair signal that the infrastructure behind it is still catching up to that demand.

Why This Matters If You’re Building With AI

The practical takeaway isn’t “switch to Kimi K3 today.” It’s a reminder about how quickly the gap between the best closed model and the best available open model can move.

If a product or engineering team has built deeply around a single closed AI provider — hard-coded prompts, tooling, and pricing assumptions with no realistic path to switching — moments like this are a useful prompt to check that exit plan. Not because you should necessarily switch, but because the assumption that closed frontier models will always be meaningfully ahead is getting harder to take for granted with every generation.

Frequently Asked Questions

What is Kimi K3?
Kimi K3 is Moonshot AI’s flagship large language model, released July 16, 2026. It’s a 2.8-trillion-parameter Mixture-of-Experts model, activating 16 of 896 experts per token, with a 1-million-token context window and native vision support.

Is Kimi K3 open-source?
It’s marketed as open-weight, but as of its launch, full model weights had not yet been released. Moonshot AI promised the weight release by July 27, 2026. Until then, access is limited to the hosted API and Kimi’s own apps.

How does Kimi K3 compare to Claude Fable 5 and GPT-5.6 Sol?
Moonshot’s own published materials acknowledge K3 trails both Claude Fable 5 and GPT-5.6 Sol on general intelligence benchmarks. However, K3 ranked #1 on Arena’s crowd-judged Frontend Code leaderboard, ahead of Claude Fable 5 in that specific blind-comparison coding test.

How much does Kimi K3 cost to use?
Roughly $0.30 per million tokens for cache-hit input, up to $3 per million tokens for cache-miss input, and $15 per million tokens for output — notably cheaper than most closed frontier AI models.

How can developers try Kimi K3 right now?
Through Moonshot’s API using the model ID kimi-k3, which follows an OpenAI-compatible format, or through the Kimi consumer app at kimi.com. Self-hosting will only become possible once the open weights are released.

Share

The post A Free, Open AI Model Just Beat the Closed Frontier at Its Own Game appeared first on Blog.

That’s not a concept video. It shipped. At the World Artificial Intelligence Conference (WAIC) in Shanghai in mid-July 2026, Chinese telecom giant ZTE unveiled the NaviX Ultra under its Nubia brand — a smartphone it calls the world’s first agentic AI phone. Days later, Apple finally received approval to bring its own AI assistant to mainland China. Two very different bets on the same question just landed in the same market, in the same week.

What “Agentic” Actually Means Here

The word “AI phone” has been used loosely for years — usually meaning a phone with a chatbot app, a photo-editing feature, or a smarter voice assistant bolted onto an otherwise ordinary interface. Agentic is a specific, narrower claim: the AI doesn’t just respond to you, it acts on your behalf across multiple apps and steps, without you supervising each one.

The NaviX Ultra makes that claim literally. According to reporting from Bloomberg and device previews, the phone has no traditional home screen or app grid in the conventional sense. Instead, a dedicated orange side button (or a voice command) summons ByteDance’s AI assistant Doubao directly. From there, Doubao is designed to map a request — “plan me a weekend trip” or “edit this photo and send it to my group chat” — into a sequence of actions and carry them out across apps itself, rather than making you open each app individually.

Demoed capabilities reportedly included real-time photo editing, generating maps, and building full travel itineraries, all triggered from a single request to the assistant.

The Players Racing for the Same Idea

ZTE isn’t alone, and the pattern across all three shows this is a genuine industry bet, not one company’s marketing stunt.

• ZTE / Nubia — NaviX Ultra. Priced from roughly 3,499 yuan (about $516) and built around ByteDance’s Doubao. An earlier, more limited device from the same partnership, the Nubia M153, reportedly sold out an initial batch of 30,000 units on launch day, with resale prices doubling on secondary markets — a real, if small, signal that consumer appetite exists.
• StepFun. Showed a device running its own proprietary operating system with a built-in agent called Amoo, rather than licensing an assistant from a bigger partner.
• Honor. Spun off from Huawei, reportedly preparing AI-agent-focused devices built on models co-developed with Alibaba, expected later in 2026.

Three different companies, three different AI partners (ByteDance, an in-house model, and Alibaba), all converging on the same structural idea: put one agent at the center of the phone instead of an app grid.

Why This Is Happening in China Specifically

This isn’t a coincidence of timing. Global smartphone upgrade cycles have slowed considerably — most new phones look and feel like the ones they replace, which makes it harder to justify a purchase. Chinese manufacturers, several of them state-linked, are betting that a genuinely different interaction model — not just faster hardware — is what makes a new phone feel worth buying again.

China’s AI ecosystem also happens to be unusually well positioned to try this first. ByteDance, Alibaba, and Baidu each have consumer-facing AI assistants with hundreds of millions of existing users, giving hardware makers an assistant with real conversational maturity to build a phone around, rather than starting from scratch.

Apple’s Very Different Answer, Landing the Same Week

The timing makes an interesting contrast. On July 15, 2026, China’s Cyberspace Administration formally approved Apple Intelligence for the mainland market — ending a roughly 22-month wait since Apple first announced the feature in 2024. Apple was the only foreign brand included in that approval batch, alongside domestic names including Huawei, Xiaomi, Samsung, OPPO, vivo, and Nubia itself.

The detail that matters most: the AI actually running Apple Intelligence in China isn’t Apple’s own model. Regulatory and data rules required a domestic partner, so Apple is using Alibaba’s Qwen model to power core generative features — text summarization, email drafting, document editing, and image generation — with Baidu also confirmed to be involved in some capacity. Both companies’ spokespeople have confirmed the arrangement; as of this approval, Apple itself hadn’t issued detailed public comment on the setup.

Structurally, this is a different bet than the ZTE approach. Apple Intelligence lives alongside the existing iOS app grid and interface — enhancing it, not replacing it. Samsung’s Galaxy AI takes a similarly additive approach globally. The Chinese agentic-first phones are proposing something more radical: remove the grid entirely and make the agent the interface.

The Part the Demos Don’t Show You

It’s worth being honest about what’s still unproven here. Nubia’s executives demoed the NaviX Ultra’s capabilities on stage but reportedly didn’t disclose chipset details, RAM, on-device model size, or how much of Doubao’s processing happens locally versus in the cloud — details that matter enormously for real-world speed, privacy, and reliability.

There’s also a track record worth remembering. Agent-first phone concepts have surfaced in Western markets before with confident demos that struggled once they had to interact with real third-party services — booking systems, payment flows, and apps that weren’t designed to be operated by another piece of software. A stage demo executing a pre-planned scenario is a meaningfully different test than a live agent handling an unpredictable request against a banking app or an airline’s booking flow. Whether Doubao holds up under that kind of real-world variability is the actual question, and it hasn’t been publicly answered yet.

Instead of juggling multiple apps, these phones are betting that AI can handle the juggling for you. Whether that holds up outside a product demo is the real test.

What This Signals for Software and Product Teams

Regardless of how the NaviX Ultra specifically performs, the direction here is worth watching closely if you build software:

• App design may need an “agent mode.” If phones increasingly let an AI operate apps on a user’s behalf, apps that are hard for an AI agent to navigate reliably could become a real competitive disadvantage, the same way non-mobile-friendly websites became one after smartphones took over.
• Voice and API-first interfaces are gaining ground. An interface built primarily for a human finger tapping a touchscreen isn’t automatically usable by an AI agent acting programmatically. Products with clean APIs and predictable, well-structured flows are naturally easier for an agent to operate correctly.
• Multiple simultaneous bets are healthy at this stage. Apple’s additive approach and ZTE’s agent-first approach are both reasonable responses to genuine uncertainty about what users actually want. It’s far too early to declare a winner.

Where This Leaves Things

What happened in Shanghai this month isn’t proof that the app grid is dead. It’s proof that a serious, well-resourced part of the industry is willing to bet real hardware, real launches, and real money that it might be, while Apple is running the more cautious experiment of layering AI on top of what already works.

Both bets are being tested in the same market, in the same year, which makes 2026 a genuinely useful natural experiment in how people actually want to interact with their phones — not just how a product team assumes they will.

Frequently Asked Questions

What is an agentic AI smartphone?
A phone built around an AI assistant that can carry out multi-step tasks across different apps on a user’s behalf — understanding a request and executing a sequence of actions — rather than simply adding AI-powered features to a conventional app-based interface.

What is the ZTE NaviX Ultra?
A smartphone launched by ZTE under its Nubia brand at the World Artificial Intelligence Conference in Shanghai in July 2026, marketed as the world’s first agentic AI smartphone. It centers on ByteDance’s Doubao AI assistant, activated via a dedicated side button or voice command, and starts at roughly 3,499 yuan (about $516).

Which companies are building agentic AI phones in China?
ZTE (Nubia brand, with ByteDance’s Doubao), StepFun (its own OS with an assistant called Amoo), and Honor (reportedly preparing AI-focused devices with Alibaba, expected later in 2026).

Is Apple Intelligence now available in China?
China’s Cyberspace Administration approved Apple Intelligence for the mainland market on July 15, 2026, ending roughly a 22-month wait. The China version uses Alibaba’s Qwen AI model for core generative features, with Baidu also confirmed to be involved, rather than Apple’s own AI model.

How is Apple’s approach different from ZTE’s agentic phones?
Apple Intelligence adds AI features on top of iOS’s existing app-grid interface. ZTE’s NaviX Ultra removes the traditional home screen and app grid, making a single AI agent the primary way of interacting with the phone.

Share

The post China Just Showed Off Phones With No App Grid — Just One AI Agent Running Everything appeared first on Blog.

The reason usually isn’t incompetence. It’s ownership. Engineering optimises for shipping features and keeping things up. Finance sees a single monthly invoice with no visibility into what drives it. In between, nobody is specifically accountable for the number going up.

The good news is that most cloud waste comes from a small, predictable set of causes. This article walks through the six most common ones we see, what each typically costs, and roughly what fixing it is worth. It’s written for founders and CTOs — you shouldn’t need to be a DevOps engineer to follow it.

One caveat before we start: every percentage below is a typical range, not a guarantee. Real savings depend entirely on your architecture and workload. Treat these as places to look, not promises.

1. Servers Running at 12% CPU

This is the single most common source of waste, and it has an entirely human explanation.

Early in a project, someone has to pick an instance size. There’s no production traffic data yet, the cost of being under-provisioned (an outage) feels far worse than the cost of being over-provisioned (a slightly bigger bill), so they round up “to be safe.” That’s a reasonable decision at the time.

The problem is that nobody ever revisits it. Two years later, that instance is still running, still oversized, and still billing every hour.

How to check

In CloudWatch, look at average CPU utilisation across 30 days for your EC2 instances and RDS databases. Sustained utilisation below 20% is a strong signal you’re paying for roughly four times the machine you need. AWS Compute Optimizer will also generate right-sizing recommendations automatically, and it’s free.

A word of caution: CPU isn’t the whole picture. Some workloads are memory-bound or I/O-bound and will show low CPU while genuinely needing the instance. Check memory and network metrics before downsizing anything, and change one instance at a time.

Typical saving: 30–50% of EC2 spend.

2. Paying On-Demand Prices for Predictable Workloads

On-demand pricing exists so you can spin up capacity instantly without commitment. You pay a premium for that flexibility, and for genuinely unpredictable workloads, it’s worth it.

But your production database isn’t unpredictable. Neither is your main application server. These run continuously, every hour of every day, and they will still be running next year. Paying a flexibility premium for something completely predictable is pure waste.

AWS offers two main alternatives for committed usage:

• Savings Plans — you commit to a consistent dollar amount of compute usage per hour for one or three years, in exchange for significantly lower rates. Compute Savings Plans are the flexible option, applying across instance families, regions, and even Fargate and Lambda.
• Reserved Instances — a more specific commitment tied to instance attributes, still widely used for RDS and other services.

AWS advertises discounts of up to roughly 72% for the deepest three-year, all-upfront commitments. Most companies won’t hit that ceiling, but even a one-year, no-upfront Compute Savings Plan typically delivers meaningful double-digit savings with very little downside.

There’s also Spot Instances — spare AWS capacity at discounts that can reach around 90%, with the catch that AWS can reclaim the capacity with two minutes’ notice. Never use Spot for your primary database. It’s excellent for batch processing, CI/CD runners, data pipelines, and any fault-tolerant workload that can be interrupted and resumed.

Typical saving: 20–40% of compute spend.

3. Development Environments Running All Night

Your team works something like 45 to 50 hours a week. Your development and staging environments bill for all 168.

That means for roughly 70% of every week, you’re paying full price for environments with nobody logged into them. Unlike production, these environments have no uptime requirement whatsoever. If staging is down at 3am on a Sunday, nothing happens.

How to fix it

A scheduler that stops non-production instances outside working hours is genuinely a one-afternoon piece of work. AWS Instance Scheduler is a supported solution for this, but a simple Lambda function on an EventBridge schedule works just as well — stop instances at 8pm, start them at 8am, skip weekends.

The main objection is usually “but what if someone needs it at night?” In practice, giving the team a self-service way to start an environment on demand solves this completely, and the exceptions are rare enough that the savings hold.

Typical saving: 65–70% of non-production spend.

4. Storage for Servers That No Longer Exist

This is the most frustrating category, because you get absolutely nothing in return for the money.

When you terminate an EC2 instance, its attached EBS volume doesn’t always go with it — depending on how it was configured, the volume can survive, unattached to anything, billing every month indefinitely. The same happens with:

• Orphaned EBS snapshots. Teams take snapshots before risky changes and never clean them up. Years of them accumulate.
• Unattached Elastic IPs. AWS charges for Elastic IP addresses that aren’t associated with a running instance.
• Idle load balancers. A load balancer left behind after a service was decommissioned bills an hourly rate for doing nothing.
• Empty or unused NAT Gateways. These carry an hourly charge regardless of whether traffic flows through them.

None of this is serving a user. None of it is supporting a workload. It’s abandoned infrastructure that nobody remembered to delete.

AWS Trusted Advisor flags several of these categories directly. A quarterly cleanup review is usually enough to keep it under control. For most mid-sized companies this recovers a few hundred dollars a month; for larger or older accounts, it can be dramatically more.

Typical saving: highly variable, but always pure profit — nothing is lost by removing it.

5. Data Transfer Costs You Can’t See

This is the sneakiest category on the list, because the charges don’t appear next to the resources causing them.

Two things dominate here:

NAT Gateway processing charges

NAT Gateways charge both an hourly rate and a per-gigabyte data processing fee for everything passing through them. If your services in private subnets are pulling large amounts of data from the internet — container images on every deployment, package downloads, external API calls — that processing fee accumulates quietly.

The common fix is VPC Endpoints. Traffic to services like S3 and DynamoDB can route through an endpoint instead of the NAT Gateway, avoiding the processing charge entirely for that traffic.

Cross-availability-zone traffic

AWS charges for data moving between availability zones inside the same region — in both directions. This is the one that catches teams out.

If you’ve split a chatty set of microservices across multiple AZs for resilience, every internal call between them may now be a billable cross-AZ transfer. You did the architecturally responsible thing and got a surprise line item for it.

The answer isn’t to abandon multi-AZ redundancy — that’s there for good reason. It’s to be deliberate about which services genuinely need to talk across zones, and to keep high-volume chatty communication zone-local where availability requirements allow.

Typical impact: often 5–15% of the total bill, and almost always underestimated.

6. Logs and Backups You Will Never Read

By default, CloudWatch log groups retain data indefinitely. Not for 30 days, not for a year — forever, unless someone explicitly sets a retention policy.

That means many companies are paying premium storage rates to keep application logs from years ago that no human will ever open. The same applies to S3 buckets without lifecycle rules, where data that’s been untouched for years still sits in the most expensive storage class.

The two fixes

• Set CloudWatch retention policies. Decide how long logs are actually useful — 30, 60, or 90 days for most application logs — and configure it. Anything you need for compliance can be exported to cheaper storage first.
• Use S3 lifecycle policies and storage classes. S3 offers a range of tiers, from Standard down to Glacier Deep Archive, at dramatically different price points. S3 Intelligent-Tiering will move objects between access tiers automatically based on usage, which is a reasonable default when access patterns are unpredictable.

Both are configured once and keep saving money indefinitely, with no ongoing effort.

Typical saving: modest as a percentage, but permanent and effortless.

Where to Actually Start

If you do nothing else, do this: open AWS Cost Explorer, group your spend by service, and look at your top three lines.

Cloud bills follow a Pareto pattern almost universally. A small number of services account for the overwhelming majority of the cost. Optimising a service that represents 2% of your bill is a poor use of engineering time, no matter how inefficient it is. Start where the money actually is.

Three practices matter more than any individual optimisation:

• Tag everything. Without resource tags for environment, team, and project, you can’t attribute cost to anything. Cost allocation tags turn an opaque invoice into an actionable breakdown.
• Set budget alerts. AWS Budgets can notify you when spend crosses a threshold or is forecast to. Finding out about a cost spike on the 3rd rather than the 30th is the difference between a small problem and a large one.
• Give the bill an owner. Not a committee — a named person who reviews it monthly and is expected to explain changes. This single organisational change tends to outperform any technical fix.

Cloud spend isn’t a technical problem. It’s an ownership problem.

A Note on Over-Optimising

It’s worth saying the obvious counterpoint: cost optimisation has diminishing returns, and engineering time isn’t free.

If your monthly AWS bill is $800, spending three engineer-weeks to save 20% is a bad trade. If it’s $80,000, the same effort is obviously worth it. And some spending that looks wasteful is actually buying you something real — multi-AZ redundancy costs more and is usually correct; over-provisioned capacity ahead of a known traffic event is prudent, not careless.

The goal isn’t the lowest possible bill. It’s a bill where every line item is a decision someone made on purpose.

How We Approach This at Onclick Innovations

We build and maintain cloud infrastructure for clients across fintech, healthcare, e-commerce and SaaS, and cost efficiency is something we treat as an architectural concern from the start rather than a cleanup exercise later. Right-sizing, environment scheduling, storage lifecycle rules and sensible tagging are far cheaper to build in at the beginning than to retrofit onto a system that’s already running in production.

Frequently Asked Questions

How much are most companies overspending on AWS?
Industry analyses of cloud spending consistently estimate that roughly 30% of cloud spend is wasted across the market. The figure for any individual company varies widely depending on architecture, workload predictability, and whether anyone actively reviews the bill.

What’s the fastest way to reduce an AWS bill?
Usually two things: right-sizing over-provisioned instances, and scheduling non-production environments to shut down outside working hours. Both are relatively quick to implement and carry low risk compared to architectural changes.

What’s the difference between Savings Plans and Reserved Instances?
Savings Plans commit you to a consistent hourly dollar amount of compute usage and apply flexibly across instance families, regions, and services including Fargate and Lambda. Reserved Instances are tied more specifically to instance attributes. Savings Plans are generally the more flexible option for EC2 compute; Reserved Instances remain common for services like RDS.

Are Spot Instances safe to use?
For the right workloads, yes. AWS can reclaim Spot capacity with two minutes’ notice, so they should never run your primary database or anything that can’t tolerate interruption. They’re well suited to batch jobs, CI/CD runners, data processing, and other fault-tolerant workloads.

Why is AWS data transfer so expensive?
Data transfer charges come from several sources, most commonly NAT Gateway per-gigabyte processing fees and cross-availability-zone traffic within a region. They’re easy to miss because the charges don’t appear alongside the resources generating them. VPC Endpoints and keeping high-volume internal traffic zone-local are the usual mitigations.

What tools does AWS provide for cost management?
Cost Explorer for analysing spend, AWS Budgets for alerts and forecasting, Compute Optimizer for right-sizing recommendations, and Trusted Advisor for flagging idle and unused resources. All are available within the AWS console.

Share

The post 6 Things Silently Inflating Your AWS Bill — And What Each One Is Actually Worth appeared first on Blog.

In 2026, JioHotstar reported a peak of roughly 72.5 million concurrent viewers during the ICC Men’s T20 World Cup final — a figure Reliance cited as a global record for a single live stream. To put that in perspective, the Super Bowl, the biggest live event in American media, peaks at somewhere around 10 to 12 million concurrent streams. JioHotstar routinely handles six to seven times that number, on a network where the same match is being watched on a 5G phone in Mumbai and a patchy 2G connection in rural Bihar at the same time.

How does a single platform pull this off without the whole thing collapsing? The answer is a genuinely fascinating piece of engineering. Here’s a breakdown of what actually makes it work.

First, A Note on the Numbers

Cricket streaming numbers in India get thrown around loosely, so it’s worth being precise. There are two very different metrics that often get confused:

• Concurrent viewers — how many people are watching at the exact same moment. This is the hard engineering number. JioHotstar’s verified peak here is around 72.5 million.
• Cumulative reach — how many unique people watched at any point across a match or a tournament. This is where you see figures in the hundreds of millions or billions (IPL 2025 reportedly drew over a billion viewers across TV and digital combined).

Both are real, but they measure completely different things. The concurrency number is the one that keeps engineers awake at night, because that’s the load the system has to survive in a single instant. Everything below is about how that instant is handled.

The Core Problem: Cricket Traffic Isn’t Smooth, It’s Explosive

Most streaming platforms deal with fairly predictable demand. People start a Netflix show whenever they feel like it, spread across the evening. Cricket does the opposite.

Hotstar’s own engineers have described traffic that can spike 20x within ten minutes of a match starting. Worse, the spikes happen mid-match too. When a star batter walks out to the crease, or a wicket falls in a tense final over, millions of people who stepped away suddenly rush back at once. Tens of millions of users can join within a single over.

This creates a specific, brutal engineering challenge called the thundering herd: a huge number of clients all requesting the same thing at the same instant, potentially overwhelming any server that isn’t ready for them. The entire architecture is designed around surviving these sudden surges, not just handling a high steady load.

Building Block 1: Adaptive Bitrate Streaming

The single most important idea in mass live streaming is that not everyone gets the same video. Through a technique called adaptive bitrate (ABR) streaming, the platform encodes every live stream into multiple quality versions simultaneously — 4K, 1080p, 720p, 480p, 360p, and stripped-down low-bandwidth versions for 2G connections.

The app on your phone constantly measures your available bandwidth and picks the right version, switching seamlessly if your connection changes — without ever interrupting playback. A viewer on stadium Wi-Fi might get 360p while a viewer on home fibre gets 4K, both watching the same match from the same infrastructure, just receiving different renditions.

This isn’t a nice-to-have. In a country with wildly varying network quality, ABR is the core mechanism that lets one platform serve everyone at once instead of buffering for half of them.

Building Block 2: A Multi-CDN Strategy

Here’s a physics problem: delivering video to 70 million people simultaneously from a central set of servers is simply impossible. The bandwidth doesn’t exist. The solution is the Content Delivery Network (CDN) — a globally distributed network of edge servers that cache content close to viewers.

JioHotstar doesn’t rely on just one. It runs a multi-CDN strategy, distributing traffic across several providers (Akamai has long been a core partner, alongside others) and using an in-house load optimizer that dynamically routes each viewer through the least-congested CDN in real time, based on live measurements of latency and packet loss. If one provider starts struggling, traffic shifts to another automatically.

The result of all this caching is dramatic: during live cricket, over 90% of content requests are served from CDN cache rather than origin servers. That single fact is the biggest scaling lever in the whole system. At a 90% cache hit rate, the origin infrastructure only has to handle roughly a tenth of the apparent load — still enormous, but survivable.

Cache hit rate is the primary scaling lever. At 90%, the platform serves ten times the load its origin servers actually see.

Building Block 3: The Custom Autoscaler

Behind the video, hundreds of microservices handle everything else: login, subscriptions, live scores, chat, reactions, recommendations, payments. These run on a massive Amazon EKS (Elastic Kubernetes Service) cluster — at peak, the setup has been described as running on the order of 16 TB of RAM, 8,000 CPU cores, and 32 Gbps of peak data transfer.

The clever part is how it scales. Standard Kubernetes autoscaling reacts to CPU and memory usage — but by the time CPU climbs, the surge has already arrived and viewers are already buffering. A newly provisioned server can take around 90 seconds to become healthy and start serving traffic, and in cricket, 90 seconds is two overs and several million viewers too late.

So JioHotstar’s engineers built a custom autoscaler that reacts to concurrency directly — the actual number of active streams — rather than to lagging server metrics. It can spin up new capacity within about 30 seconds of detecting a rising trend, giving it a crucial 60-to-90-second head start over standard tooling.

Building Block 4: Prewarming and Predicting the Surge

Even a fast autoscaler is reactive. The most sophisticated part of the strategy is being proactive. Rather than waiting for load to arrive, the team prewarms infrastructure ahead of big matches — provisioning servers and load balancers in advance, based on estimated peak concurrency drawn from years of historical match data.

Cricket is unusually predictable in this respect. Engineers know an India-Pakistan game will draw a bigger crowd than a mid-table league fixture, and they know viewership climbs toward the final overs. That historical pattern lets them pre-position capacity for the wave before it hits, treating reactive autoscaling as a backup rather than the front line.

The Clever Optimizations Most People Never Notice

Beyond the big architectural pieces, some of the most interesting work is in the small optimizations that shave load off the system:

• Separating cacheable from non-cacheable data. Not every request is equal. A live scorecard or match summary doesn’t change every second, so it can be cached and reused. Engineers separated these cacheable APIs onto a dedicated path with lighter security checks and faster routing, dramatically increasing how many users each server could handle.
• Slowing down refresh rates that don’t matter. Features like “watch more” suggestions or certain stats overlays don’t need real-time updates. By slightly reducing how often they refresh, the platform cut total network traffic without any viewer noticing a difference.
• Accepting a small, deliberate delay. JioHotstar streams run roughly 30 to 40 seconds behind the live TV broadcast. This isn’t a flaw — it’s a deliberate trade-off. That buffer is exactly what gives the system room to handle adaptive bitrate switching and absorb network hiccups without the stream stalling.
• Feature flags for safe rollouts. New features (interactive overlays, new quality options) are rolled out to a small percentage of viewers first. If something breaks under real load, it can be switched off instantly for everyone without touching the core stream.

The Jio Advantage Nobody Else Has

There’s one structural advantage worth calling out. Because JioHotstar sits inside Reliance, it has a relationship with Jio’s telecom network and its 450-million-plus subscribers that no independent streaming platform can replicate.

That telecom data can inform where CDN edge nodes are placed — pre-positioning capacity in regions where network data shows dense cricket viewership before a match even begins. Controlling both the last-mile network and the streaming platform is a genuine edge in a market this large and this network-diverse.

Why This Matters Beyond Cricket

It’s tempting to file this under “interesting cricket trivia,” but the engineering lessons are universal. The Netflix livestream of the Jake Paul vs. Mike Tyson fight in late 2024 buffered and stuttered for many viewers — a reminder that even one of the most sophisticated streaming companies in the world can struggle with live sport when it hasn’t been engineered specifically for these explosive, unpredictable spikes.

The principles JioHotstar relies on — cache aggressively and treat cache misses as the exception, scale on the metric that actually predicts load, prepare for the surge before it arrives, and make deliberate trade-offs like accepting a few seconds of latency for stability — apply to any system that has to survive sudden, massive concurrency. That includes ticketing platforms during a sale, payment systems on a festival day, and any product that goes from quiet to viral in minutes.

At Onclick Innovations, this is exactly the class of problem we love: architecting systems that stay fast and reliable not on an average day, but on the single worst-case moment when everyone shows up at once. The best infrastructure isn’t the kind that handles a steady load. It’s the kind you never notice, precisely because it was built for the spike.

Frequently Asked Questions

How many people watch JioHotstar at the same time during big matches?
JioHotstar reported a peak of roughly 72.5 million concurrent viewers during the ICC Men’s T20 World Cup final in 2026, cited by Reliance as a global record for a single live stream. Cumulative reach across a full match or tournament runs far higher, into the hundreds of millions, but that counts unique viewers over time rather than at a single moment.

What cloud infrastructure does JioHotstar use?
The platform runs primarily on Amazon Web Services, using Amazon EKS (managed Kubernetes) to orchestrate its microservices, alongside a multi-CDN delivery strategy with partners such as Akamai. It uses a mix of on-demand and spot instances to manage cost at scale.

Why doesn’t JioHotstar buffer during peak cricket traffic?
A combination of adaptive bitrate streaming (serving different quality levels to different viewers), aggressive CDN caching that handles over 90% of requests, a custom autoscaler that reacts to concurrency in about 30 seconds, and prewarming infrastructure ahead of matches based on historical data.

Why is the JioHotstar stream a bit behind the TV broadcast?
The stream runs roughly 30 to 40 seconds behind live TV. This is a deliberate engineering trade-off — the delay creates a buffer that allows adaptive bitrate switching and absorbs network fluctuations, keeping the stream stable for tens of millions of viewers at once.

What is the thundering herd problem in live streaming?
It’s when a very large number of viewers request the same content at the same instant — for example, millions rushing back to the stream when a wicket falls — potentially overwhelming servers. Streaming platforms design specifically around absorbing these sudden surges rather than just handling steady high load.

Sources: figures and technical details in this article are drawn from Reliance’s public statements, Business Standard, published Hotstar/JioHotstar engineering talks and case studies, and industry technical analyses (2019–2026). Some detailed architecture specifics reported by third parties are described by those sources as informed inference rather than officially confirmed by JioHotstar.

Share

The post How JioHotstar Streams Cricket to 70+ Million People at Once Without Buffering appeared first on Blog.

No major rewrite has replaced it. No well-funded startup has dethroned it. Every serious alternative that’s launched since — and there have been several — has ended up either wrapping Git, integrating with Git, or quietly fading out. In an industry that reinvents itself every eighteen months, that kind of staying power is worth asking about.

Built Out of Frustration, Not Ambition

Git wasn’t built as a product. It was built because the Linux kernel team lost access to the proprietary tool (BitKeeper) they’d been using, and Torvalds needed a replacement fast — one that could handle a codebase with thousands of contributors and no central authority forcing everyone to work the same way.

That constraint shaped everything about how Git works. It had to be distributed, because Linux kernel development has never had one central server everyone depends on. It had to be fast, because kernel commits happen constantly. And it had to trust developers to work independently and merge later, rather than requiring permission before every change.

Those weren’t marketing decisions. They were survival decisions for one specific, enormous open-source project. It just turned out that nearly every software team on Earth had the same underlying problem.

What Actually Makes Git Different

Version control existed before Git. CVS, Subversion, and Perforce were all in wide use in 2005. What set Git apart wasn’t that it tracked changes — it was how it tracked them.

• Fully distributed. Every developer’s local copy is a complete repository with full history, not a thin client talking to a central server. You can commit, branch, and view history with zero network connection.
• Cheap, fast branching. Creating a branch in older systems could be a slow, heavyweight operation. In Git, it’s close to instant, which is what made feature branches, pull requests, and modern code review workflows practical in the first place.
• Content-addressed storage. Git identifies every piece of data by a hash of its content, not by filename or location. That’s the underlying reason Git is so good at detecting duplicate content, verifying integrity, and handling merges intelligently.
• No single point of failure. Because every clone is a full repository, losing the server doesn’t mean losing the project. Any developer’s machine can restore the whole history.

None of these ideas were entirely new in computer science. What Git did was combine them into a tool fast and reliable enough that teams stopped thinking about version control as a constraint and started treating it as infrastructure they didn’t need to worry about.

GitHub Didn’t Make Git Popular — It Made Git Social

It’s a common mix-up: many developers who started their careers after 2010 assume Git and GitHub are basically the same thing. They’re not. Git is the version control system running on your machine. GitHub, launched in 2008, is a hosting platform built on top of it.

What GitHub actually did was take Git’s distributed model and add a social and collaborative layer on top: pull requests, code review threads, issues, forks you could contribute back from, and eventually a de facto resume for developers. GitLab and Bitbucket followed with their own takes on the same idea.

That combination — Git’s technical model plus a platform for open collaboration — is arguably what pushed Git from “the tool Linux uses” to the default choice for nearly every kind of software project, open source or private.

Every Attempt to Replace It Has Failed — Or Just Joined It

Git has had real competition. Mercurial launched the same year as Git and, for a while, was considered by many to have a friendlier command-line interface. Some large companies, including Facebook for a period, invested heavily in alternatives or in heavily customized Git internals (Facebook eventually built Sapling, and Google has long used a modified, monorepo-focused workflow).

None of these efforts displaced Git at the industry level. The pattern that keeps repeating is telling: companies that need something different from stock Git tend to build tooling on top of Git rather than replace it outright. The underlying object model and distributed design have proven durable even when the workflow layered on top changes completely.

The Learning Curve Nobody Talks Their Way Out Of

Ask almost any developer, junior or senior, and you’ll hear some version of the same story: Git was confusing at first. Commands like rebase, cherry-pick, and reflog are genuinely hard to reason about the first time you encounter them, and a botched merge can still produce a moment of real panic.

That difficulty is part of why Git has stayed relevant rather than a reason it should have been replaced. The complexity isn’t accidental — it’s the visible surface of a genuinely powerful underlying model. Once a developer understands what a commit, a branch, and a merge actually represent internally, the commands stop feeling arbitrary and start feeling like direct, honest access to the data. Tools that hide that complexity behind friendlier interfaces tend to work fine until something goes wrong, at which point understanding the Git model underneath becomes the only way out.

Why Git Survived the AI Coding Wave

2026 has brought a wave of AI coding assistants, autonomous coding agents, and AI-native development workflows. It would have been reasonable to expect version control itself to get reinvented along with everything else.

Instead, AI coding tools have overwhelmingly built on top of Git rather than around it. AI agents commit through Git. Code review tools built for AI-generated pull requests still rely on Git’s diff and merge model. Even tools designed to let AI agents work autonomously across a codebase use Git branches and commits as the underlying record of what changed and why.

That’s not a coincidence. Git’s content-addressed, immutable history is exactly the kind of structure that makes it possible to track, audit, and roll back AI-generated changes with confidence — something that matters more, not less, as more code gets written by autonomous agents rather than humans typing directly.

What 21 Years of Git Says About Good Infrastructure

Git’s longevity says something bigger about how durable technical decisions actually work. It wasn’t designed to be a product, to be easy to learn, or to win a popularity contest. It was designed to solve one hard, specific problem correctly, at scale, under real constraints.

Software teams evaluating new tools and frameworks in 2026 are often chasing the newest option. Git is a reminder that the tools with the longest lifespans are usually the ones built to solve a real structural problem well, not the ones built to be trendy. Frameworks come and go. The version control layer underneath them has stayed remarkably stable for over two decades.

At Onclick Innovations, every project we build — regardless of the framework, language, or client industry — runs on Git. It’s one of the few pieces of the stack we never have to debate.

Frequently Asked Questions

How old is Git in 2026?
Git was created by Linus Torvalds in April 2005, making it 21 years old in 2026.

Why was Git created?
Git was built because the Linux kernel development team lost access to the proprietary version control tool they had been using and needed a fast, distributed replacement capable of handling a massive, decentralized open-source project.

Is Git the same thing as GitHub?
No. Git is the version control system itself, run locally on a developer’s machine. GitHub is a hosting platform, launched in 2008, built on top of Git that adds collaboration features like pull requests and issue tracking. GitLab and Bitbucket are similar hosting platforms.

Has anything replaced Git?
No mainstream alternative has replaced Git at an industry level. Some large companies have built customized tooling on top of Git’s core model for specific needs, but Git itself remains the dominant underlying version control system.

Why does Git still matter in the age of AI coding tools?
AI coding assistants and autonomous coding agents in 2026 are built on top of Git rather than replacing it, because Git’s immutable, content-addressed history makes it possible to track, audit, and roll back AI-generated code changes reliably.

Share

The post Git Just Turned 21 — Here’s Why Every Developer Still Can’t Escape It appeared first on Blog.

ByteDance’s Doubao, Alibaba’s Qwen, and Tencent’s Yuanbao all currently let users build a custom AI persona — give it a name, shape its personality, and let it remember previous conversations. That feature is being switched off across all three platforms on the same day.

For anyone building AI products — not just in China, but anywhere — this is worth understanding closely. It is the clearest signal yet that “AI designed to feel human” is becoming its own regulated category, with real compliance costs attached.

What’s Actually Shutting Down

The feature in question is often called an AI companion or AI persona: a chatbot that isn’t just answering questions, but is designed to be talked to like a relationship. Users name it, describe its personality, and the AI carries memory of past conversations to make interactions feel continuous and personal.

Doubao, Qwen, and Yuanbao each built consumer-facing versions of this. It’s been a major driver of daily engagement for all three apps.

Starting July 15, that capability disappears. The rollout isn’t identical across platforms:

• Doubao users get a read-only export window through October 15, 2026, to save their chat history before it’s permanently removed.
• Qwen users have no announced export window. Alibaba has not published a data retention plan for existing companion conversations.
• Tencent’s Yuanbao is affected the same way, though Tencent has said less publicly about transition details.

For a feature used daily by a large share of each platform’s user base, this is a significant product change to make on a single fixed date.

The Law Behind the Shutdown

The trigger is a regulation from China’s Cyberspace Administration: the Interim Measures for the Administration of AI Anthropomorphic Interaction Services. It was issued in April 2026 and takes effect July 15.

Stripped of the legal language, the measure regulates any AI system designed to be human-like enough that users form real emotional attachments to it. That is a meaningfully different target than most AI regulation so far, which has focused on accuracy, bias, or data privacy. This law is about emotional design itself.

The requirements include:

• Anti-addiction mechanisms. Products must include break reminders and usage safeguards, similar to rules already applied to gaming apps in China.
• Protection for minors. AI companions cannot be positioned or designed to replace real relationships for users under 18.
• A ban on training on private conversations. Companies can no longer use users’ personal chat data, including companion conversations, to train models without explicit separate consent.
• Limits on manipulative design. Patterns that are built to increase emotional dependence — artificial urgency, guilt-based re-engagement prompts, and similar dark patterns — are restricted.

According to reporting from Bloomberg and TechTimes in early July 2026, both ByteDance and Alibaba concluded that patching their existing companion systems to meet these requirements in time wasn’t feasible. Rebuilding from the ground up, on a compliant architecture, was judged the faster path — even though it means switching the current feature off entirely first.

The Detail Most Coverage Is Missing

Most headlines have framed this as China “banning AI companions.” That framing misses the more interesting part.

China isn’t banning AI companionship as a category. It’s licensing it — setting a compliance bar high enough that only well-resourced companies can clear it. ByteDance is already reportedly redirecting users toward a separate, standalone companion app (reported under the name Maoxiang) built specifically to meet the new requirements from the ground up.

That distinction matters for market structure. Building anti-addiction systems, minor-protection logic, consent-based training pipelines, and manipulative-design audits is expensive engineering and legal work. ByteDance and Alibaba can absorb that cost and treat it as a rebuild. Smaller AI companion startups operating in China generally cannot.

The practical effect, according to analysis from FourWeekMBA, is consolidation. A law framed around user protection is also, functionally, a barrier to entry that favors the largest platforms in the market.

This Isn’t Happening in Isolation

China’s measure is the broadest version of a trend that’s already underway elsewhere.

In the United States, California’s SB 243 — effective January 1, 2026 — regulates companion AI chatbots specifically where minors are involved. Washington State’s HB 2225, effective January 1, 2027, goes further by banning manipulative engagement tactics designed to create emotional dependence, regardless of the user’s age.

China’s rule is broader than either of these because it applies to all users, not only minors. But the direction across all three jurisdictions is consistent: regulators are starting to treat emotionally engaging AI as a distinct governance category, separate from general AI safety or data privacy rules.

Regulators worldwide are converging on the idea that AI designed to feel human needs its own rulebook — not just an extension of existing data privacy law.

Why This Matters If You’re Building AI Products

Even if your product isn’t an AI companion app, the underlying questions this regulation raises are becoming standard product decisions for anyone building with conversational AI:

• Should this AI remember the user across sessions? Persistent memory is powerful for usability, but it’s exactly the kind of feature regulators are now scrutinizing.
• How much personality should this AI have? Products designed to feel warm and personal are more engaging — and increasingly, more regulated.
• What happens to user conversation data? Using chat logs to fine-tune or improve a model is common practice. It’s also now a specific compliance question in at least three jurisdictions.
• Are your engagement mechanics manipulative by design, even unintentionally? Notification timing, guilt-based prompts, and streak mechanics that were once purely growth tactics are now legal risk surfaces.

These aren’t hypothetical concerns for a future product cycle. They’re live design decisions for anything shipping conversational AI features today, particularly in fintech, healthcare, education, and consumer apps — sectors where emotionally resonant AI is often exactly the point.

How We Think About This at Onclick Innovations

We build AI features for clients across fintech, healthcare, e-commerce, and SaaS, and this shift changes how we approach a feature request before writing a line of code. Memory, personalization, and personality used to be almost purely UX decisions. They’re now compliance decisions with real legal weight behind them, and that changes how early in a project they need to be addressed.

Our approach on any AI feature with a personal or emotional dimension now includes mapping it against the relevant regulatory landscape for the client’s markets before development starts — not as a late-stage legal review, but as part of the initial architecture conversation.

Frequently Asked Questions

What is China’s new AI companion law?
It’s the Interim Measures for the Administration of AI Anthropomorphic Interaction Services, issued by China’s Cyberspace Administration in April 2026 and effective July 15, 2026. It regulates AI systems designed to be human-like enough to create emotional attachment, requiring anti-addiction safeguards, minor protections, restrictions on training with private conversation data, and limits on manipulative design.

Which companies are affected?
ByteDance (Doubao), Alibaba (Qwen), and Tencent (Yuanbao) are all shutting down their custom AI persona features as a direct result of the new rules taking effect.

Will users lose their AI companion chat history?
Doubao users have a read-only export window through October 15, 2026. Alibaba has not published a similar plan for Qwen users as of early July 2026.

Is China banning AI companion apps entirely?
No. The measures regulate rather than prohibit the category. ByteDance is reportedly building a separate, compliant standalone companion app, suggesting the category continues under stricter rules rather than disappearing.

Does this affect AI regulation outside China?
Not directly, but it reflects a broader global pattern. California’s SB 243 and Washington State’s HB 2225 regulate similar territory in the U.S., focused on companion AI and manipulative engagement design.

Share

The post China Just Banned AI Companions As You Know Them — Here’s What Every AI Product Team Should Learn From It appeared first on Blog.

In that quarter of a second, an extraordinary sequence of events takes place across your device, multiple servers scattered around the planet, and several layers of internet infrastructure that most people never think about. This is the story of everything that happens in that invisible journey — from keystroke to pixel.

The Illusion of Instant

Modern browsing feels instant. That feeling is an illusion carefully engineered by decades of infrastructure investment, protocol optimisation and clever caching. Underneath that illusion is a genuinely complex pipeline involving your operating system, your router, your internet service provider, global naming systems, distant servers, and your browser’s rendering engine — all cooperating in milliseconds.

Understanding this pipeline is not just academic curiosity. It is one of the most useful mental models a developer, founder or technical decision-maker can have, because nearly every performance problem, security consideration and infrastructure cost in web development traces back to one of these steps.

Here is exactly what happens, step by step, from the moment you press Enter.

Step 1: Parsing What You Typed (0–1ms)

Before anything travels anywhere, your browser has to figure out what you actually typed. Modern address bars accept search terms, partial URLs and full addresses interchangeably, so the browser first determines whether your input is a valid URL or a search query destined for your default search engine.

If it is a URL, the browser parses it into its component parts: the protocol (http or https), the domain name, the path, and any query parameters. This happens locally, in well under a millisecond, before any network activity begins.

Step 2: The DNS Lookup (0–120ms)

Computers do not naturally know that “google.com” corresponds to a specific server. They need an IP address — a numerical identifier like 142.250.190.78. Translating a human-readable domain name into that IP address is the job of DNS, the Domain Name System, often described as the phone book of the internet.

The lookup process follows a specific order, checking increasingly slower caches until it finds an answer. First, the browser checks its own DNS cache — if you have visited this site recently, the answer may already be stored locally, and this step completes in under a millisecond. If not, the browser checks the operating system’s DNS cache, then potentially a local router’s cache.

If none of these have an answer, the request travels to a DNS resolver — typically operated by your internet service provider or a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. This resolver may need to query a chain of authoritative servers: first a root server, then a top-level domain server (responsible for all “.com” domains, for instance), then finally the authoritative server for the specific domain, which returns the actual IP address.

A cold DNS lookup with no caching anywhere in the chain can take anywhere from 20 to 120 milliseconds — a significant portion of your total 300 millisecond budget, spent before a single byte of the actual website has been requested. This is precisely why DNS caching, and services like DNS prefetching, matter so much for perceived site speed.

Step 3: The TCP Handshake (20–100ms)

With an IP address in hand, your browser now needs to establish a reliable connection to that server. Most web traffic runs over TCP, the Transmission Control Protocol, which guarantees that data arrives complete, in order, and without corruption — a critical property for something as detail-sensitive as a web page.

Establishing a TCP connection requires what is known as a three-way handshake. Your browser sends a SYN (synchronize) packet to the server, essentially saying “I’d like to start a conversation.” The server responds with a SYN-ACK packet, acknowledging the request and proposing its own synchronization. Your browser then sends a final ACK packet, confirming the connection is established.

Each of these three packets has to physically travel across the network — through your router, your ISP, and potentially dozens of intermediate hops — before the next one can be sent. This round-trip time, often abbreviated as RTT, depends heavily on physical distance. A server on the other side of the world will always have a higher minimum TCP handshake time than one in a nearby data centre, no matter how well-optimised the software is, because the packets are limited by the speed of light through fibre optic cable.

Step 4: The TLS Negotiation (30–100ms)

If the connection uses HTTPS — which the overwhelming majority of the modern web does — an additional negotiation happens immediately after the TCP handshake completes. This is the TLS (Transport Layer Security) handshake, and it is responsible for the encryption that keeps your data private and verifies you are actually talking to the server you think you are.

During this negotiation, your browser and the server agree on which encryption protocols and cipher suites they will use, the server presents a digital certificate proving its identity (issued by a trusted certificate authority), and both sides generate the cryptographic keys that will encrypt all subsequent communication. Modern TLS 1.3, now the dominant standard, reduced this from two round trips down to effectively one, meaningfully cutting the time this step takes compared to older TLS versions.

By the end of this step, you have a secure, authenticated, encrypted channel open to the server — and you still have not received a single byte of the actual web page.

Step 5: The HTTP Request and Server Processing (10–200ms)

With the secure connection established, your browser finally sends the actual HTTP request — specifying which page it wants, along with headers describing your browser, accepted content types, cookies, and other metadata.

What happens next depends entirely on how the destination server is built. For a simple static site, the server might locate a pre-built HTML file and return it almost instantly. For a dynamic application, the server typically needs to run application code, which might query one or more databases, call external APIs, apply business logic, and assemble a response — all before sending anything back.

This is the step where backend architecture decisions have the most visible impact. A well-indexed database query might add 5 milliseconds. A poorly optimised one, missing the right index or fetching far more data than needed, can add hundreds of milliseconds all on its own. This is also where server-side caching, content delivery networks and edge computing earn their keep — by serving pre-computed or cached responses instead of repeating expensive work for every single request.

Step 6: Receiving the Response and Parsing HTML (5–20ms)

The server’s response arrives, typically starting with an HTML document. Your browser does not wait for the entire page to arrive before beginning work — it starts parsing the HTML as bytes stream in, building what is called the DOM, or Document Object Model: a structured tree representation of every element on the page.

As the parser encounters references to additional resources — CSS stylesheets, JavaScript files, images, fonts — it typically kicks off requests for those resources immediately, often in parallel, rather than waiting for the full document to finish downloading first. This parallelism is a major reason modern pages load faster than a naive step-by-step model would suggest.

Step 7: Building the Render Tree and Layout (5–30ms)

Once enough CSS has arrived, the browser combines the DOM with the CSS Object Model (the parsed representation of your stylesheets) to produce what is called the render tree — essentially the DOM, but annotated with exactly how each element should look.

The browser then performs what is called layout, or reflow: calculating the precise size and position of every single element on the page, accounting for the viewport size, box model rules, flexbox and grid layouts, and every CSS rule that affects geometry. This is genuinely one of the more computationally expensive steps in the entire pipeline, which is why excessive dynamic layout changes are a common cause of janky, sluggish-feeling web pages.

Step 8: Painting and Compositing (5–20ms)

With layout complete, the browser moves to painting — converting the render tree into actual pixels, filling in colours, text, images, borders, shadows and every other visual detail. Modern browsers optimise this further through compositing, where different layers of the page (an animated element, a fixed header, a video player) are rendered independently on the GPU and combined at the final moment, allowing smooth animations and scrolling without repainting the entire page from scratch.

This is the step where your screen finally shows something. On a fast connection with an optimised site, everything from the initial DNS lookup to this final paint can complete in well under 300 milliseconds — fast enough that the entire journey feels instantaneous to a human brain.

Why Every Millisecond in This Chain Matters

Google has published research showing that even small increases in page load time measurably increase bounce rates and decrease conversions. Amazon has cited internal data suggesting that every 100 milliseconds of additional latency measurably impacts revenue. These are not abstract engineering concerns — they are direct business outcomes tied to exactly the pipeline described above.

Every step in this journey represents an opportunity for optimisation, and every step represents a potential point of failure or slowdown if built carelessly. DNS prefetching, connection pooling, HTTP/2 and HTTP/3 multiplexing, TLS session resumption, database query optimisation, CDN edge caching, code splitting, lazy loading and critical rendering path optimisation are all, at their core, techniques aimed at shortening one specific step in this exact pipeline.

What This Means for Anyone Building Software

Understanding this journey changes how you think about performance. A slow page is never just “slow” in some vague sense — it is slow at a specific, identifiable step. Maybe DNS resolution is taking too long because there is no caching strategy. Maybe the TCP and TLS handshakes are slow because the server is geographically distant from most users, with no CDN in front of it. Maybe the server processing step is slow because of an unoptimised database query. Maybe the rendering step is slow because of render-blocking JavaScript or excessive layout recalculation.

Each of these has a specific, well-understood fix. But you can only apply the right fix once you understand which step in the pipeline is actually the bottleneck — which is exactly why this invisible 300-millisecond journey is worth understanding in detail, not just accepting as web browsing magic.

How Onclick Innovations Builds for Speed

At Onclick Innovations, performance is not an afterthought we address after launch — it is a consideration at every step of this pipeline, built in from the start. We implement CDN strategies to shorten physical distance to users, optimise database queries and indexing to keep server processing fast, apply modern HTTP protocols and TLS configurations to minimise handshake overhead, and build frontend code with the critical rendering path in mind.

The result is software that feels instant — because every millisecond in this 300-millisecond journey has been considered, measured and optimised.

If your website or application feels slower than it should, we are happy to help identify exactly which step in this pipeline is the bottleneck.

📩 Get in touch → www.onclickinnovations.com
📍 Based in Mohali, India · Serving clients globally across 10+ countries

Frequently Asked Questions

What is a DNS lookup and why does it take time?

A DNS lookup translates a human-readable domain name like “example.com” into the numerical IP address computers use to locate a server. It takes time because, without caching, the request may need to travel through multiple servers — a resolver, a root server, a top-level domain server, and finally the domain’s authoritative server — each adding network round-trip time. Caching at the browser, operating system or router level can reduce a 100+ millisecond lookup to under a millisecond.

Why does HTTPS make websites slower than HTTP?

HTTPS requires an additional TLS handshake after the TCP connection is established, adding one or more network round trips to negotiate encryption before any page data is transferred. Modern TLS 1.3 has significantly reduced this overhead compared to older versions, and the security benefits far outweigh the small latency cost — which is typically tens of milliseconds, not a noticeable delay to users.

What is the biggest factor in how fast a website loads?

There is no single biggest factor — it depends on the specific site. Common major contributors include server response time (often tied to database query performance), geographic distance between the user and server (addressed by CDNs), unoptimised images and assets, render-blocking JavaScript and CSS, and inefficient rendering caused by excessive dynamic layout changes. Identifying the actual bottleneck for a specific site requires performance profiling rather than guessing.

What is the difference between the DOM and the render tree?

The DOM (Document Object Model) is the browser’s structural representation of the HTML document — every element and its relationship to other elements. The render tree combines the DOM with CSS styling information, representing only the elements that will actually be visually displayed, along with how each one should look. The render tree is what the browser uses to calculate layout and eventually paint pixels to the screen.

Can Onclick Innovations help improve our website’s load time?

Yes. We analyse performance across the entire request pipeline — from DNS and connection setup through server processing and frontend rendering — to identify the specific bottlenecks affecting your site and implement targeted fixes. Contact us at onclickinnovations.com to discuss your project.

Share

The post What Actually Happens When You Type a URL and Hit Enter appeared first on Blog.

The technology choices behind Netflix, Uber, WhatsApp, Instagram, Spotify and Airbnb reveal something the framework debates on social media rarely admit: there is no universally “best” stack. There is only the right stack for a specific problem, at a specific scale, with a specific team. Here is what each of these companies actually runs on — and the lesson behind each choice.

Netflix: Java, Cassandra and a Custom-Built CDN

Netflix serves over 300 million subscribers across 190 countries and is responsible for a significant share of global downstream internet traffic. Its technology choices reflect the scale of that challenge.

The frontend runs on React, with GraphQL (via Netflix’s open-source DGS framework) handling data fetching for most modern client surfaces, after years of relying on a custom system called Falcor. The backend is built predominantly in Java with Spring Boot, powering thousands of independently deployable microservices. Python and Go handle specific domains including machine learning and observability tooling.

For data storage, Netflix relies on Apache Cassandra as its primary scale-out NoSQL store, EVCache (a memcached-based system) for high-speed caching, and MySQL for transactional data like billing. Real-time data movement runs through Kafka and Netflix’s own streaming platforms, Mantis and Keystone.

Perhaps the most striking architectural decision is Open Connect — Netflix’s proprietary content delivery network. Rather than relying entirely on third-party CDNs, Netflix places its own caching servers directly inside internet service provider networks around the world, pushing content as close to viewers as possible during off-peak hours.

The lesson: when you operate at a scale where standard infrastructure no longer fits your problem, building proprietary infrastructure becomes the rational choice — not over-engineering.

Uber: Polyglot Microservices Built for Real-Time Geography

Uber’s engineering challenge is fundamentally about real-time coordination across location, time and millions of simultaneous transactions. The company’s technology stack reflects a deliberate move away from a single dominant language toward a polyglot microservices architecture.

Uber’s backend spans Go, Java and Node.js, chosen for different services based on performance requirements and team expertise. The company famously built its own database system, internally known as Schemaless, on top of MySQL to handle the specific consistency and scale requirements of ride data. PostgreSQL and MySQL both appear throughout the broader system for different workloads. Kafka handles the real-time event streaming that powers live trip tracking, surge pricing calculations and driver-rider matching.

Uber migrated from an early monolithic architecture to microservices specifically because a single application could not be scaled, deployed and maintained fast enough to support the company’s growth. This migration was not undertaken on day one — it happened in response to genuine scaling pressure.

The lesson: architecture should follow the shape of your actual problem. Uber’s real-time, geographically distributed coordination problem demanded an architecture that could evolve service by service, rather than a single codebase trying to do everything.

WhatsApp: Erlang and the Power of the “Boring” Choice

WhatsApp’s technology story is one of the most instructive in the industry. At the time of its acquisition by Facebook in 2014, WhatsApp was famously serving hundreds of millions of users with an engineering team that numbered only in the dozens.

The reason this was possible comes down largely to one technology choice: Erlang. Erlang is a programming language originally built by Ericsson for telecommunications systems — designed from the ground up to handle massive numbers of concurrent, lightweight connections with extremely high reliability. It is not a trendy language. It was never going to top a “hottest frameworks of the year” list. But it was exactly suited to WhatsApp’s core problem: keeping millions of persistent connections open simultaneously, reliably, with minimal overhead.

The lesson: the most-discussed technology is rarely the most appropriate one. WhatsApp chose a niche, decades-old language because it was the correct tool for the specific problem — and that choice let a tiny team support an enormous user base.

Instagram: Scaling to a Billion Users on Python

Instagram is frequently cited as proof that the programming language you choose matters far less than how you architect around it. The platform’s backend is built primarily in Python using the Django framework — a combination often dismissed as too slow for applications at serious scale.

Instagram has scaled past a billion users on this foundation. The data layer relies on PostgreSQL for core relational data and Cassandra for specific high-volume, high-availability workloads. Caching is handled through Memcached and Redis, which absorb the read load that would otherwise hit the database directly for every request.

What made this scale possible was not a language switch but disciplined engineering around the language: aggressive caching strategies, careful database sharding, asynchronous processing for non-critical paths, and a willingness to optimise the specific bottlenecks that actually appeared under real load rather than guessing in advance.

The lesson: a programming language’s raw performance characteristics matter far less at scale than the architecture built around it. Bad architecture will make a fast language slow. Good architecture can make a famously “slow” language scale to a billion users.

Spotify: Microservices and the Squad Model

Spotify’s technology stack centres on Java and Python across a large number of independently owned microservices, with Google Cloud Platform and BigQuery handling much of its data infrastructure, and Kafka powering real-time event streaming for everything from play counts to recommendation signals.

What makes Spotify particularly interesting is not just the technology but the organisational model built around it. Spotify popularised the “squad” model — small, autonomous, cross-functional teams that each own a specific service or feature area end to end, with the freedom to choose their own tools and deployment cadence within broad guardrails.

This organisational structure and the underlying microservices architecture reinforce each other. Independent services map naturally onto independent teams, allowing Spotify to ship changes across a vast product surface without every team needing to coordinate on every release.

The lesson: technical architecture and organisational structure are deeply connected. The way you split your codebase into services often ends up mirroring — or should mirror — the way you split your teams. This is sometimes called Conway’s Law, and Spotify is one of its most-cited modern examples.

Airbnb: Starting on Rails, Evolving Under Scale

Airbnb’s technology story is a useful counterpoint to the others on this list because it illustrates evolution rather than a single static stack. The platform was originally built on Ruby on Rails — a framework chosen specifically for the speed at which it allowed a small founding team to build, iterate and ship a working product.

As Airbnb scaled into a global marketplace processing complex search, pricing and trust-and-safety logic, the company began migrating performance-critical and team-isolated portions of its system toward service-oriented architectures using languages including Java and Kotlin, while React became the standard for frontend development. MySQL and Redis remain core to the data layer.

Airbnb did not rewrite everything overnight, and it did not start with a microservices architecture from day one. The migration happened gradually, driven by specific scaling pain points rather than a wholesale rejection of the original technology choice.

The lesson: starting with a framework optimised for development speed is often the correct early-stage decision, even if it is not the architecture you will run at massive scale. Re-architecting in response to real growth is normal and expected — it is not a sign that the original choice was wrong.

What These Six Stacks Teach Every Founder and CTO

Looking across all six companies, four patterns emerge that matter far more than any individual technology choice.

There is no universally best stack. Java works for Netflix and Spotify. Python works for Instagram. Erlang works for WhatsApp. Ruby on Rails worked for early Airbnb. Each choice was correct for the problem, team and stage it was made for — not because of any inherent superiority of the language itself.

Boring, proven technology beats trendy technology at scale. None of these companies built their core infrastructure on whatever was generating the most hype on social media at the time. Cassandra, MySQL, Kafka and PostgreSQL are not exciting choices. They are reliable ones, with deep operational knowledge available across the industry.

Architecture matters more than the language itself. Instagram on Python and WhatsApp on Erlang both scaled to enormous user bases despite using technologies that are, by raw benchmark numbers, far from the fastest options available. The architecture built around the language — caching strategy, database design, service boundaries — determined the outcome far more than the language choice alone.

Start simple and re-architect when growth demands it. Airbnb did not start with a complex microservices architecture. WhatsApp did not start by trying to anticipate Facebook-scale traffic. Every one of these companies built something that worked for their actual stage, then evolved the architecture as real scaling pressure emerged — not in anticipation of hypothetical future scale.

How Onclick Innovations Approaches Technology Decisions

At Onclick Innovations, we do not have a default stack we push onto every client regardless of fit. We have built production applications in React, Vue and Angular for the frontend, and Node.js, Python, PHP and Java for the backend — choosing based on the specific project, team, timeline and long-term maintenance considerations involved.

The pattern across the six companies in this article holds true for every project we work on, regardless of size: the right technology choice is the one that fits the actual problem you are solving today, with room to evolve as your product and user base grow. Not the most fashionable choice. Not the one with the most active hype on social media this month. The right one for your specific situation.

If you are making technology decisions for a new product, or reconsidering the architecture behind an existing one, we are happy to talk through the tradeoffs honestly.

📩 Get in touch → www.onclickinnovations.com
📍 Based in Mohali, India · Serving clients globally across 10+ countries

Frequently Asked Questions

What programming language does Netflix use?

Netflix uses Java with Spring Boot as the primary language for its backend microservices, React for its frontend, and Python and Go for specific domains like machine learning and observability. Its data layer relies on Apache Cassandra, EVCache and MySQL, with Kafka handling real-time event streaming.

Why does WhatsApp use Erlang?

WhatsApp chose Erlang because it was specifically designed for telecommunications systems that need to handle massive numbers of concurrent, lightweight connections with high reliability and minimal overhead. This made it exceptionally well suited to WhatsApp’s core technical challenge of maintaining millions of simultaneous persistent connections, allowing a small engineering team to support an enormous global user base.

How did Instagram scale to a billion users on Python?

Instagram scaled on Python and Django through disciplined architecture rather than raw language performance: aggressive caching with Memcached and Redis, careful database sharding across PostgreSQL and Cassandra, and asynchronous processing for non-critical operations. This demonstrates that architectural decisions around a language matter more than the language’s raw benchmark speed.

Should a startup choose the same tech stack as a company like Netflix or Uber?

No. The technology choices made by Netflix, Uber and similar companies were shaped by their specific scale, team size and problem domain at the time those decisions were made — often after years of evolution from much simpler starting points. A startup should choose technology that fits its current stage, team expertise and actual requirements, with an architecture that can evolve as real growth demands it, rather than copying the infrastructure of a company operating at a vastly different scale.

Can Onclick Innovations help us choose the right technology stack for our product?

Yes. We help clients evaluate technology decisions based on their specific project requirements, team composition, timeline and growth plans rather than defaulting to a single preferred stack. Contact us at onclickinnovations.com to discuss your project.

Share

The post The Tech Stack Behind 6 Famous Apps: What Netflix, Uber, WhatsApp, Instagram, Spotify and Airbnb Are Actually Built With appeared first on Blog.

React is still here. Still the default choice for new projects. Still the framework most developers learn first and most companies hire for. Still, by almost every measurable metric, winning.

This is the story of why React refuses to die — and an honest look at what would actually need to happen for something to replace it.

The Numbers First

Before the opinions, the data. As of 2026:

• React receives approximately 9 million npm downloads per week — a number that has grown consistently year over year
• Used in production by Meta, Netflix, Airbnb, Notion, Linear, Vercel, Atlassian and thousands of other companies at scale
• Next.js — React’s most popular framework — powers a significant proportion of all new web applications built today
• React developers represent the largest pool of available frontend talent in the world, by a considerable margin
• The React ecosystem — libraries, tools, community packages, documentation, courses — dwarfs any competing framework

These are not the numbers of a dying technology. They are the numbers of an entrenched standard.

A Brief History of React’s Many Predicted Deaths

Understanding why React keeps surviving requires understanding the pattern of the predictions.

2016–2018: Angular was going to win. Google’s Angular framework had enterprise backing, TypeScript from the start, and a complete opinionated structure that React deliberately lacked. It was the “professional” choice. React was “just a view library.” Angular would dominate enterprise development.

What happened: React’s simplicity and flexibility won. Angular’s complexity and steep learning curve slowed adoption. React took enterprise too.

2019–2020: Vue was the sensible alternative. Vue 3 brought a Composition API that many developers found more intuitive than React’s hooks. Its gentler learning curve and cleaner syntax made it a genuine alternative, particularly in Asia and Europe. The creator of Vue had worked at Google and the framework felt mature and thoughtful.

What happened: Vue 3 migration from Vue 2 was painful and slow, fracturing the ecosystem at a critical moment. React consolidated.

2021–2022: Svelte was revolutionary. Svelte compiled away the framework entirely — no virtual DOM, no runtime overhead, just clean JavaScript output. Svelte’s syntax was genuinely beautiful. Performance benchmarks were excellent. Many developers declared it the obvious future.

What happened: Svelte remained popular among developers who love it, but ecosystem growth stalled compared to React’s continued acceleration. SvelteKit is excellent. Svelte’s market share remains a fraction of React’s.

2023: SolidJS, Qwik, and the era of micro-frameworks. A wave of new frameworks promised better performance, smaller bundles, and smarter hydration strategies. Each was technically impressive. Each had a passionate community.

What happened: They educated React. React 18’s concurrent rendering and React 19’s Server Components borrowed and refined many of these ideas. The challengers made React better without displacing it.

2024–2025: htmx and the return to simplicity. A genuine philosophical counter-movement emerged — why use a JavaScript framework at all? htmx let server-rendered HTML handle interactivity with minimal JavaScript. It resonated deeply with developers exhausted by JavaScript complexity.

What happened: htmx carved out a real niche for content-heavy, interaction-light applications. It did not touch React’s dominance in complex, interactive application development.

Why React Wins — The Real Reason

The framework debates always miss the same fundamental point.

Technical superiority does not win ecosystems. Network effects do.

React does not need to be the best framework. It needs to be the one everyone already knows, the one with the most third-party libraries, the one with the most jobs posted, the one with the most Stack Overflow answers, the one every bootcamp teaches, and the one every company defaults to when starting a new project.

It is all of these things. By a wide margin.

When a new developer joins a team, the probability they already know React is high. When a company hires frontend developers, the pool of React developers is enormous. When a startup chooses a stack, React is the safe default — not because it is technically optimal for every use case, but because the hiring, the libraries, the documentation and the community all pull in that direction.

This is what economists call a network effect. The value of a technology increases with the number of people using it. React’s network effect is so large that technically superior alternatives struggle to overcome it — not because developers don’t appreciate their qualities, but because the switching cost of moving an ecosystem is enormous.

What React Critics Get Right

React is not perfect. Not even close. Intellectual honesty requires acknowledging this.

useEffect is genuinely confusing. The dependency array, the cleanup function, the mental model of effects synchronising with external systems — these are legitimately hard concepts that trip up experienced developers regularly. It is one of the most-searched topics in React development and has been for years.

The re-render model has sharp edges. React’s rendering behaviour — when components re-render, why they re-render, how to prevent unnecessary re-renders — requires genuine expertise to manage well in complex applications. useMemo, useCallback and React.memo exist precisely because the default behaviour needs help at scale.

Bundle sizes grow quickly. A poorly managed React application accumulates JavaScript at an alarming rate. Without careful attention to code splitting, lazy loading and dependency management, bundle sizes balloon in ways that hurt performance on slower connections and devices.

React Server Components are a paradigm shift. The mental model introduced by RSC in React 18 and refined in React 19 — the boundary between server and client components, the rules around what can run where — is genuinely difficult. It solves real problems but introduces real complexity.

Svelte is more intuitive. Vue has cleaner syntax for straightforward applications. SolidJS has more impressive performance benchmarks. All of this is true. None of it has been enough to shift the ecosystem.

React 19 and What Actually Changed

It is worth acknowledging that React in 2026 is not the React of 2015. The framework has evolved substantially.

React 19 introduced several meaningful changes: the Actions API that simplifies async state management, the new use() hook that handles promises and context in a more natural way, improvements to ref handling and form management, and continued refinement of the Server Components model.

Next.js 15 built on these foundations to create what is effectively a full-stack React framework — server-side rendering, API routes, middleware, edge functions, image optimisation, and a deployment pipeline all in one cohesive package. For many teams, Next.js is now the entire backend and frontend in a single framework.

React has survived this long partly by learning from its competitors and incorporating their best ideas. The pattern is likely to continue.

What Would Actually Kill React

Given all of this, what would actually need to happen for React to be displaced?

Meta abandons it. If Meta stopped investing in React and the core team dissolved, the community would face a genuine existential question. This seems extremely unlikely — React is foundational to Meta’s product development and has been for over a decade.

A native web component model good enough to make frameworks redundant. Web Components have promised this for years and have not delivered. If browser vendors converged on a component model so capable that frameworks added no meaningful value, the case for React would weaken significantly. This might happen in a decade or more. It has not happened yet.

AI-driven UI generation eliminates the need for a component model. This is the most genuinely interesting possibility. Tools like v0 by Vercel already generate React components from natural language descriptions. If AI advances to the point where developers describe interfaces and AI writes and maintains the component code, the framework choice may become abstracted away entirely. This is worth watching carefully over the next few years.

Until one of these scenarios materialises, React wins by default. Not because it is always the best tool. Because it is everywhere — and everywhere is very hard to compete with.

The Pragmatic Conclusion

The right question for any team is not “is React the best framework?” It is “which framework best fits this project, this team and these constraints?”

For most projects, most teams, most of the time — that answer is React or Next.js. Not because the alternatives are bad. Because the ecosystem, the talent pool and the long-term maintenance story all point in that direction.

For content-heavy sites with minimal interactivity, htmx or Astro might be better. For teams deeply invested in Vue, Vue 3 is excellent. For projects where performance is the absolute priority, SolidJS deserves serious consideration. For new small projects where developer experience matters most, Svelte is a genuine delight.

The framework wars are interesting. The business of building software is pragmatic. React is still winning because pragmatism, at scale, almost always looks like the default choice.

How Onclick Innovations Approaches Framework Decisions

At Onclick Innovations, we build with React, Next.js, Vue and Angular — choosing the right tool for each specific project rather than defaulting to one framework for everything.

We have shipped production applications in React and Next.js for startups, enterprises and everything in between. We have built Vue applications where the team’s existing expertise made it the obvious choice. We have worked in Angular codebases where the structure and patterns were exactly right for the project’s complexity.

We don’t have framework religion. We have shipping deadlines and clients who need products that work.

If you are making frontend technology decisions for a new project — or reconsidering the choices made on an existing one — we are happy to talk through the tradeoffs honestly.

📩 Get in touch → www.onclickinnovations.com
📍 Based in Mohali, India · Serving clients globally across 10+ countries

Frequently Asked Questions

Is React still worth learning in 2026?

Yes — unambiguously. React remains the most in-demand frontend skill in the job market by a significant margin. Learning React gives access to the largest ecosystem of libraries and tools, the most comprehensive documentation and community support, and the widest range of job opportunities. Whatever replaces React eventually, it has not appeared yet.

Is Next.js the same as React?

Next.js is a framework built on top of React that adds server-side rendering, file-based routing, API routes, and a production-optimised build system. React is the underlying UI library — Next.js extends it into a full-stack application framework. Most new React projects in 2026 start with Next.js rather than plain React.

What are the best alternatives to React in 2026?

The most mature alternatives are Vue 3 (excellent developer experience, strong ecosystem), Svelte and SvelteKit (intuitive syntax, compiled output), Angular (comprehensive enterprise framework), and SolidJS (superior performance benchmarks). For content-heavy sites, Astro and htmx are worth considering. Each has genuine strengths — the right choice depends on your specific project requirements.

Why do developers keep predicting React’s death?

Because React genuinely has real weaknesses that alternatives address well. useEffect is confusing, the re-render model has sharp edges, and bundle sizes can grow quickly. When a new framework solves these problems elegantly, it is natural for developers to predict a transition. What these predictions underestimate is the weight of React’s ecosystem and network effects — which have proven extremely durable.

Can Onclick Innovations build our project in React or Next.js?

Yes. React and Next.js are our most-used frontend technologies and we have extensive production experience across both. Contact us at onclickinnovations.com to discuss your project requirements.

Share

The post React Is 13 Years Old — And It’s Still Winning in 2026. Here’s Why. appeared first on Blog.

One of the biggest mistakes founders, CTOs, and product teams make is assuming that if software is working, it is ready for production.

But those two things are very different.

“Working” means the software can perform the expected task in a controlled environment.

“Production-ready” means the software can survive real users, real data, real traffic, real failures, and real business pressure.

This gap is where many software projects fail.

What “Working” Software Really Means

When a feature is working, it usually means it does what it is supposed to do under ideal conditions.

• It works on the developer’s machine.
• It works with test data.
• It works when the user follows the expected path.
• It works when all third-party services are available.
• It works when only one person is using it.

That is useful, but it is not enough.

A working feature can still break under real-world conditions. It may look good in a demo, pass basic testing, and still fail badly once actual users start depending on it.

What Production-Ready Software Actually Means

Production-ready software is built for real business use. It is not just about whether the main feature works. It is about whether the entire system can operate reliably, securely, and predictably after launch.

Production-ready software should be able to:

• Handle many users at the same time.
• Accept bad input without crashing.
• Fail gracefully when dependencies go down.
• Log important errors so issues can be debugged quickly.
• Recover from failures without losing data.
• Protect against common security risks.
• Monitor performance and errors before users complain.
• Support safe deployment, rollback, and future updates.
• Be understandable for developers who did not originally build it.

That is the real difference.

Working software proves that an idea can function. Production-ready software proves that a business can depend on it.

The Difference Between a Demo and a Business

A demo is usually built around the happy path. The user clicks the right buttons, enters valid data, and everything behaves as expected.

A real product is different.

Users enter unexpected data. Networks fail. Payment providers go down. Servers slow down. APIs time out. Databases receive duplicate requests. Bots attack forms. A new deployment breaks something that was working yesterday.

This is why production readiness matters.

The real test of software is not whether it works when everything goes right. The real test is whether it behaves safely when something goes wrong.

Real Examples of Software That Was “Working” but Not Production-Ready

1. The Payment Flow That Charged Users Twice

The payment flow worked perfectly during testing. One user clicked “Pay,” the transaction went through, and the order was created.

But in production, two requests came in at almost the same time. The system did not handle duplicate transactions properly, and the customer was charged twice.

The feature was working. It was not production-ready.

2. The Login System That Crashed on Unexpected Input

The login system worked with normal usernames and passwords. But when a user entered an unusual character, such as an emoji, the system failed because input validation and database handling were not strong enough.

A production-ready system should expect unexpected input. It should validate, sanitize, reject, or safely process data without taking down the application.

3. The App That Failed on Launch Day

The application looked smooth in the demo. Pages loaded quickly, the interface worked, and the product felt ready.

Then launch day came. Hundreds of real users opened the app at the same time, and pages started taking 30 to 45 seconds to load.

The app worked in testing, but it had not been designed or tested for scale.

4. The API That Failed When a Third-Party Service Went Down

The API worked well as long as every dependency was available. But when one third-party service went offline, the entire application stopped responding.

A production-ready system should not collapse completely because one external service fails. It should use timeouts, retries, fallback behavior, and graceful error handling.

5. The Feature That Broke Silently

A new feature was released on Friday. It appeared to work, and the team moved on.

By Monday, users had already experienced problems, but nobody on the team knew because there was no monitoring, no alerting, and no visibility into the failure.

Production-ready software does not depend on users to report every problem. It should detect issues early through monitoring, logging, and alerts.

Why Rushing to “Working” Becomes Expensive

The most expensive software is often not the software that takes longer to build properly.

The most expensive software is the software that has to be rebuilt because the first version was rushed to “working” and called complete.

When production readiness is ignored, the cost usually appears later in the form of:

• Emergency bug fixes
• Lost customer trust
• Failed launches
• Security vulnerabilities
• Data loss
• Poor performance
• Developer confusion
• Expensive rewrites

Many teams think they are saving time by skipping error handling, monitoring, documentation, scalability planning, and security review.

In reality, they are often moving the cost from development time to business risk.

A Simple Production-Ready Software Checklist

Before calling any feature complete, ask these questions:

• What happens if two users perform the same action at the same time?
• What happens if the user enters invalid or unexpected data?
• What happens if a third-party API is slow or unavailable?
• What happens if the database request fails?
• What happens if traffic suddenly increases?
• Can we detect errors before users complain?
• Can we roll back safely if something breaks?
• Is sensitive data protected properly?
• Can another developer understand and maintain this code?
• Is the system documented well enough for future changes?

If the answer to these questions is unclear, the software may be working, but it is not fully production-ready.

Production-Ready Software Is a Business Decision

Production readiness is not just a technical concern. It is a business decision.

For founders and CTOs, the goal is not only to launch fast. The goal is to launch in a way that can support users, protect the business, and create a foundation for growth.

A product that only works in a demo may impress people for a moment.

A product that is production-ready can support customers, revenue, operations, and long-term growth.

Working is the starting point. Production-ready is the standard.

How Onclick Innovations Builds Production-Ready Software

At Onclick Innovations, “working” is never the finish line.

We build software with production readiness in mind from day one. That means error handling, monitoring, security, scalability, clean architecture, and documentation are not treated as afterthoughts.

They are part of the foundation.

Whether you are building a startup MVP, a SaaS platform, a custom web application, an internal business tool, or a scalable digital product, the difference between “working” and “production-ready” can decide how reliable your product becomes after launch.

If you need developers who can build beyond the demo, Onclick Innovations can help.

Visit: www.onclickinnovations.com

Share

The post “It’s Working” and “It’s Production-Ready” Are Not the Same Thing appeared first on Blog.