Blog

If you have collected three quotes for a website and they read ₹18,000, ₹95,000 and ₹4 lakh, you are not being cheated by two of them. You have asked three companies a question that has no single answer, and each has assumed a different project. This page sets out what each price band actually buys in India, what the recurring costs are, and the three questions that make quotes comparable.

Most founders get their first app quote and cannot tell whether it is reasonable. The range is genuinely enormous, and unlike a website, there is very little you can compare it against. This page sets out the three bands app projects actually fall into, what moves a project between them, and the one budgeting mistake that costs more than any negotiation will save you.

Most ERP budget conversations go wrong in the first meeting, because everyone compares licence prices. On the major platforms, implementation is typically sixty to seventy per cent of the first year's budget. Comparing licences is therefore comparing the smaller third of the cost, and the platform that looks cheapest on that basis is frequently not.

ISO 27001 is the certification European, APAC and Middle Eastern buyers ask for, and Indian companies routinely delay it because nobody will give them a number. Published Indian pricing for 2026 puts a typical startup or mid-market company of ten to a hundred employees at ₹2–4 lakh for year one — considerably less than most people assume, and less than the equivalent SOC 2 exercise.

An e-commerce build costs between ₹50,000 and ₹2.5 lakh in India, most commonly WooCommerce with a payment gateway. That range is wide because four things move it, and because the build price is only part of what an online store costs you.

Search for IT annual maintenance contract pricing in India and you will find almost nothing specific. Vendors explain that it depends on location, equipment age and service level — which is true, and also conveniently keeps you without a benchmark when the negotiation starts.

Timeline questions get vague answers because the honest answer depends on things the supplier cannot see yet. Here are the realistic ranges, and — more usefully — the three variables that actually decide where within them you land.

CRM is quoted per user per month, which makes it look simple and hides where the money goes. The licence is frequently the smaller half of year one, and the number a finance director should be approving is four times larger than the one on the vendor's pricing page.

Chatbot quotes are unusual in one respect: the build cost is often the smaller number. A rule-based bot costs a fraction of an LLM bot to build and almost nothing to run. An LLM bot costs more to build and then charges you for every conversation, forever. Choosing on build price alone is how businesses end up with an annual bill larger than the project.

Website maintenance is the line most businesses skip and most regret. It is also the line where you are least able to tell whether you are getting anything, because a well-maintained site and a neglected one look identical right up until the moment they do not.

Security programmes usually start with tools. A DLP product, an encryption policy, an access review. Each of them asks the same question in its configuration screen: which data is sensitive? And that is where the programme stalls, because nobody has answered it.

Most breaches escalate the same way. An attacker gets ordinary access, finds a credential with more privilege, and uses it. The controls that stop this are unglamorous and mostly free.

Object storage is priced to look inexpensive. A few paise per gigabyte per month invites a culture of keeping everything. Several years in, the bucket holds every log file, every image variant, every database export ever taken, and the line item is no longer small.

Time-series data has a particular profile: writes are constant and append-only, reads are almost always over a time range, and old data is queried less as it ages. A relational database will accept this workload happily for a while and then become the bottleneck.

Location features fail in India for a reason that has nothing to do with the mapping library. Addresses here are frequently descriptive rather than structured — a landmark, a lane, a building name that the postal system recognises and no geocoder does. A pin dropped by the user is often more reliable than the text they typed.

A customer data platform promises to collect behavioural and transactional data from every channel, resolve it to individual people, and make those profiles available to marketing and support tools. When it works, it is genuinely useful. It also costs a great deal and depends entirely on data you may not have in usable shape.

India's Digital Personal Data Protection framework treats consent as the primary basis for processing personal data, with limited exceptions. That single sentence has architectural consequences most teams underestimate, because consent is not a checkbox — it is a state that changes over time and must be provable.

Sustainability reporting has moved from voluntary to structured for large listed Indian companies through SEBI's Business Responsibility and Sustainability Reporting requirements. Those companies increasingly push the question down their supply chain, and software vendors are part of that chain.

Sharding means splitting rows across multiple database servers so no single machine holds everything. It works, and it is close to irreversible. Every subsequent feature has to respect the shard boundary, and any query spanning shards becomes an application-level join.

Both vendors provide migration tooling that moves mail, calendars and contacts competently. If email were the whole job, this would be a weekend. It is not, and the parts that hurt are the parts nobody inventories before starting.

An identity provider authenticates users and tells your applications who they are. Once several applications depend on it, replacing it means reconfiguring every one, migrating credentials that in many cases cannot be exported, and asking users to re-enrol their second factors. Choose accordingly.

Detecting an intrusion requires someone looking at alerts at three in the morning. Covering every hour of every week with reasonable handover and leave cover takes a team, not a person, and that team needs to be busy enough to stay sharp. Below a certain size, building this in house produces an expensive rota that is bored most of the time and inexperienced when it matters.

Warehouse management demos are all impressive. The system that fails is rarely the one with fewer features — it is the one that assumed conditions your warehouse does not have.

Every organisation with more than a few data pipelines reaches the same moment: two reports show different revenue figures, and resolving it takes days of tracing transformations backwards through jobs nobody has looked at in a year.

A feature store holds the computed inputs to machine learning models and serves them consistently to both training and inference. The problem it addresses is genuine: a feature calculated one way in a training notebook and another way in production code produces a model that performs worse in the real world than in evaluation, and the cause is extremely difficult to find.

The gap between a model that works in a notebook and one that runs reliably in production is mostly engineering, and most of that engineering is unremarkable — versioning, reproducibility, deployment, monitoring. The industry's tooling is built for scale that few teams have.

GST rates and classifications change. When they do, every billing system in the country has the same week: finding where the rate lives, changing it, and discovering what broke.

Label printing defeats more retail and warehouse projects than any algorithm. The reason is that the web platform was not designed for it, and the workarounds each have a cost.

The technical differences between the options are smaller than the discussions suggest. All three ship credible applications. The decision that actually matters is which team you can hire and keep, and what your roadmap demands of the platform.

Business intelligence tools are evaluated on features and abandoned for other reasons. Six months after launch, the dashboards nobody opens outnumber the ones that changed a decision, and the licence renewal becomes an awkward conversation.

Email is where the record of a commercial relationship actually lives. When a contract dispute, an employment claim or a regulatory question arises, the correspondence is the evidence, and the ability to produce it — or the failure to — shapes the outcome.

The Change Advisory Board exists to catch the change that would cause an outage before it happens, and in most organisations it has drifted into something else: a weekly meeting where a long list of changes is read out, nobody has read the details in advance, and everything is approved because objecting to something you haven't reviewed feels presumptuous. The board exists, the meeting happens, and it prevents almost nothing.

ServiceNow is the platform enterprises buy, and it is genuinely capable of modelling almost any process an organisation could want — which is exactly the problem for a mid-market buyer. The implementation effort and licensing cost are built around large, complex estates with dedicated administrators, and a fifty-person company adopting it is usually paying for capability it will never configure, let alone use.

IT asset management sounds like inventory and is really about accountability. A spreadsheet listing every laptop, monitor and phone is not an asset register if nobody updates it when a device is issued, returned, or lost — it's a snapshot of the day it was created, and every day after that it grows less accurate.

A service catalog exists to let someone request what they need without knowing which team owns it or what the internal process is called. Most catalogs fail this test because they're organised by department — IT, HR, Facilities — which requires the requester to already know who handles their problem, which is exactly the knowledge the catalog was supposed to remove the need for.

The standard priority matrix — impact against urgency, producing a P1 through P4 — looks rigorous and gets overridden constantly in practice, because it doesn't account for the thing that actually determines how a ticket gets treated: who raised it and how loudly. A P3 ticket from a senior executive routinely jumps the queue ahead of a P2 from someone junior, and pretending the matrix is what's driving prioritization is dishonest to everyone using it.

Average handle time is the metric most helpdesks track and the one most easily gamed, because an agent under pressure to keep it low learns to close tickets fast rather than resolve them properly, and the same problem returns as a second ticket a week later. The metric improves while the actual experience of being supported gets worse.

Shadow IT exists because the approved path for adopting a new tool is slower than a team's need for it. A marketing team wanting a design tool this week will not wait six weeks for procurement to review it — they'll sign up with a company card, and by the time IT finds out, customer assets and possibly customer data are already inside a tool nobody vetted for security or data residency.

Most helpdesks treat documentation as a task someone will do later, separately from actually resolving tickets, which means it competes with ticket volume for attention and reliably loses. The result is the same category of issue solved from scratch repeatedly by different agents, each one unaware that a colleague solved the identical problem last month.

Incident management and problem management solve different questions and get conflated constantly. Incident management asks how do we restore service right now, and closes the ticket the moment the symptom is gone. Problem management asks why does this keep happening, and it's a question that has no place inside an active incident because answering it properly takes longer than the business can tolerate being down.

The instinct during a serious outage is to pull in everyone who might be able to help, and beyond a certain point that instinct actively slows recovery. A call with fifteen people, all capable engineers, produces cross-talk, duplicated investigation, and a fix that's harder to coordinate — not because any individual is unhelpful, but because coordination overhead grows faster than the value each additional person adds.

The two terms get used interchangeably and they answer genuinely different questions. Disaster recovery is a technical capability: can this system be restored, and how quickly. IT service continuity management is broader and organisational: if a major disruption happens, can the business keep functioning, and what does that require beyond restoring servers — alternate work locations, manual fallback processes, communication to customers, and a clear decision on which systems must come back first.

A self-service portal is sold internally on the promise of reduced ticket volume, and most fail to deliver it because they're built around what IT wants to offer rather than what users are actually asking for. Look at your ticket history before building anything — the top ten or fifteen request types by volume are the ones that need a genuinely good self-service path, and everything else can wait.

AIOps vendors pitch autonomous remediation — infrastructure that heals itself without a human in the loop — and for most organisations that's not where the near-term value actually is. What AI genuinely does well in IT operations today is correlation and noise reduction: taking the hundreds of alerts a busy infrastructure estate generates and identifying which handful are actually related to one underlying event, rather than autonomously fixing anything.

Modern engineering practice favours teams deploying independently and frequently, and that's correct for most changes — the CI/CD guidance elsewhere on this site makes the case for it clearly. Release management as a discipline exists for the smaller category of changes where independence stops being enough: when two teams' changes touch the same system in the same window, or when a change is significant enough that the business needs advance notice regardless of how well-tested it is.

Approval workflows exist to add a human decision point where one is genuinely needed, and in practice most organisations route far more requests through them than that. A manager facing forty routine access requests a week for tools their team already uses is not making forty considered decisions — they're clicking approve as fast as possible because being the reason a colleague can't do their job for three days is worse than the theoretical risk of an ungranted access request slipping through.

When IT cost sits in one central budget line with no visibility into which department is driving it, every department behaves rationally by requesting more IT resource than they would if they actually saw the price attached — because from their perspective it's free. Chargeback and showback are the two mechanisms for fixing that, and they differ in one important way: chargeback actually bills the department for what they consume, showback simply reports it without moving money.

A stated uptime target like 99.9% sounds precise and rigorous, and most people quoting it haven't actually calculated what it permits: roughly 43 minutes of downtime per month, or about 8.7 hours a year. Whether that's an acceptable target depends entirely on the system it applies to and when the downtime occurs, and a single blanket target across every system in an organisation is almost always wrong for most of them.

Public leaderboards rank models on broad benchmarks that rarely resemble what a specific product actually needs the model to do. A model ranking highly on general reasoning benchmarks can underperform a lower-ranked model on your specific task — structured extraction from a particular document format, say, or a narrow classification job — because leaderboard rankings average across a wide spread of tasks, and your task may sit far from that average.

A multimodal model that accepts text, images and sometimes audio in a single request is genuinely useful when the task actually requires combining information across those modes — reading a scanned invoice where the layout and the text both carry meaning, or answering a question about what's visible in a photograph. It's a poor fit when a product simply has an image somewhere in its workflow and the team defaults to sending it to the model because the capability exists, when a much cheaper text-only or vision-specific pipeline would do the job.

Synthetic data — generating training examples rather than collecting them from real usage — is genuinely valuable where real data is scarce, sensitive, or expensive to label: rare edge cases that barely occur naturally, or scenarios where using real customer data for training raises privacy concerns the synthetic version sidesteps entirely. Used deliberately for these gaps, it's a real technique with real value.

Red-teaming an AI system means deliberately trying to make it behave badly, before shipping, rather than discovering the failure modes from real users after launch. It's broader than the prompt injection testing covered elsewhere on this site — that's one specific attack category. Red-teaming also probes for the system producing harmful, biased, or simply embarrassing outputs under adversarial or unusual input, and for the system being manipulated into behaviour outside its intended scope through means that have nothing to do with hidden instructions in content.

Retention periods in India are not set by a single statute. Company records, tax records, GST records, employment records and sector-specific records each have their own requirement, and the periods do not align. A software system with one global retention setting will inevitably be wrong for some category of data.

Adding video to a product looks like a storage problem and is actually a delivery problem. A single high-resolution file served to everyone will buffer on the connections a large share of Indian users have, and will consume data that many of them are counting.

Inheriting an unmanaged Windows fleet is common in Indian mid-market companies that grew faster than their IT function did — laptops purchased at different times, imaged inconsistently or not at all, and patched whenever an individual user happened to click 'update now'. The instinct is to push a mandatory update to everything at once, and that instinct is what causes an outage rather than fixing one.

A managed service provider's entire business model depends on servicing many clients' infrastructure with a small team, and that only works with a remote monitoring and management platform doing the watching that a human otherwise would. Without one, 'managed' means someone remembers to check periodically, which does not scale past a handful of clients and does not catch problems before a client notices them.

Indian retail brands routinely commission a native app because a competitor has one, without examining whether their actual usage pattern justifies it. A Progressive Web App — a website that can be added to a home screen, cached for offline use, and can send push notifications on Android — delivers most of what retail actually needs from an app at a fraction of the build and maintenance cost.

A content-heavy site — a blog, documentation, most marketing pages — doesn't need to query a database on every request, because the content changes rarely and is the same for every visitor. Building one on a full server-rendered framework with a live database connection is solving a problem the site doesn't have, and paying in server cost and attack surface for flexibility nobody uses.

A headless CMS stores and delivers content through an API rather than rendering pages itself, which lets the same content power a website, a mobile app and anything else through one editing interface. The appeal to engineering is real — no monolithic platform to maintain, no plugin ecosystem to patch — but the decision that actually determines whether it succeeds is whether the people writing content every day can use it comfortably.

WebAssembly lets code written in languages like Rust, C++ or Go run in the browser at close to native speed, and the pitch — near-native performance on the web — makes it tempting to reach for on any project with a performance complaint. Most web applications' performance problems are not computational; they're network latency, unoptimised rendering, or too much JavaScript shipped to the client, none of which WebAssembly fixes.

WebSockets have become the default answer for 'we need real-time updates,' and they're genuinely the right tool when the client needs to send frequent messages back to the server — a chat application, a collaborative editor, a multiplayer game. A large share of real-time features don't actually need that: they need the server to push updates to the client, one direction only, which is a simpler problem with a simpler solution already built into every browser.

Most Indian applications run their backend out of a single region — commonly Mumbai — which serves users near that region well and users in the northeast or far south with a round trip that's noticeably longer, even within the same country. Edge functions run code at points of presence distributed geographically, closer to wherever the request originates, cutting that round trip for the parts of the logic that can run there.

The fastest way to ship dark mode is a CSS filter that inverts every colour on the page, and it produces a genuinely unpleasant result: images invert into unnatural colours, shadows that should recede now appear to glow, and a white card floating on a previously-white background becomes a dark card with none of the visual hierarchy the light version had. Users notice this immediately even if they can't articulate why the dark mode feels wrong.

Building a browser extension is technically approachable — a manifest file, some scripts, a small interface — and the parts that actually determine whether it succeeds are the review process and the permissions it asks for, both of which are largely outside the developer's control once the extension is submitted. Chrome's Manifest V3 in particular restricted what extensions can do with background processes, and any extension design predating that shift needs re-architecting rather than a minor patch.

Traditional antivirus works by matching files against a known list of malicious signatures, which means it's structurally unable to catch anything genuinely new. Endpoint detection and response tools work differently — watching behaviour on the device and flagging patterns that look malicious regardless of whether the specific threat has been seen before, which catches a meaningfully wider category of attack.

Bring-your-own-device is the reality in most Indian companies whether or not it was ever decided deliberately — an employee simply adds their work email to their personal phone, and from that moment, company data lives on a device IT has no control over, no visibility into, and no ability to wipe if the phone is lost or the employee leaves under difficult circumstances.

A traditional VPN was designed on the assumption that most employees work from the office and occasionally connect remotely — a small, predictable slice of traffic. Hybrid work inverted that assumption without most companies redesigning the infrastructure to match, and the result is a VPN concentrator sized for occasional use now carrying most of the company's daily traffic, which is why it's slow and why it's become a single point of failure that didn't matter as much when it was lightly used.

Office Wi-Fi complaints almost always get diagnosed as a signal strength problem — 'we need a stronger router' — and the actual cause at growing headcount is usually device density rather than signal. A single access point can serve a signal strong enough to show full bars across an entire floor while genuinely struggling once forty or fifty devices are simultaneously trying to use it, because the access point's actual constraint is how many concurrent connections it can serve well, not how far its signal reaches.

Backup software is chosen almost entirely on how easy backing up looks in a demo, because that's the part vendors show. The feature that actually matters — restoration — is rarely demonstrated with the same enthusiasm, because restoration is where the genuine complexity and the genuine differentiation between products lives, and it's harder to make look impressive in a fifteen-minute sales call.

Micro-frontends split a single web application into independently deployable pieces, each owned and shipped by a different team, composed together at runtime into what the user experiences as one product. The pitch is compelling on paper — teams ship independently, on their own schedules, without coordinating a single monolithic frontend release — and it solves a genuinely real problem for organisations with several substantial teams working on one large product.

Utility-first CSS — applying many small, single-purpose classes directly in markup, as Tailwind popularised — lets a developer build a screen quickly without leaving the markup to write separate stylesheet rules, and once a team is fluent in the utility vocabulary, that speed advantage is real and consistent. The trade is that the markup itself becomes visually dense, and design intent lives implicitly in a long string of utility classes rather than in a named, readable component style.

Modern frontend development defaults to building the entire experience in JavaScript, which works well for the visitor whose connection is stable and whose script loads cleanly, and fails completely for the visitor whose doesn't — a poor mobile connection dropping mid-load, an aggressive corporate firewall stripping scripts, an ad blocker or privacy extension interfering more broadly than intended. For that visitor, a JavaScript-dependent site isn't degraded, it's blank.

Automated accessibility testing tools reliably catch a genuine but limited subset of accessibility issues — missing alt text, insufficient colour contrast, form inputs without labels, malformed heading hierarchy. Published figures generally put this at somewhere around a third of real-world issues, which sounds like a modest number until you consider what it actually buys: catching that third continuously, on every pull request, for close to no ongoing cost, rather than catching it once a year during an expensive manual audit.

Custom web fonts are a small file that most teams add without considering the loading behaviour they introduce by default. Left at browser defaults, text using a custom font is often invisible entirely until the font file finishes downloading — a behaviour called the flash of invisible text — which on a slow connection means a visitor stares at a blank area where text should be for a genuinely noticeable delay, even though the content itself was ready instantly.

A command-line tool built to automate an internal task gets used enthusiastically by the person who wrote it and largely ignored by everyone else on the team, and the reason is rarely that the underlying automation is wrong — it's that CLI usability has its own discipline, distinct from application development, and it's usually skipped when the tool was built quickly to solve one person's immediate problem.

For most teams building their first retrieval-augmented feature, pgvector — a vector extension on a Postgres database you likely already run — is the pragmatic starting point rather than a dedicated vector database. It avoids adding a new system to operate, keeps vector search alongside your existing relational data so queries can combine both naturally, and is genuinely adequate for embedding volumes many teams never actually exceed.

AI code review tools, run automatically on every pull request, reliably catch a specific and genuinely useful category of issue: obvious bugs, inconsistent patterns against the rest of the codebase, missing error handling, and style inconsistencies — largely the same territory static analysis and linting already cover, but explained in plain language rather than a terse rule violation, which makes the feedback more actionable for whoever's reading it.

When an AI system makes or influences a consequential decision — a credit decline, a content moderation action, a flagged transaction — someone will eventually ask why, and 'the model determined this' is not an answer that satisfies a customer, a regulator, or often the person's own manager. Building the capability to answer that question properly is a design requirement that has to be planned before the system ships, not retrofitted once the first dispute arrives and there's nothing to point to.

Accuracy percentages get reported as if they're the whole story, and the actual business cost of a wrong answer depends entirely on what happens next — a fact covered from the technical evaluation angle in the piece on evaluating an AI vendor's accuracy claims, and worth returning to specifically from the cost side, because the same accuracy figure can represent wildly different financial exposure depending on the use case.

A notification system that works perfectly in testing and silently fails for a third of users is one of the more demoralising bugs to chase. The usual cause is not your code. It is manufacturer-level battery management deciding your app should not run.

Teams treat application size as an engineering hygiene issue. In markets where storage is limited and data costs money, it is a business metric. A user who taps install and watches a progress bar crawl has a decision point that a smaller app never gave them.

If you build software for central or state government bodies or public sector undertakings, where it runs is a procurement question before it is an engineering one. The Ministry of Electronics and Information Technology operates an empanelment scheme, administered through the STQC directorate, that certifies which cloud providers may serve government customers. Most central and state cloud procurement defaults to empanelled providers, with narrow alternative paths for certain defence and intelligence workloads. Private sector buyers are free to use anyone.

The IRDAI issued its Information and Cyber Security Guidelines on 24 April 2023, and their scope is considerably wider than the word insurer suggests. They apply to regulated entities across the sector: insurers, brokers, foreign reinsurance businesses, corporate agents, web aggregators, third-party administrators, insurance marketing firms, insurance repositories, insurance self-network platforms, corporate surveyors, motor insurance service providers, common service centres and the Insurance Information Bureau of India. If you build software for any of those, your client is inside the perimeter and your product is part of how they comply.

Any Indian product that needs a legally binding signature — a loan agreement, a rental contract, an insurance proposal, an employment offer — eventually faces the same choice between two mechanisms, both recognised under the IT Act's Second Schedule, that behave completely differently in a user journey. Getting the choice right is largely about who is signing and how often.

Founders selling software in India routinely take a price that works in the US, convert it, apply a discount, and conclude that Indian buyers are unwilling to pay for software. The conclusion is wrong and the method is the reason. Indian buyers pay for software; they buy it on a different structure, with different expectations about what is included, and a converted-and-discounted foreign price satisfies none of them.

A large customer agrees to a pilot. Your team builds it, it works, the users are complimentary, the demonstration goes well — and then the conversation goes quiet and reappears six months later as a request for another pilot with a different department. This is the most common way enterprise deals fail, and it almost always traces back to what was agreed before the work started.

A company of twenty people has usually arrived there without ever deciding how its technology should work. Accounts were created as needed, access was granted by whoever asked, laptops were bought individually, and the shared drive grew organically. Nothing is broken, so nothing gets attention — until the first security questionnaire from a customer, or the first departure that turns awkward.

A proof of concept is commissioned to reduce uncertainty and usually reduces none, because it was scoped to demonstrate rather than to test. Someone builds a working example of the technology, everyone agrees it works, and the actual question — will this hold up in our environment, at our volume, against our data — remains exactly as open as it was. The difference between a useful proof of concept and a demonstration is that the useful one could fail.

Partner channels are attractive because they look like leverage: other companies selling your product to customers you could not reach. They frequently deliver nothing, and the failure is consistent enough to be predictable. A firm signs a run of partner agreements, celebrates the count, and discovers a year later that two partners produced everything and the rest produced a logo on a slide.

Bengaluru is the default answer for engineering in India and it is not always the right one. We are based here, so read this accordingly, but the honest position is that the city solves one specific problem — depth of senior people who have operated systems at scale — and charges a premium for it whether or not that is the problem you have.

The resignation you fear is the one from the person who understands the part of the system nobody else does. In India that arrives with a notice period — often thirty days, sometimes sixty or ninety — which is genuinely generous compared with many markets and is still less time than it feels like once you subtract handover of current work, leave they will take, and the disengagement that follows any resignation.

In 2023 the Central Consumer Protection Authority notified Guidelines for the Prevention and Regulation of Dark Patterns, naming thirteen specific interface behaviours as prohibited. The list is worth reading as a product document rather than a legal one, because most of the items are things a growth team has been asked to build at some point: false urgency, basket sneaking, confirm shaming, forced action, subscription trap, interface interference, bait and switch, drip pricing, disguised advertisements, nagging, trick question, SaaS billing, and rogue malware.

The Reserve Bank issued its Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices on 7 November 2023. It is the framework that sits above the more specific rules on digital lending and payment data, and it governs how a regulated financial entity organises technology as a whole. For a software firm, it matters because it determines who at your client can approve what, and how much evidence they need from you.

Indian product teams generally encounter accessibility for the first time in a foreign customer's procurement questionnaire, and conclude it is an export requirement. It is not only that. The Rights of Persons with Disabilities Act, 2016, administered by the Ministry of Social Justice and Empowerment, is a non-discrimination law that applies to both the public and private sectors, and its scope extends beyond web content to information and communication technology more broadly.

One day an email arrives from someone you have never heard of saying they found a security flaw in your product. What happens in the next few hours determines a great deal: whether you learn about your other flaws from researchers or from attackers, and whether this particular person works with you or writes it up publicly. Most companies handle this badly, and the worst version — responding with a legal threat — reliably converts a helpful stranger into a hostile one with an audience.

Every system fails eventually, and customers know that. What they judge you on is not whether you had an incident but what it was like to be your customer during one. The companies people stay with are the ones where, within a few minutes, there was somewhere to look that said yes, this is us, we know, here is what we are doing. The companies people leave are the ones where support said everything looks fine on our end while nothing worked.

Indian consumer businesses do not have a smooth annual curve. They have a handful of days — the festive sale window, a big cricket fixture, a payday, a campaign launch — where traffic is a multiple of normal and arrives in minutes rather than hours. That shape defeats the standard advice, because autoscaling responds to load that has already arrived, and by the time capacity appears the queue has built and the first thousand customers have seen an error page.

Ask any engineering team to list every third party that touches customer data and the first answer is usually three or four names. The real list is longer: the cloud provider, the error tracker, the analytics platform, the email service, the support desk, the session recording tool, the chat widget, the observability vendor, the payment gateway, the SMS provider, and whichever AI service somebody wired in last quarter. Every one of them is a subprocessor, and under the DPDP framework and any serious enterprise contract, their handling of the data is your accountability.

Moving from one cloud to another gets discussed as though it were the same exercise as migrating from a data centre, and it is not. The workloads are already containerised or virtualised, already defined in code, already operated by people who understand cloud. What makes it hard is different: the managed services you have built on do not have identical equivalents, the identity model is not portable, and the data has to physically move at a price the other provider sets and you do not.

Almost every Indian company's privacy policy was assembled from a template, and almost none of them accurately describe what the product does. They over-promise in some places and are silent in others, and both are problems now rather than merely untidy — under the DPDP framework, the notice you give is the basis on which you are permitted to process data, and a notice describing a different product does not authorise what you are actually doing.

Security awareness training exists in most organisations as an annual compliance exercise: a slide deck, a multiple-choice quiz, a completion certificate for the auditor. It reliably produces a hundred per cent completion rate and no measurable change in behaviour, because a person who watched a video in April is not more suspicious of an email in September. The exercise satisfies the requirement and misses the point.

Video-based Customer Identification Process began as a pandemic accommodation and has become the standard remote onboarding route for Indian financial institutions. It is not a video call with a screenshot. The RBI has progressively tightened what a compliant session must contain, and the requirements shape the architecture far more than the video streaming does.

Bharat Bill Payment System is the interoperable rail for recurring bill payments in India — electricity, gas, water, telecom, insurance premiums, loan instalments and a widening list beyond. For a product team it is attractive because it turns hundreds of separate biller integrations into one connection. The RBI issued revised directions governing it with effect from 1 April 2024, and understanding the role structure is the first step in deciding how, or whether, to participate.

A credit decisioning engine looks from the outside like a model that outputs a score. In practice the model is a modest component inside a system whose real requirements are explainability, auditability and the ability to change policy safely. Teams that build the model first and the surrounding machinery afterwards end up rebuilding, usually at the point where the business wants to change a rule and nobody can predict what will happen.

Fraud teams report what they prevented. What they rarely report, because it is invisible, is what they blocked that was legitimate — the customer whose card was declined, who tried once more, and then bought somewhere else. For most Indian merchants the cost of false positives exceeds the cost of the fraud, and a fraud system that is not measuring both numbers is optimising half the problem.

Voice is how a very large number of Indians prefer to interact with a service, particularly outside the metros, and it is where most product teams' assumptions break most completely. A speech system that performs well in a demonstration meets accented speech, background noise, code-switching mid-sentence and a call quality that varies by the second, and its accuracy falls off a cliff that no benchmark predicted.

A mid-sized Indian business choosing its first proper CRM or ERP is making a decision it will live with for five to ten years, usually on the basis of three demonstrations that all looked good. Demonstrations are designed to look good. What separates a system that gets adopted from one that gets abandoned alongside the old spreadsheets is a smaller set of questions, most of which are specific to operating here.

Most software businesses put their best people on sales and their least experienced on implementation, then are surprised when customers who signed enthusiastically do not renew. The pattern is consistent: the deal is won on a vision, handed to a team that was not in those conversations, and delivered as a configuration exercise. The customer gets working software and never gets the outcome they bought.

Bidding for large or public sector work is a different skill from selling, and Indian firms lose a great deal of winnable business to the mechanics of it rather than the substance. The single largest cause is disqualification on eligibility or documentation — a missing certificate, an unsigned page, a turnover threshold not evidenced, an earnest money deposit submitted incorrectly — which means the technical proposal that took three weeks was never read.

Last-mile logistics software built on assumptions that hold in Europe or North America performs badly in India, and the reasons are not about algorithm quality. They are about the inputs: addresses that do not geocode, roads that are not passable at the width the map assumes, recipients who are not where the address says, and a delivery model where cash frequently changes hands at the door.

Any product that moves money ends up with three or more records of the same event: your database, the payment provider's record, and the bank statement. Those three will disagree. Not occasionally — routinely, for entirely ordinary reasons, including timing differences at day boundaries, refunds processed asynchronously, chargebacks, provider fees netted from settlements, and transactions that succeeded on one side and timed out on the other. Reconciliation is the system that explains the differences, and in most companies it is not a system at all. It is a person with a spreadsheet.

The Invoice Management System went live on the GST portal from 1 October, and it changed the shape of input tax credit reconciliation from a reporting exercise into a workflow. Every outward supply your suppliers report in GSTR-1, IFF or GSTR-1A now appears on your IMS dashboard for you to act on. Inward reverse charge supplies and transactions ineligible for input tax credit bypass IMS entirely and flow straight to GSTR-3B.

India has four credit information companies operating under the Credit Information Companies (Regulation) Act, 2005 and regulated by the RBI: TransUnion CIBIL, Equifax India, Experian India and CRIF High Mark. Any lending product integrates with at least one, and understanding that they are not interchangeable is the starting point — each holds what its member institutions reported to it, so the same borrower can look materially different depending on which you query.

Payroll looks like arithmetic and is really a compliance system with an arithmetic component. In India a single monthly run touches provident fund, employees' state insurance, professional tax, income tax deduction at source, labour welfare fund in some states, and gratuity provisioning — each with its own thresholds, its own filing, and in several cases its own state-level variation. Software that computes a net figure correctly and cannot produce the returns has solved the easy half.

Distribution decisions for an Indian consumer app are made under constraints that Western product teams rarely face. A large share of your target users hold devices with limited storage that is already close to full, on data plans they are conscious of, and they uninstall applications routinely to make room. That reality should shape the build long before it shapes the marketing.

Every product has an internal side — the screens support, operations and finance use to answer questions, fix mistakes and unblock customers. It is almost never designed, rarely reviewed, and frequently consists of whatever a developer built quickly two years ago plus direct database access for the things it cannot do. It is also the interface through which your customers' problems actually get resolved, which makes its quality a customer-facing concern wearing an internal disguise.

Subscription businesses discuss churn constantly and define it loosely, which is why so much effort aimed at it achieves nothing. Before any intervention, three distinctions have to exist in your data: customers who chose to leave, customers whose payment failed, and customers who downgraded but stayed. They have completely different causes and completely different remedies, and a single churn percentage hides all of it.

Most products accumulate notification channels rather than designing them. Email came first, SMS was added for OTPs, push arrived with the mobile app, and WhatsApp was bolted on because that is where Indian customers reply. Each was built by whoever needed it, with its own templates, its own sending code and its own idea of when to send. The customer experiences the result as noise, and the business cannot answer basic questions like how many messages we send a person per week.

Quality assurance in Indian software teams is frequently organised as a stage: developers finish, testers verify, defects come back. It is a familiar arrangement and it produces predictable pathologies — defects found at the most expensive moment, an adversarial relationship between two groups who need each other, and a testing phase that gets compressed whenever the schedule slips, which is exactly when it is most needed.

A marketplace is the most attractive business model to describe and the hardest to start, because on day one it is worth nothing to either side. Buyers arrive, find nothing, and leave. Sellers list, sell nothing, and stop. The engineering is largely a solved problem — catalogue, search, orders, payments, ratings — and building it well does nothing whatsoever to solve the actual problem, which is that an empty market has no value.

Every organisation eventually faces a renewal with a supplier it depends on and is not entirely happy with — a platform embedded in operations, a development partner who holds the knowledge, a system nobody wants to migrate. The renewal conversation goes badly for buyers who approach it as a complaint, because dissatisfaction is not leverage. What determines the outcome is whether you could realistically leave, and how confident the vendor is in their answer to that question.

Every Indian company exporting software or IT-enabled services carries an obligation most engineers have never heard of and most founders regard as the accountant's problem. Export declarations must be filed, and export proceeds must be realised within a stated window, or the tax treatment of invoices you have already booked as zero-rated changes. Two significant things have happened to that regime, and one of them takes effect in six weeks.

Services firms grow by getting good at serving somebody, and the natural consequence is that one relationship becomes very large. It rarely feels like a risk while it is happening — the work is good, the client is happy, and turning down more of it to protect a ratio feels like an absurd reason to refuse revenue. The risk becomes visible at exactly the moment it is least manageable.

Open sourcing an internal library is proposed for good reasons — engineering reputation, recruiting, giving something back, and occasionally a strategic wish to make a format or a protocol standard. All of those are real. What gets underestimated is that publishing code is the beginning of an obligation rather than the completion of a task, and a repository that goes quiet after four months does more reputational harm than never having published.

Teams build component libraries and call them design systems. The library is the visible part — buttons, inputs, modals, tables — and it is the smaller half. A design system is the set of decisions that make those components consistent: the spacing scale, the type scale, the colour roles, the interaction patterns, and the rules about which component to use for which job. Without those, you have a folder of components that will diverge, because every new screen requires a fresh judgement.

Engineering-led companies typically hire their first designer late, and hire them for the wrong job. The brief is usually to make the product look better, which treats design as decoration applied at the end. What a good designer actually changes is what gets built — which problems are worth solving, what the flow should be, and which of the four features someone requested was the real need. Hired as a decorator, they will decorate, and the company will conclude that design is a nice-to-have.

Every project overruns and the usual explanation is scope creep, framed as a client failing to stick to what they agreed. That framing is comfortable for suppliers and mostly wrong. Requirements change because building software teaches everyone things they did not know at the start — including the client, who could not have described the right thing before seeing the wrong one. A process that treats learning as misbehaviour is fighting the nature of the work.

The first data hire in most companies is a data scientist, because that is the title everyone has heard of, and it is usually the wrong one. A data scientist joining a company with no reliable data infrastructure spends their first year cleaning exports, writing queries for other people, and rebuilding the same dashboard — work they are overqualified for and did not join to do. They leave within eighteen months and the company concludes that data was oversold.

Insurance is the least interesting item in a software firm's operations and it appears in almost every enterprise contract. Buyers require suppliers to carry specified cover at specified limits, and the requirement is easy to agree to and awkward to discover you do not meet — typically at the point of signature, when the deal is waiting and the policy takes weeks to arrange.

The first hours of a security incident are the ones that determine everything afterwards, and they are the hours in which organisations behave worst — because nobody has decided in advance who does what, and the people who could decide are asleep or in a meeting. Writing this down on a calm day is the entire preparation, and almost nobody does it.

Every piece of software you publish carries a licence, including when you do not choose one — code published with no licence is, in most jurisdictions, all rights reserved, meaning nobody may legally use it. That is rarely the intent, and it is the commonest licensing mistake: a repository made public with the assumption that public means usable, which it does not.

The Indian software services market has thousands of genuine firms and a meaningful number whose websites are considerably more impressive than their capabilities. Photographs of a leadership team who do not exist, client logos never worked with, certifications never held, and case studies describing projects that did not happen — all of it is easy to produce and none of it is verified by anyone. Before paying a deposit to a firm you found online, four checks are worth twenty minutes.

The software is delivered, everyone is pleased, and a maintenance agreement is signed with little attention because the interesting part is over. It is the document that governs the next several years of the relationship, and it is usually two pages saying the supplier will provide support and fix defects. Both of those terms need defining or the first disagreement will be about what was promised.

A large share of Indian business websites run on WordPress, and a large share of those get compromised at some point — usually turned into a host for spam pages, a redirect to somewhere else, or a crypto miner. The owner discovers it when Google flags the site or a customer mentions it. Almost none of these compromises exploit WordPress core, which is maintained carefully; they come through plugins, themes and credentials.

Any software that files returns, generates e-invoices or produces e-way bills on behalf of Indian businesses has to connect to government systems, and there are two routes. A GST Suvidha Provider is an authorised intermediary that holds the connection and exposes a friendlier interface to you. Alternatively, larger taxpayers can obtain direct API access. Most product companies use a GSP, and understanding why is worth ten minutes before the architecture is decided.

ERP replacement is rarely triggered by a failure. The system still runs, still produces invoices, still closes the month. What has happened instead is that the organisation has quietly built a layer of human effort around it, and the cost of that layer has grown past the cost of replacing the software — but because it is distributed across people's ordinary work, nobody adds it up.

A business builds a website, waits, searches for itself and finds nothing. The usual conclusion is that it needs SEO, and money gets spent on content and links. Frequently the actual cause is that Google has not indexed the site at all, and no amount of content fixes that. There are four things to check first, and each takes minutes.

The rule is short and absolute. From 1 October 2022, no entity in the card payment chain other than card issuers and card networks may store card-on-file data. That covers merchants, payment aggregators, gateways and anyone else in the flow. If your product holds a card number to make the next purchase easier, it is not a convenience feature — it is non-compliant, and it is a category of finding that ends conversations with any regulated partner.

An Aadhaar Data Vault is centralised, restricted-access storage for every Aadhaar number an entity has collected, held inside its own secure infrastructure. The requirement originated in UIDAI circular 11020-205/2017 of 25 July 2017, was revised by Circular No. 8 of 2025 on 18 July 2025, and the accompanying FAQs were updated on 3 November 2025. If you build for anyone handling Aadhaar, the 2025 revision is the version to work from.

India's four labour codes came into force on 21 November 2025: the Code on Wages 2019, the Code on Social Security 2020, the Industrial Relations Code 2020, and the Occupational Safety, Health and Working Conditions Code 2020. They consolidate a large body of older legislation, and two of the changes go directly at logic embedded in nearly every Indian payroll system.

A large Indian bank, insurer, manufacturer or government body eventually asks whether your SaaS product can run inside their data centre. Refusing loses a deal that may be worth more than your entire self-serve business. Agreeing casually is worse, because a single-tenant deployment inside somebody else's infrastructure changes your engineering, your support model and your release cadence, and companies that discover this after signing spend two years paying for the discovery.

Selling software to an Indian bank, NBFC or insurer is not a sales process in the ordinary sense — it is an onboarding process that a sales conversation eventually triggers. Regulated entities are required to conduct due diligence on their technology suppliers, and that requirement flows down to you as a document pack, an audit, and a set of contractual terms that are largely non-negotiable. Firms that treat this as paperwork to handle after the deal is agreed lose quarters to it.

Every engineering organisation past a certain size is asked to demonstrate that it is improving, and most answer with velocity — a count of story points completed per sprint. It is the wrong number for a simple reason: it measures how the team estimates, not what it delivers, and it can be improved by estimating more generously. Any metric a team can move without changing the outcome will be moved.

A product that supports Indian languages usually means one that displays them. Searching and sorting them is a different problem, and it is where the support turns out to be superficial. The assumptions baked into most databases and search libraries — that sorting is byte order, that a word is a sequence of letters separated by spaces, that users type in the script the content is stored in — hold poorly for Indic text.

Product decisions in Indian software are made on the assumption of a smartphone with a data connection, and for a great many use cases that assumption is fine. For others — agricultural supply chains, rural financial services, blue-collar workforce management, government schemes — a significant portion of the people the product exists to serve either do not have a smartphone, share one within a household, or have one they cannot reliably keep charged and connected. Designing only for the app excludes them entirely.

Cloud cost is treated as something you find out rather than something you decide. A system is designed, built, deployed, and the bill arrives with a number nobody predicted. That is avoidable — not to the rupee, but to the order of magnitude, which is the part that matters. And the exercise is worth doing before building rather than after, because the estimate frequently changes the architecture.

Sooner or later a larger company proposes selling your product as theirs. For a small software business that is genuinely attractive — distribution you could not buy, a customer base you could not reach, and revenue without a sales team. It is also a structural decision rather than a cosmetic one, and the version that goes badly is the one agreed as though it were a branding exercise.

The Legal Metrology (Packaged Commodities) Amendment Rules, 2026 were notified on 13 February 2026 and took effect on 1 July 2026. They insert Rule 6(10A), which requires e-commerce entities to display imported products through a searchable filter and to provide a sortable filter based on country of origin. If you run or build an Indian e-commerce platform and that filter does not exist, the compliance date has passed and this is a remediation item rather than something to schedule.

The Telecommunications (Telecom Cyber Security) Rules, 2024 were notified on 21 November 2024 and apply to telecommunication entities broadly — service providers, network operators, equipment manufacturers and importers. For a software firm the relevance is indirect but real: if your client is any of those, these rules shape what they can accept from a supplier and what they will require of you.

Cloud is the default and colocation is treated as something companies are migrating away from. For a subset of Indian businesses that framing is wrong, and the subset is larger than the cloud conversation suggests. A workload that runs at a steady, predictable level, twenty-four hours a day, with substantial storage and heavy data transfer, is close to the worst case for cloud pricing and close to the best case for owning hardware in somebody else's data centre.

Two versions of this request arrive and they are frequently confused. An individual exercising a right under the DPDP framework or GDPR asks for the personal data you hold about them. An enterprise customer leaving, or preparing to, asks for the data their organisation put into your product. Both are obligations, they have different scopes and formats, and a product that handles one badly usually handles both badly.

Companies open an API because a customer asked, and then discover they have taken on obligations nobody scoped. External integrators write code against it and that code runs in their production. From the moment the first one goes live, your ability to change the interface is constrained by people you cannot deploy for, and that is the defining property of an API as a product rather than as a feature.

Small engineering teams avoid career frameworks because they feel like corporate machinery for a company of twelve. The consequence is not the absence of a ladder but an invisible one: titles awarded to whoever raised it, salaries set by who negotiated hardest, and promotion decisions defended after the fact. In the Indian market, where people move for a title as readily as for money, that invisibility is a retention problem rather than an administrative one.

Organisations institute architecture review to stop expensive mistakes and frequently get a ceremony instead. An engineer presents a diagram, senior people ask a few questions, approval is granted, and nobody's decision changed. The cost is real — the delay, the preparation, the meeting — and the benefit is close to zero, because a design cannot be meaningfully assessed by people encountering it for the first time in a room.

Almost every Indian software services firm describes itself the same way: custom development, cloud, AI, mobile, data, security, across every industry. The reason is understandable — turning away work is painful and the pipeline is uncertain. The consequence is that a buyer comparing three firms sees three identical capability lists and is left with price as the only differentiator, which is the competition nobody wins.

A software company with an Indian product eventually faces a choice it often makes by accident: whether it is selling to small and mid-sized businesses or to enterprises. They are not two segments of one market. They buy differently, pay differently, expect different support, and require a different company shape. Serving both from one set of processes produces a product too heavy for the small buyer and too light for the large one.

Field service software — for installation, maintenance, inspection, surveying, collections — is built by people sitting at desks with good connectivity, for people standing in a factory, a basement, a rooftop or a village with one bar of signal. The gap between those two situations produces a consistent set of failures, and most of them are foreseeable rather than surprising.

The Telemedicine Practice Guidelines, issued in 2020 by the Ministry of Health and Family Welfare, are the legal basis on which registered medical practitioners may consult patients remotely in India. Only physicians registered with the National Medical Commission or a State Medical Council may practise under them, which means the first thing a platform must do is verify registration rather than accept a claimed qualification.

An Indian company exporting software chooses between three structures, and most choose by default rather than by analysis. A Special Economic Zone unit sits inside a notified enclave with fiscal incentives. An STPI unit operates under the Software Technology Parks scheme, which is not location-restricted. A non-STPI or Domestic Tariff Area entity operates under ordinary tax and compliance rules with no special incentives. The differences are large enough to be worth an afternoon before incorporating anything.

Section 43B(h) of the Income Tax Act took effect from 1 April 2024, applicable from assessment year 2024-25, and it changed the economics of late payment in India. Where a buyer pays a micro or small enterprise beyond the statutory time limit, the deduction for that expense is allowed only in the year the payment is actually made — not the year the service was delivered. For a buyer with a March year end, paying an invoice late moves the deduction into the next financial year and increases this year's taxable profit.

Indian payment gateways are broadly reliable and they are not perfectly reliable, and the failures cluster in the worst possible places: during a festive sale, at the end of the month, on the day a campaign lands. A business whose checkout can only route through one provider has accepted that its revenue stops when that provider has a problem. For anything past a modest volume, a second gateway is not sophistication, it is ordinary continuity planning.

Switching payment provider is usually motivated by rates, reliability or a feature the incumbent lacks, and it is scoped as an integration project. The integration is the straightforward part. What makes these migrations difficult is everything that already exists at the old provider — tokenised cards, active recurring mandates, in-flight disputes and settlement history — none of which transfers automatically.

Payment flows get attention because revenue depends on them. Refunds get a button and a hope. The result in most Indian products is that a refund is initiated, the customer sees nothing for several days, contacts support twice, and support cannot say where the money is — because the system recorded that a refund was requested and nothing about what happened next.

Referral bonuses, first-order discounts, cashback and affiliate commissions are among the most effective growth levers available in the Indian market, and among the most reliably exploited. Within weeks of launch, coordinated groups will be extracting value at a scale the launching team did not model — and because this is classified as growth spend rather than fraud, it frequently runs for months before anyone measures it properly.

Business continuity discussions in software companies concentrate on infrastructure — multi-zone deployment, backups, failover. Those matter and they are not what stops an Indian services firm working. What stops it is a flooded arterial road during monsoon, a building-wide power failure with a generator that was never load-tested, a fibre cut affecting the office park, or a civic disruption that makes commuting unsafe for a day.

In a services firm, people are the cost and billable time is the revenue, so the gap between them — engineers on the bench, waiting for the next project — is where margin goes. It is also poorly measured in most Indian firms, because utilisation is reported as an average across the company, which conceals both the person who has been unassigned for six weeks and the team working unsustainable hours on a late delivery.

Fixed price is what most Indian buyers want, and for a supplier it is a bet on your own estimate. The bet is winnable on well-defined work and close to unwinnable on vague work, and the commonest cause of an unprofitable services project is a fixed price quoted against a brief that could be interpreted three ways. The discipline is not better estimating; it is declining to quote fixed price on work that is not fixed.

Services firms subcontract for good reasons — a specialisation they lack, a capacity spike, a geography they cannot cover. It is normal and it is manageable. What causes trouble is that the client's contract is with you, so the subcontractor's quality, security posture, confidentiality and delivery are all your liability, while their work is the part of the project you have least visibility of.

Every product past a certain age has a bug backlog too large to read. Nobody planned it: bugs were reported, triaged as low priority, and left. The list grows monotonically because nothing removes items except fixing them, and the low-priority ones are never the most valuable work available. Eventually the backlog is a place where reports go to be forgotten, and the team knows it, which changes how they treat new reports.

Companies build a help centre by documenting the product feature by feature, publishing it, and observing that ticket volume does not fall. The reason is that the documentation is organised the way the product is built, and users arrive with a problem described in their own words. A section titled Account Settings does not answer why can't I log in, and a user who fails to find an answer in ninety seconds contacts support and never returns to the help centre.

A client escalation that reaches the head of the company almost never arrives because a technical issue was unusually hard. It arrives because the client stopped believing that the people they were dealing with had it under control. That belief is lost gradually — a missed update, a date that moved without explanation, an answer that turned out to be optimistic — and the escalation is the moment the accumulated doubt becomes an action.

Some Indian deployments — defence, certain government systems, parts of critical infrastructure, occasionally a bank's most sensitive environment — run on networks with no route to the internet. Delivering software into one is a different discipline from ordinary on-premise work, and the difficulty is not security engineering. It is that every convenience your build and runtime quietly depend on has to be identified and removed.

Requests for security investment fail in a predictable way. Engineering describes risk qualitatively, leadership hears a preference competing against customer features, and the features win. The problem is not that leadership is careless; it is that one side is describing a possibility and the other is allocating money, and possibilities do not compete well against roadmap items. The fix is to model one specific incident properly.

Projects that disappoint rarely fail in the build. They fail at the seam between the people who sold the work and the people who do it. The deal was won on a series of conversations, a demonstration, and a set of impressions the client formed about what they were buying. What crosses to delivery is a signed scope document, which contains a fraction of that and none of the impressions.

The Information Technology Act defines an intermediary very broadly: any person who receives, stores, transmits or provides a service in respect of an electronic record on behalf of another person. That covers web hosts, internet service providers, search engines, e-commerce platforms and social media, and it catches a great many products whose founders have never thought of themselves as intermediaries — anything with user-generated content, reviews, listings, comments or file sharing.

The first product manager in a small company is usually hired because engineering is asking what to build next and the founder has run out of hours to answer. That framing produces a coordinator: someone who writes tickets, chases updates and runs standups. It is a real job and it is not what a product manager is for, and hiring at product manager salary for it is expensive administration.

User research in India runs into a cultural pattern that quietly invalidates a great deal of it: participants are reluctant to criticise something to the face of the person who made it, particularly across a status gap. Ask an Indian user whether they liked your product and you will frequently be told yes, sincerely and warmly, by someone who will never open it again. Research that does not account for this produces confident, wrong conclusions.

Companies attack churn with retention campaigns aimed at customers who are already leaving, which is the most expensive point of intervention available. The decision was mostly made in the first session. A user who reached the thing your product does well, and did it, behaves completely differently from one who signed up, looked around, and closed the tab — and the difference persists for the life of the account.

A company rebuilds its product, ships something genuinely better, and receives complaints. This surprises teams every time and it should not. Existing users did not experience the old product's flaws the way you did — they learned around them, built habits, and became fast. What you shipped removes their expertise and asks them to be beginners again, and the improvement has to be large enough to pay for that.

Discontinuing a product is a normal commercial decision and it is handled badly often enough that doing it well is a differentiator. Customers who built a process on your software are being told to stop, and how you manage that is observed by everyone else you sell to. A company that ends a product carelessly has told its remaining customers something about what happens if their product becomes unprofitable.

Split testing is treated as the mature way to make product decisions, and for a consumer product with substantial traffic it is. For a B2B product with four hundred accounts, or a young marketplace with a few thousand monthly users, the arithmetic does not work: detecting a realistic improvement requires far more observations than you will collect in a reasonable period, and a test stopped early because the numbers looked good is not evidence of anything.

Any Indian platform carrying user content — reviews, listings, comments, profiles, uploads — needs a moderation capability, and the requirement is set partly by law and partly by what your users will tolerate. The legal floor comes from the IT Rules: acknowledge a grievance within twenty-four hours, resolve within fifteen days, act on a court order or government notification within thirty-six hours, and within twenty-four for the most serious categories. Missing those puts your safe harbour at risk.

An enterprise buyer researching a supplier does something specific and predictable, and most Indian software websites are not built for it. They are not persuaded by the value proposition on the homepage. They are establishing whether you are real, whether you are competent, and whether the procurement process is going to be painful — and they form that judgement in about ten minutes across four or five pages.

Companies build dashboards by adding every metric anyone asks for, and end up with a screen that describes the business comprehensively and changes no decision. The problem is not measurement, it is that a metric only matters if there is an action attached to it moving. Forty numbers cannot each have an owner and a response, so none of them do.

Engineering teams in young companies frequently work under a founder whose direction changes often. Some of that is correct — a founder who never changes course in response to evidence is a worse problem — and some of it is the avoidance that comes from a hard problem being replaced by a fresh one. From inside the team the two are indistinguishable, and the indistinguishability is what destroys morale.

Hiring across Indian cities rather than within one removes the constraint that determines most engineering hiring here: whether a good candidate is willing to commute to your office. The pool becomes national, salaries outside the metros are lower, and attrition is often lower too. What it costs is everything that was previously handled implicitly by proximity, and the companies that struggle are the ones that did not replace those things deliberately.

A client asks for AI in their product. Sometimes the requirement is real and well-formed. Frequently the request is a board expectation, a competitor's announcement, or a genuine problem described in the vocabulary currently available. Building what was asked for, without establishing which of those it is, produces a feature that demonstrates well and changes nothing — and the client concludes that AI did not work for them.

Every engineering team eventually proposes building something it could buy — a deployment tool, a monitoring layer, an internal wiki, a ticketing system, a feature flag service. The arguments are consistent and often sincere: the commercial option is expensive, it does not fit our workflow, and we could build a simpler version in two weeks. The two weeks is the part that is almost never true.

A customer advisory board is a small group of customers who meet periodically to discuss where your product should go. Done casually, it becomes a session where you present the roadmap and customers nod, which produces a pleasant meeting and no information. Done deliberately, it is the cheapest access to informed judgement about your market that exists.

Beta programmes are usually run to find bugs before launch and to generate a feeling of momentum. Both are fine and neither is the valuable outcome. The valuable outcome is discovering whether people will actually use the thing, repeatedly, when it is not new — and a beta designed for coverage rather than for depth cannot answer that.

A competitor drops their price, your sales team starts losing deals on cost, and the pressure to respond is immediate. In Indian software and services this happens constantly, because the market has a wide range of firms with different cost bases and different definitions of an acceptable margin. Matching is the instinctive response and it is usually a decision to compete on the one dimension where you cannot win permanently.

Small companies say yes reflexively, particularly in a competitive market, and particularly to large customers. It feels like service and it is frequently the opposite: a yes to something you cannot do well produces a late delivery, a compromised product, or a feature nobody else wants that you maintain forever. The disappointment is deferred rather than avoided, and it arrives after the money has been spent.

At some point in an enterprise sale, the buyer brings an architect or a security lead into the room. Their job is to establish whether the capability described in the proposal exists. The supplier's instinct is to send whoever presents best, and the better instinct is to send the person who would actually do the work — because the buyer's technical person can tell the difference within a few questions, and the discovery that they were being managed is worse than any weakness they might have found.

Founders resist choosing a segment because the Indian market is enormous and narrowing feels like discarding opportunity. The effect is the opposite. A product described for all businesses has to be described generically, which means no particular buyer recognises their own problem in it, which means each sale is a fresh act of persuasion. A product for a specific kind of buyer sells itself partway before anyone speaks.

Any e-commerce food business operator in India must hold a valid FSSAI licence or registration, and cannot trade on any platform without it. For a platform that is a two-sided obligation: your own status, and verification that every seller listing food holds theirs. Collecting a licence number at onboarding, validating it, and tracking its expiry is the minimum, and platforms that treat it as a free-text field discover the gap when a regulator asks.

An Indian business needing software has three routes and usually compares them on hourly rate, which is the least informative axis available. A freelancer, an agency and an in-house team are not the same thing at different prices — they carry different risk, different continuity and different amounts of work that you have to do yourself. Knowing which of those matters most to you decides it more cleanly than any quote.

A business with a problem asks whether to buy software or have it built. Custom development firms have an obvious incentive in answering that, so treat what follows accordingly — but the honest position is that a large share of the enquiries we receive describe problems a configured product solves better and cheaper. Recommending against a build is occasionally the right recommendation, and firms that never do it are not giving advice.

Businesses commission a technical audit for a small number of recurring reasons: changes have become slow and expensive and nobody can say why, the vendor who built it is unresponsive or gone, an investor or buyer has asked questions, or something broke badly enough to prompt the question of what else might. All four are legitimate, and what the audit should produce differs depending on which one you have.

Digital transformation is sold as a programme and bought as an aspiration, which is why so many of these initiatives produce a strategy document, a pilot, and no change to how the business operates. The phrase has no fixed meaning, so the first useful step is to refuse it and ask what specifically is supposed to be different in eighteen months.

IT budgeting in mid-sized Indian companies is frequently done by taking last year's spend and adding a percentage. It produces a number that is approximately right and is wrong in the specific places that matter, because IT cost does not grow smoothly — it steps, when a licence tier is crossed, when a contract renews at a new rate, when hardware reaches end of support, or when headcount pushes you into a different pricing band.

Software subscriptions are bought by individuals to solve immediate problems and are almost never cancelled. A tool adopted for a project that ended. Seats for people who have left. Two products doing the same job because two teams chose separately. A plan upgraded during a busy quarter and never downgraded. Each was reasonable, none is reviewed, and collectively they are usually a meaningful share of a company's software spend.

All the major cloud providers now offer ARM-based instances alongside x86, priced lower for comparable specifications. For workloads that run well on them, the saving is straightforward and permanent. The question is whether yours does.

Cloud providers offer substantial discounts in exchange for committing to a level of usage over one or three years. The discount is real and the trap is equally real: a commitment made on optimistic growth assumptions becomes a bill for capacity you are not using.

ITIL 4 arrives as a large book of practices, and the instinct of a newly appointed IT manager is to implement all of it, because that is what the certification implied was correct. Six months later most of the documentation is unused, the process nobody asked for is being worked around, and the framework has acquired a reputation inside the company as bureaucracy rather than discipline.

Ask an IT team what the oldest running server is and the answer is often a file transfer host. It exchanges data with banks, logistics partners, payroll providers. Its credentials predate the current staff. Its logs, if any, go back a week.

Onboarding flows that ask users to photograph a document create work on both sides. The user finds a document and takes a picture in poor light; someone or something at your end tries to read it and decide whether it is genuine. Neither step is reliable.

Most CMDB projects begin with an enthusiastic discovery exercise, a populated database, and a demonstration to leadership showing every server, application and dependency mapped cleanly. Eighteen months later the database describes an estate that no longer exists, because servers were decommissioned without anyone updating the record, and a new application was deployed by a team that had never heard of the CMDB.

UPI began as an account-to-account rail, and a great deal of merchant software was written assuming that. The extension of UPI to credit — RuPay credit cards and pre-sanctioned credit lines linked to a UPI handle — changes some of those assumptions in ways that surface at reconciliation time rather than at checkout.

Input tax credit depends on your suppliers doing their part. If a supplier has not reported an invoice, the credit does not appear in your auto-populated statement, and claiming it anyway creates an exposure. Finding the gaps is a matching exercise across two datasets that rarely agree on formatting.

Most buyers assume fixed-price is the safe option and time-and-materials is the one where a vendor runs up the meter. That instinct is understandable and it is usually wrong. Both models are legitimate; the failures come from applying one to work that has the shape of the other. It is worth understanding what each actually does before you decide which to insist on.

Every IT and software service supplied in India carries GST at 18%. There is no concessional rate for the sector and no composition scheme, whatever a consultant tells you. Custom development, SaaS subscriptions, AMC contracts, consulting and support all sit at the same rate, classified under SAC codes in the 9983 family — 998314 for software development and SaaS platforms, 998313 for IT consulting and support, 998315 for hosting and cloud infrastructure. If your turnover crosses five crore rupees you must use the full six-digit code on every invoice, and it is worth doing from the start regardless.

On 6 April 2018 the Reserve Bank of India issued a circular requiring every payment system operator to store payment system data within India. It is a short document and it has not changed much since, which is precisely why teams skim it, assume they understand it, and then discover during an audit that a logging pipeline or an analytics tool has been quietly shipping regulated data to another continent for three years.

CERT-In Direction No. 20(3)/2022, issued on 28 April 2022 and effective sixty days later, requires organisations to report specified cyber incidents within six hours of noticing them, or of being made aware of them. Six hours is the number everyone remembers and almost nobody has planned for. It is shorter than a working day, shorter than most escalation chains, and considerably shorter than the time an engineering team typically spends establishing whether something is an incident at all.

A surprising number of Indian software products drift into being payment aggregators without anyone deciding to. If your platform collects money from a customer and later passes it to a merchant — a marketplace, a booking product, a services platform taking payment on behalf of providers — you are handling funds that are not yours, and the Reserve Bank has a specific view about who is allowed to do that. The framework began with the PA-PG guidelines of 17 March 2020 and was expanded in November 2024 to bring offline payment aggregators and cross-border aggregators inside the perimeter.

Indian software companies tend to read the EU AI Act as somebody else's regulation. It is not. Like the GDPR before it, the Act reaches providers outside the Union when the system or its output is used within it. A Bengaluru firm shipping an AI feature inside a product sold to European customers is a provider under the Act, and the fact that no part of the company is in Europe changes nothing about that.

E-invoicing under GST is mandatory for businesses with aggregate annual turnover above five crore rupees. It applies to business-to-business transactions and exports. Banking, insurance, NBFCs, goods transport agencies, passenger transport and multiplexes are exempt, as are business-to-consumer sales. If you build billing software, an ERP, or any product that issues invoices on behalf of Indian businesses, this is not an optional module — it determines whether your customer's invoices are legally valid.

The question is usually framed as which standard is stronger. That is the wrong frame. Both exist to give a buyer confidence that you manage information security deliberately, and the honest deciding factor is which document your prospective customers ask for in procurement. That is largely geographic. ISO 27001 is accepted in more than 160 countries and is the default expectation across Europe, APAC, the Middle East and Latin America. SOC 2 is primarily a North American expectation, with growing recognition in the UK, Australia and Israel.

At some point a deal you thought was closing produces a spreadsheet with several hundred rows, sent by a security team you have not met, with a response deadline that assumes you have done this before. The questions cover encryption, access control, incident response, subprocessors, business continuity, secure development, physical security and a dozen other areas, and roughly a third of them do not apply to your product at all.

The most common misconception in outsourced development is that signing a non-disclosure agreement settles the intellectual property question. It does not. An NDA governs what each side may reveal about the other. Ownership of what gets built is a separate matter, requiring an explicit assignment, and a contract can be entirely silent on it while looking thorough. If your agreement does not contain the words assigning ownership of deliverables to you, the default position may not be what you assume.

A large customer buying critical software from a smaller vendor eventually asks what happens if that vendor disappears. Source code escrow is the traditional answer: the source is deposited with a neutral third party and released to the customer on defined trigger events — insolvency, cessation of business, or persistent failure to meet support obligations. As a way of making a procurement committee comfortable, it works. As a way of actually recovering a system, it usually does not, and it is worth understanding why before either side signs.

A takeover starts from an unusual position: the client is unhappy, often with reason, and is inclined to describe the incumbent's work as worse than it is. Believing that description uncritically is the first mistake, because it leads to promising a rewrite that is neither necessary nor affordable. The second mistake is the opposite — assuming the code is fine and the problem was purely relationship management. Both errors come from the same source, which is starting work before completing an inventory.

Staff augmentation places engineers under your management. You set priorities, run standups, review their work and own the result. A managed team is different: the vendor owns delivery of an agreed outcome, brings its own lead, and is accountable for how the work gets done. Both are legitimate. The failure mode is buying one and expecting the other, which happens often enough to be the default outcome when nobody names it explicitly.

A cloud bill is not a list of what you use. It is a list of what you are charged for, organised for billing rather than for understanding, and the gap between those two things is where the money goes. Teams that set out to reduce spend usually start with instance sizes, because that is the line item they recognise. It is rarely where the surplus is.

The first thing to understand about UPI is that you almost certainly cannot participate in it directly. NPCI owns and operates the network, approves every participant and audits its members. Banks connect as Payment Service Providers — they register users, link accounts to UPI identifiers and authenticate customers. An application company sits a level below that, as a Third Party Application Provider, and a TPAP is explicitly a service provider to a PSP rather than an independent member. It participates in UPI through the PSP bank, not alongside it.

India's Account Aggregator framework moves financial data between institutions with the customer's explicit consent, and it has quietly become usable infrastructure rather than a pilot. As of early 2026 there were seventeen licensed Account Aggregators, thirteen of them with live integrations, and more than 135 financial information providers on the network: 72 banks spanning private, public, small finance, regional rural, foreign and cooperative institutions, 57 insurers, both depositories, the two major registrars, three NPS record keepers, six NBFCs, forty asset management companies via the RTAs, GSTN and CCIL.

The most useful sentence anyone can hear about ONDC is that it is a protocol rather than a platform. Selling on Amazon means joining somebody's marketplace and accepting its rules. ONDC instead standardises how buyer-facing and seller-facing software talk to each other, so that independent applications can interoperate without any of them owning the network. Every design decision in the integration follows from that, and teams that approach it as another sales channel to plug in tend to underestimate it.

WhatsApp is where Indian customers actually reply, which is why almost every consumer product here eventually builds on the WhatsApp Business Platform. The economics changed materially on 1 July 2025, when Meta moved from conversation-based pricing to per-message billing. Anything designed or costed against the old model needs revisiting, because the levers that reduce spend are now completely different ones.

A product built in Bengaluru is usually built on a fast, stable connection, by engineers with current hardware, in a room where the network never wavers. The people who determine whether it grows are frequently on an intermittent mobile connection, on a device several generations old, with limited storage and an operating system that aggressively kills background processes. The gap between those two experiences is where most Indian consumer products quietly lose their users, and it does not show up in any dashboard that measures averages.

A business that has run on Tally or an on-premise ERP for ten years is not running on software. It is running on software plus a decade of accumulated convention: how a particular ledger is used, which fields were repurposed for something they were not designed for, what a specific narration prefix means, and which reports are trusted versus which are politely ignored. The migration project is mostly about surfacing that, and teams that scope it as a data transfer discover this in month three.

Global capability centres in Bengaluru have moved a long way from the cost-arbitrage back offices of twenty years ago, and the ones being built now are generally intended to own products rather than support them. That intent is the single strongest predictor of whether the centre succeeds, because it determines who is willing to join it. Senior engineers in this market have options, and they can tell within one interview loop whether a role involves deciding anything.

We build software in India, so read this knowing where it comes from. The comparison is worth making honestly anyway, because a buyer who picks the wrong geography for their situation ends up unhappy with a supplier who was never going to fit, and that helps nobody. The decision turns on three things: the time zone you need to work in, the size of team you need, and how specialised the skills are.

Every few months a team asks us to compare the three major clouds so they can choose correctly. The honest answer is that for the overwhelming majority of Indian businesses, all three will run the workload competently, all three have multiple Indian regions, and the feature differences that generate the most argument are the ones that matter least to the decision. AWS operates regions in Mumbai and Hyderabad, Microsoft Azure has regions across western, central and southern India, and Google Cloud runs regions in Mumbai and Delhi. Data residency, for most purposes, is satisfied by any of them.

Pulling structured fields out of invoices, purchase orders, contracts, claim forms and bank statements is one of the few AI applications with an obvious and immediate return, which is why every organisation with a back office is trying it. It is also an area where the demo is dramatically easier than the product, and the gap between them catches out teams who judged feasibility from the demo.

The RBI issued the Digital Lending Directions, 2025 on 8 May 2025, consolidating years of scattered guidance into one framework. Most provisions took effect immediately, the requirement to register digital lending applications with the RBI through the CIMS portal applied from 15 June 2025, and the rules governing multi-lender arrangements applied from 1 November 2025. If you are building or maintaining a lending product, this is the document your architecture is judged against.

The single most common misconception in Indian product onboarding is that Aadhaar verification is a service you sign up for. It is not. Online Aadhaar authentication is restricted to entities licensed as Authentication User Agencies, Know Your Customer User Agencies or sub-KUAs under the UIDAI framework, and that licensing is generally available to regulated entities rather than to private companies at large. A software product that is not itself a bank, NBFC or similarly notified entity cannot independently authenticate against the Aadhaar database, however many vendors offer to arrange it.

The Ayushman Bharat Digital Mission is India's national digital health framework, with the National Health Authority acting as certifying body. For anyone building or selling hospital or clinic software here, ABDM compliance has moved from optional differentiator to procurement requirement, and the integration is a larger piece of work than most vendors budget for.

The Government e-Marketplace is the unified portal through which central and state government bodies and public sector undertakings buy, and it has removed most of the intermediary layer that used to sit between a vendor and a public buyer. For an Indian IT firm it is a substantial addressable market that requires no relationship-building to enter — only registration and the patience to learn how procurement actually works there.

An Indian SaaS company selling abroad has two problems that a domestic one does not: getting paid in another currency, and proving to the Indian system that the payment was what you say it was. Founders usually solve the first and discover the second at the end of the financial year, when someone asks for documentation that nobody was collecting.

When an investor or acquirer sends in a technical diligence team, founders tend to prepare by trying to make the codebase look good. This is the wrong preparation and it is also impossible in the available time. Diligence teams have seen many codebases and expect none of them to be clean. What they are actually assessing is whether the engineering leadership has an accurate picture of their own system, because a team that knows its weaknesses can be planned around and a team that does not cannot.

Equity is offered to Indian engineers far more often than it is understood by them, and the gap does most of the damage. A grant letter with a number of options, a strike price and a vesting schedule means very little to someone who has not been through a liquidity event, and a company that treats the grant as self-explanatory usually finds that it neither retains nor motivates. Explaining the instrument properly is not a legal task, it is a management one.

A company with a product but no senior technical leadership has a specific and expensive problem: decisions with long consequences are being made by people optimising for this week. Which platform, which architecture, which vendor, which hire, what to build in-house — each gets settled by whoever is nearest, and the cost arrives eighteen months later. A fractional or part-time CTO exists to take those decisions, and understanding that is the difference between the arrangement working and it disappointing everyone.

A non-technical founder hiring their first engineers is being asked to judge something they cannot evaluate directly, and most respond in one of two unhelpful ways. Some outsource the judgement entirely to a recruiter, whose incentive is placement rather than fit. Others try to compensate by learning enough to run a technical interview, which produces a superficial screen that a well-prepared weak candidate passes and a strong quiet one fails. Neither works, and the way out is to stop trying to assess what you cannot.

Organisations often write a deliberately loose requirements document, reasoning that it invites suppliers to propose creative approaches. What it actually does is select for suppliers comfortable quoting on incomplete information — which is not the same population as suppliers who will deliver well. The careful ones either decline or price in the uncertainty, so you end up choosing between an optimistic number from someone guessing and a defensive number from someone hedging, with no basis to compare them.

Every Indian engineering team eventually hits the same bug: OTPs work in testing, work for some users, and vanish for others, while the SMS provider's dashboard reports successful delivery. The cause is almost always DLT. Under TRAI's TCCCPR 2018 regulation, telecom operators maintain a distributed ledger registry of who is allowed to send commercial messages, under what sender name, and with exactly what text. Outbound SMS is scrubbed against that registry in real time, and anything that does not match a registered template is blocked.

The Reserve Bank issued the Digital Payments – E-mandate Framework, 2026 on 21 April 2026, effective immediately, consolidating eight separate circulars issued between 2019 and 2024 into a single document. For anyone running a subscription business in India, this is now the reference. The substantive changes are modest — grievance redressal detail and card re-issuance mapping, plus adjustments from stakeholder feedback — but having one document instead of eight is itself worth the re-read.

SEBI's Cybersecurity and Cyber Resilience Framework arrived as circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 on 20 August 2024, and has been amended twice since — on 30 April 2025 and 28 August 2025. It applies to twenty-two categories of regulated entity, spanning stock exchanges, clearing corporations, depositories, brokers, asset managers, custodians and alternative investment fund managers. If you build or operate software for any of them, the framework is now part of your delivery obligations whether or not it is named in the contract.

An e-way bill is required when a single consignment exceeds fifty thousand rupees in value, or when the aggregate value of consignments in one vehicle does. That is the interstate rule; intrastate thresholds vary by state, ranging from fifty thousand up to two lakh, which is the first thing an engineer discovers is not a single number. Normally the supplier generates it, but the recipient may where they transport goods themselves, and where an unregistered supplier sells to a registered buyer, compliance falls on the buyer.

We build custom software, so treat what follows accordingly — but the honest position is that a large share of what businesses ask us for should not be built from scratch. An internal approval workflow, a data collection form feeding a report, a lightweight CRM for a team of fifteen: building these bespoke is often an expensive way to arrive somewhere a configured platform reaches in a fortnight. Recommending against a project is occasionally the right recommendation.

Almost every services firm eventually tries to build a product. The logic is sound: services revenue is linear in headcount, product revenue is not, and the team has already built the same thing four times for four clients. The attempt usually fails, and it fails in a consistent way that is worth understanding before starting rather than after.

A great deal of Indian business runs on spreadsheets that have grown for years — an order book, a production plan, a commission calculation, a reconciliation. When a company asks for software to replace one, the instinct is to treat the spreadsheet as a mess to be swept away. That is the wrong reading. It is the most accurate specification of the business process that exists anywhere in the organisation, including in anyone's head, and the first task is to read it properly rather than replace it quickly.

Support agreements are usually negotiated in a comfortable moment and invoked in an uncomfortable one, which means the words matter far more than they seem to at signing. The most common defect is not a target that is too aggressive — it is a target that cannot be measured, or that measures something neither party actually cares about.

Most data models used in Indian software were inherited from Western frameworks and encode assumptions that do not hold here. The failures are individually small and collectively constant: a name that will not save, an address that cannot be delivered to, a phone number rejected as invalid. Each generates a support ticket, and each is entirely avoidable at design time.

Twenty-four hour support is one of the more attractive things an Indian firm can offer a Western client, because the time zone that complicates collaboration becomes an advantage the moment the requirement is coverage rather than conversation. It is also one of the easier commitments to sell and harder ones to run well, and the gap between the two shows up around month four.

An operator running a platform where other people sell picks up obligations that a direct seller does not have. Under GST there is a collection requirement on the value of supplies made through the platform; under income tax there is a deduction requirement on payments to participating sellers. Both are computed by the operator and both are reported by the operator.

Every organisation that has lost data had backups. The failure is almost never that no backup ran; it is that the backup did not contain what was needed, or could not be read, or took far longer to restore than anyone had assumed.

Most selection processes evaluate a company through its sales function - a proposal, a capability deck, a reference call arranged by the vendor. All three are curated. Technical due diligence means evaluating the thing you are actually buying, which is a team's engineering judgement, and it takes about ninety minutes if you ask the right things.

WebRTC makes a two-person video call surprisingly easy to prototype. Browsers handle capture, encoding and peer connection, and a working demo comes together quickly. That demo creates an expectation about effort that the rest of the work does not meet.

A software bill of materials is an inventory of the components in a piece of software — direct dependencies, transitive dependencies, versions and licences. The idea is old; the requirement to hand one over is new, and it is appearing in enterprise procurement and in regulated sectors.

It is the first question every buyer asks and the one most development companies answer with a shrug and a discovery call. So here are the actual numbers. Rate surveys published across the Indian market in 2026 put junior developers (two to three years) at roughly $14-25 per hour depending on stack, mid-level engineers (three to six years) at $20-38, and senior engineers at $32-58. Full-stack sits at the upper end of each band. Specialists carry a premium: developers with production AI and LLM integration experience are commanding 25-40% above the equivalent general rate, which currently makes it the fastest-appreciating skill in the Indian market.

In a services firm, the solution architect is the person who turns a client's stated problem into something that can be estimated, staffed and built. When the role works, projects start with a shared understanding of scope. When it does not, sales promises one thing and delivery discovers another.

Estimating a project properly takes real work — understanding the current systems, the constraints, the integrations, the people. Firms routinely do this unpaid, in the hope of winning the build. The cost is absorbed, the estimates are rushed because the work is unfunded, and the resulting number is the one everyone is held to.

The phrase minimum viable product has been used loosely enough that it now means whatever the person saying it wants it to mean. To a founder under time pressure it means the cheapest version. To an engineer it often means the version without the difficult parts. Both readings produce something that answers no question, which is the only thing an MVP is actually for.

A standard analytics snippet, installed with defaults, captures page URLs, referrers, device details and often the contents of form fields and page elements. URLs frequently carry identifiers, email addresses and search terms. All of it goes to a third party, usually outside India.

Teams starting AI work assume the question is cost. Often the first real obstacle is availability: the instance type you planned around is not available in the region you need, and the wait is measured in weeks.

There are two ways to buy engineering from an Indian partner, and they suit genuinely different situations. Project outsourcing means you define a piece of work and buy its delivery. A dedicated team means you rent engineers, month by month, and direct them yourself. Buyers usually compare the two on monthly cost, which is the least informative axis available.

AI coding assistants are now standard equipment on many teams. The measured effect on delivery speed varies widely between studies and between tasks, and the honest position is that the benefit is real for some work and marginal for other work. That uncertainty is a reason to roll out deliberately rather than not at all.

Ask who owns your domain registration and you will often get a pause. It was registered years ago, possibly by an agency, possibly on a personal credit card belonging to someone who has left. The renewal notice goes to an address nobody reads.

TLS certificate expiry is one of the few outages with a known date in advance. It still catches organisations regularly, because the certificate that expires is rarely the main website — it is an internal API, a load balancer health check, a client certificate on an integration, or a mail server.

A convincing imitation of your company costs an attacker a domain registration and an afternoon. The variants that matter are the ones a customer would not scrutinise: a hyphen added, a letter doubled, a different top-level domain, a homoglyph from another script.

Point-of-sale integration is unforgiving because the failure is public. A slow response or an error is not a logged exception; it is a queue of customers watching a cashier apologise. That constraint should shape every design decision.

A business with several branches usually knows how much stock each holds, on paper. Whether that number is accurate enough to tell a customer 'yes, we have it' is a different question, and the gap between the two is where the commercial value sits.

Every legacy system reaches a point where someone proposes replacing it. The argument is always persuasive: the code is unmaintainable, nobody understands it, each change takes weeks, and a clean rebuild on modern foundations would take eighteen months. The trouble is that the eighteen months is measured against a specification nobody has written, for a system whose behaviour nobody fully knows, while the original keeps changing underneath. Full rewrites are the most commonly attempted and most commonly abandoned modernisation strategy there is.

Any business software that touches money eventually meets the question of how data reaches the accounting system. In India that usually means Tally, and increasingly also cloud packages such as Zoho Books, or an ERP for larger organisations. The integration effort varies enormously between them.

Support desk software is a crowded market where every product demonstrates well. Freshdesk, Zoho Desk and Zendesk all handle a ticket competently. The decision usually comes down to channels, reporting and cost at your actual volume.

Building a SaaS product is a different discipline from building software, and the difference is concentrated in a handful of early decisions. They are easy to make casually because at one tenant they appear not to matter. By the fiftieth tenant, and particularly by the first enterprise buyer, they determine whether the platform grows or gets rebuilt.

An API gateway handles traffic arriving from outside — authentication, rate limiting, routing, request shaping. A service mesh handles traffic between your own services — encryption, retries, observability, traffic shifting. North-south and east-west, in the usual shorthand.

Every team has a support matrix. Most have never written it down, which means it is whatever the developers happen to test on — recent Chrome on a good laptop — and everything else works by luck.

India's Digital Personal Data Protection Rules were notified on 14 November 2025, starting an eighteen-month transition that ends on 13 May 2027. Between those two dates sit deadlines that most companies have not put in a plan, and penalties at the end of it reaching up to ₹250 crore for serious violations. The reason to act now is not the final date - it is that the engineering work involved has a longer lead time than the calendar suggests.

Emulators and simulators are fast, scriptable and essential for the development loop. They are also uniformly well-behaved, well-resourced and running recent software, which is exactly what your users' devices are not. A test suite that passes only on emulators is testing the code, not the product.

Three techniques get proposed for almost every LLM problem, and they solve genuinely different failure modes. Choosing wrongly is expensive - not because the wrong one fails loudly, but because it half-works, which is worse. The distinction is easier to hold if you frame each one by the deficiency it corrects.

In most companies of any age there is a scheduled job that writes a file, drops it somewhere, and another job that picks it up and loads it. It was the pragmatic answer when it was built and it has run for years. It is also, usually, the least observable and most failure-prone part of the estate - and the failures are silent, which is the part that costs money.

SOC 2 usually enters the conversation the same way: a large customer sends a security questionnaire, somewhere in it is a request for a SOC 2 report, and the deal stops moving. What follows is a fortnight of vendors quoting wildly different numbers and nobody explaining what the money is for. Here is the whole budget, broken into its parts, at 2026 Indian market rates.

The decision to build a native app is usually made before anyone examines whether it is necessary. Someone senior observes that competitors have one, or that customers are on phones, and the requirement arrives fully formed. But a mobile web experience and a native app cost very different amounts, carry very different maintenance burdens, and only one of them requires app store approval for every change. It is worth ten minutes of examination.

Choosing a development partner is a decision made with very little information, usually under time pressure, by someone who will have to live with the consequences for years. Price, timeline and technology stack dominate the conversation because they are easy to compare across proposals. They are also the three things most likely to change. These are the questions we would ask instead, and we include them knowing they are uncomfortable to answer.

Automated testing is the first thing cut when a deadline tightens, and the reasoning is always the same: the feature is what the customer wants, tests are overhead, and we will add them later. It sounds like a trade of quality for speed. In practice it is a trade of speed later for speed now, at a poor exchange rate, and the bill arrives within months rather than years.

Indian teams building software for US healthcare clients hit the same confusion early: the client says the system must be HIPAA compliant, and there is no exam to sit, no certificate to purchase and no body that issues approval. HIPAA is a law with requirements, not a certification scheme, and the vendors selling HIPAA certificates are selling their own assessment rather than anything official. What your client actually needs is evidence that specific obligations are met.

The pitch for AI agents is that instead of coding a process, you describe a goal, give the model some tools, and let it work out the steps. In demonstrations this is genuinely impressive. In production it separates sharply into cases where it earns its place and cases where it is an unreliable reimplementation of something a workflow engine has done deterministically for twenty years.

Recovery time objective and recovery point objective appear in most enterprise contracts and disaster recovery policies, usually as numbers somebody chose because they sounded responsible. RTO is how long you may take to restore service after a failure. RPO is how much data you may lose, measured in time. Both are commitments, and both have an architecture and a cost attached that is rarely traced back before signing.

Bengaluru gets described in marketing copy as the Silicon Valley of India, which is the kind of phrase that stops conveying information. The useful version is more specific: the city has an unusually deep concentration of engineers who have operated production systems at scale, because the global product companies, the Indian IT majors and a large startup ecosystem have all been hiring into the same talent pool here for three decades. That depth is the actual asset, and it is why the city is a reasonable default for work involving architecture rather than execution.

ERP programmes rarely fail in a way that produces a headline. Far more often the system goes live, the project is declared complete, and eighteen months later the real work is still happening in spreadsheets alongside an expensive licence. The technology functions; the organisation simply did not move onto it. The reasons repeat across companies and industries.

Companies working with Indian teams for the first time expect the time difference to be the hard part. It rarely is on its own. The difficulties that actually surface are decision latency and handover quality, and both have practical fixes that have nothing to do with asking anyone to work unsociable hours.

Adding an assistant to an existing product looks like a self-contained feature and behaves like a cross-cutting one. The model is the easy part - an API call. What takes the time is everything around it: what the assistant is allowed to see, what it is allowed to do, how it gets enough context to be useful, and what happens when it is confidently wrong in front of a paying customer.

Every AI vendor quotes an accuracy figure and almost none of them explain what it measures. The number is usually true and frequently meaningless, because accuracy is only defined relative to a dataset, a task and a definition of correct. Four questions convert the claim into something you can act on, and any vendor doing serious work will welcome them.

Industrial IoT programmes on Indian factory floors tend to follow a recognisable arc: sensors are installed, a dashboard appears, executives are shown live machine data, and then nothing changes. Output is the same, downtime is the same, and eighteen months later the dashboard is open on a screen nobody looks at. The failure is almost never the sensors.

Cloud migration budgets fail in a specific way: the number covers moving the workloads and nothing else, and the project then spends its contingency on the parts nobody costed. So it is worth starting from what published 2026 figures actually say, and then being precise about what those figures do and do not include.

Ask three firms to price a penetration test on the same web application and the quotes will differ by a factor of ten. That is not a market inefficiency you can arbitrage. At the bottom of that range you are buying an automated scanner report with a cover page, and at the top you are buying a senior tester spending two weeks trying to break your authorisation logic. Knowing which you are being offered is the entire skill in buying this.

Warehouse pricing looks transparent - every vendor publishes rates - and is in practice one of the harder things to forecast, because what you pay depends on how the thing is used rather than how much data you hold. It is worth starting with the published rates, then being clear about which of them actually drive a bill.

Costing an LLM feature starts easy and gets difficult fast. The published rates are public and precise. What is not public - and this is the finding worth leading with - is almost everything downstream of them. When we went looking for citable figures on tokens consumed per request, or cost per user per month, we found that essentially every number in circulation traces back to blog posts performing arithmetic on the same public price lists. There is no observed data. Anyone quoting you a benchmark for cost per user is quoting a model, not a measurement.

Any figure you read for engineering salaries in Bengaluru depends almost entirely on who was counted. Indeed puts the average software engineer at around ₹10.4 lakh from 5,700 self-reported salaries. Recruitment platform data covering eight thousand tech roles puts engineers with two to three years at a product company between ₹14 and ₹28 lakh. Neither is wrong. Job-board data skews towards IT services and junior roles and usually captures base pay only; platform offer data captures active switchers at product companies and includes variable and equity. Mixing them produces nonsense, and a lot of published comparison is exactly that.

The microservices decision is usually made for the wrong reason, which is that the codebase has become unpleasant to work in. Splitting it into services does make each piece smaller. It also converts every function call that crossed a module boundary into a network call that can fail, time out, or arrive twice, and it converts every schema change into a coordination problem between teams. You have not removed the complexity; you have moved it somewhere harder to debug.

Kubernetes is genuinely good engineering that solves a genuine problem: running many containerised workloads across a fleet of machines, with automatic placement, self-healing and rolling updates. The question is not whether it works. It is whether the problem it solves is one you have, because the cost of running it is charged continuously and the benefit only arrives at a certain scale.

The default answer for a new product is PostgreSQL, and the useful discussion is about when that default breaks rather than about comparing feature matrices. Postgres handles relational data, JSON documents, full-text search, geospatial queries and vector similarity in one system, with transactions and constraints that stop bad data existing in the first place. Most products never outgrow it, and the ones that do outgrow one specific dimension of it rather than the whole thing.

Most database changes that cause outages do so because the schema and the application changed together. For a moment during deployment, old code is running against a new schema, or new code against an old one, and one of those combinations does not work. The technique that removes this entire class of failure is to make every change backwards compatible and to deploy it in stages, so that at no point is any running version of the code incompatible with the schema it sees.

Events decouple producers from consumers, and that is a genuine benefit: a service can publish that something happened without knowing or caring who reacts. The cost, which is rarely discussed with the same enthusiasm, is that no single place in the system describes what happens when an order is placed. The behaviour is distributed across every consumer, and understanding it means reading all of them.

Caching is the most reliably effective performance tool available and the one most likely to introduce a bug nobody can reproduce. Both facts come from the same property: a cache makes the system serve data that was true at some point rather than data that is true now. Whether that is fine or catastrophic depends entirely on the data, and that judgement is the whole discipline.

"AI-first" has become one of those phrases every vendor slaps on a homepage, which means it's mostly stopped meaning anything. So here's our operational definition, the one we actually hold ourselves to on every engagement: before we scope any project, we ask what part of it should be automated or augmented with AI, and we only rule it out after that question has a real answer - not by default.

Most API versioning discussions are about where the version goes - the URL, a header, a media type - which is the least consequential decision in the whole area. The consequential one is what you commit to when you publish version one, because every version you have ever released is a version you are maintaining until you can prove nobody uses it.

Lock-in anxiety produces some of the most expensive architecture decisions in enterprise software: abstraction layers over cloud services, self-hosted alternatives to managed ones, portability requirements that constrain every design. The anxiety is not baseless, but it is usually pointed at the wrong things. Some dependencies are genuinely hard to leave; others are trivial and get treated as though they were not.

Observability tooling is easy to buy and easy to misapply. A common end state is a large monthly bill, dashboards nobody consults, alerts everyone has muted, and an incident where the first twenty minutes go on establishing what is actually wrong. The problem is almost never volume of data. It is that the wrong things were measured, in a form that cannot answer questions.

Published incident management frameworks assume a dedicated reliability team, a rota of incident commanders and a war room. Most companies running important software have none of those, and conclude that incident process is for larger organisations. The conclusion is wrong: four practices deliver nearly all the benefit and none of them requires a specialist.

On-call is where reliability practice meets human cost, and the cost is usually paid quietly until someone resigns. The failure is rarely the existence of a rota. It is a rota where the pages are frequent, unactionable, or arrive for systems the person on duty has no ability to fix, and where the hours spent awake at night are treated as free.

The single most useful idea in modern delivery is that deploying code and releasing a feature are different events. Deploy the code dark, behind a flag that is off. Turn it on for yourself, then for a few per cent of users, then for everyone - and turn it off in seconds if something is wrong. That decouples the risky moment from the deployment, and it is why teams that do this can deploy on a Friday afternoon without anyone becoming tense.

Almost every stalled AI project we're brought in to rescue has the same root cause, and it's not the model. It's that nobody checked whether the data underneath could actually support what leadership wanted to build. Here's the six-point audit we run before scoping any AI engagement.

Almost every organisation has secrets in places they should not be, and almost every one believes it does not. The reason is that secrets spread by ordinary, reasonable actions: an engineer pastes a connection string into a chat to unblock a colleague, a config file gets committed during a rush, a credential is emailed to a contractor. None of these are negligence. They are what happens without a mechanism that makes the right path easier than the wrong one.

Technical debt conversations fail in a predictable way. Engineering says the codebase is a mess and changes are painful; leadership hears a preference for tidiness competing against customer features, and chooses the features. The problem is not that leadership is short-sighted. It is that one side is speaking in adjectives and the other budgets in numbers.

Code review in most teams has drifted into two failure modes at once: a rubber stamp on large changes nobody has capacity to read properly, and a pile of comments about naming and formatting on small ones. Both feel like process and neither catches the defects that matter. Fixing it is mostly about removing what machines should do and being explicit about what humans are for.

Almost every team has documentation that is out of date, and concludes that documentation does not work. What actually failed is a particular kind of documentation: the kind that describes what the code does. That is guaranteed to rot, because the code changes and the prose does not, and a wrong document is worse than none because someone will trust it.

Most teams are roughly competent at estimating greenfield work and reliably terrible at estimating changes to a system that already exists. The gap is not discipline, it is information. On new work you are estimating construction, which you can decompose. On existing systems you are estimating discovery, and you cannot decompose what you have not found yet.