What We Actually Mean by "Complex"

Every studio, including ours, uses the word "complex" when scoping a website or app. Most of the time it's shorthand, not an actual definition. We think that's a problem, because "complex" is what shows up on the invoice.

So this post breaks the word down into the things that actually make a project harder to build: how heavy the pages are, what the front end has to do, how many outside systems it talks to, and — for Indian businesses specifically — how many regulators have a say in how it's built. None of this is opinion. Every claim below is sourced.

Complexity you can measure: page weight and Core Web Vitals

The simplest, least debatable form of complexity is how much a browser has to download and process before a page is usable.

The HTTP Archive's Web Almanac tracks this every year, and the trend is stark: the median mobile home page grew from 845 KB in 2015 to 2,362 KB by mid-2025 — a 202.8% increase over the decade. Desktop pages grew 110.2% in the same period, and the median jumped 7.8% year-over-year to 2.7 MB by 2025 alone Web Almanac, page weight.

JavaScript is the main driver of that weight, and most of it is dead weight. At the median, about half the JavaScript bytes downloaded on a mobile page — roughly 206 KB, or 44% of what's delivered — go unused during page load Web Almanac, JavaScript. That's code the browser fetched, parsed, and paid a performance cost for, without ever running it.

The downstream effect shows up in Google's own numbers: 40% of sites in the Chrome User Experience Report fail to meet the recommended threshold for Largest Contentful Paint, one of the three Core Web Vitals. Google's own guidance for fixing this is blunt — avoid "large, complex layouts" web.dev, Core Web Vitals. Complexity here isn't abstract. It's kilobytes, unused scripts, and layouts the browser struggles to paint quickly.

Google also flags a second, less obvious form of technical complexity: URL structure. Search Central warns that overly complex URLs — especially ones with many parameters — can waste crawl budget and stop a site from being fully indexed Google Search Central, URL structure. This is the kind of complexity that never shows up in a client meeting, but quietly caps how much of a site Google ever bothers to look at.

Complexity from tooling: what a framework actually buys you

A lot of "complex" gets attached to the decision to use a JavaScript framework — React, Angular, Vue, and so on. The honest answer is that this is a genuinely contested point among the people who build this software for a living.

MDN's own documentation is neutral to positive: frameworks provide "tried and tested tools for building scalable, interactive web applications" and are considered essential to modern front-end work MDN, Frameworks and libraries. Fair enough — for a genuinely large, interactive application, that's true.

Smashing Magazine pushes back hard on applying that logic to smaller projects. Its argument: frameworks like Angular and React were built by Google and Meta to sustain their own enormous, long-lived codebases, and teams routinely underestimate how much time it takes to build something reliable and maintainable with a framework designed for that scale, on a project that doesn't need it Smashing Magazine, web development getting too complex.

MDN's own more detailed guidance actually agrees with part of that concern. It notes that a framework "amplifies" whatever priorities the development team already has — if performance and accessibility aren't actively protected, the result is a bloated, fragile, inaccessible site. The framework isn't automatically the villain; unmanaged priorities are MDN, Frameworks introduction.

Our takeaway for clients: "we're using React" is not, by itself, a complexity justification. What matters is whether the project's actual requirements (state management across many screens, offline support, real-time updates) need that machinery, or whether it's being added by default.

Complexity from integrations: the part that actually drives cost

Across independent cost-estimation guides, the one factor everyone agrees adds real complexity is connecting a site or app to outside systems — CRMs, marketing automation tools, payment processors, inventory or ERP systems. One guide puts it directly: each integration point introduces its own dependencies and potential failure modes, and connecting to external systems requires specialized expertise beyond front-end or back-end build work Convergine, cost factors.

This is also where cost estimates diverge wildly, which is itself worth naming honestly:

There's no industry-wide number for what "complex" costs. What the guides agree on, even while disagreeing on price, is that scope, integration count, and non-functional requirements like security and scalability are what push a project from one bracket to the next Wolfpack Digital, cost guide. If a vendor quotes you "complex" without naming which integrations or non-functional requirements drove the number, ask.

Complexity that's specific to India: the compliance stack

This is the part of "complex" that a generic international guide won't cover, and it's often the biggest hidden driver of scope for Indian businesses, especially anything touching payments or personal data.

Payments. RBI's Master Directions for Payment Aggregators, effective September 2025, tightened requirements considerably. They now require 100% data localization, meaning any foreign copy of transaction data has to be purged within 24 hours, along with stricter merchant due diligence Razorpay, payment gateway compliance. On top of that, PCI DSS v4.0.1 became fully enforceable from March 31, 2025, and it adds a requirement most teams haven't budgeted for: mandatory client-side script monitoring, to catch digital skimming attacks on checkout pages Razorpay, payment gateway compliance. RBI also bars merchants from storing card numbers, CVV, or expiry dates on their own servers at all, regardless of PCI DSS status — which forces tokenization integration into the build, not as an optional extra PhonePe Business, RBI compliance rules.

Data protection. India's Digital Personal Data Protection Act, 2023, together with the DPDP Rules notified in November 2025, goes well beyond a privacy policy and a cookie banner. It sets requirements around consent capture, notice language, security safeguards, and breach notification Legal500, DPDP Act website compliance. The main substantive obligations phase in over time, with the bulk of duties starting around 18 months after the November 2025 notification — roughly May 2027 Privacy World, DPDP Rules. That gives businesses a runway, but it also means "we'll add DPDP compliance later" is a real, plannable line item, not a vague future risk.

Tax and invoicing. GST e-invoicing requires an API connection between a business's billing or ERP system and the government's Invoice Registration Portal. This isn't optional once a business crosses the relevant turnover threshold — taxpayers with annual aggregate turnover between ₹5 crore and ₹10 crore, for instance, have already been brought into the e-invoicing mandate GST e-invoice portal.

Stack these three together — RBI plus PCI DSS, DPDP, and GST e-invoicing — and you get a compliance layer that's genuinely specific to building for the Indian market. It doesn't show up in most Western "how complex is your website" checklists, and no single regulator publishes it as one unified list. It has to be assembled project by project.

A working checklist for what "complex" should actually mean

When we (or any studio) say a project is complex, it should be traceable to one or more of these, not just a feeling:

If a quote or proposal calls a project "complex" and can't point to which of these apply, that's worth asking about before signing.

Questions people also ask

Is a website "complex" just because it uses React or Angular?

Not by itself. MDN treats frameworks as standard tooling for interactive apps MDN, but Smashing Magazine argues teams often add framework-level complexity to projects that don't need it, based on habits from Google- and Meta-scale codebases Smashing Magazine. The real question is whether your interactivity and state-management needs justify it.

Does accepting online payments in India automatically make a project "complex"?

Usually yes, in a specific and traceable way. RBI's data localization and due-diligence rules Razorpay, PCI DSS v4.0.1's client-side monitoring mandate Razorpay, and the ban on storing card data locally PhonePe Business all add real engineering work beyond a basic checkout integration.

Why do different agencies quote wildly different prices for a "complex" site or app?

Because there's no industry-standard definition. Published brackets range from roughly $30,000 Amcodr to $250,000+ Netguru depending on how each vendor defines scope, integrations, and non-functional requirements Wolfpack Digital. Ask any quote to itemize which specific factors are driving the "complex" label.