Practical notes from the engineers who build agents, copilots and AI products.
No service is compliant in the abstract; your implementation either is or is not. An API handling personal data of people in India must carry a purpose with every read, restrict access by role, log who saw what, enforce retention automatically and delete on request. Those five controls belong in the specification.
You implement a data analytics application in five stages: audit the sources, agree one definition per metric, build incremental pipelines, enforce permissions in the database, then design the front end around a decision. The order matters, because every stage inherits the mistakes of the one before it.
Analytics application projects fail in five recognisable ways: contested metric definitions, pipelines that fail silently, permissions bolted on late, dashboards designed around the data rather than a decision, and no owner after handover. Each has an early symptom and an engineering decision that prevents it.
Data analytics application development for startups is a speed problem over one or two clean sources; enterprise work is a governance problem across a dozen messy ones. The architecture is similar. What changes is integration depth, access rules, the approval chain and the cost, which moves roughly four-fold.
Measure four layers: correctness, freshness, adoption and decision impact. Correctness asks whether the numbers match the source of truth, freshness whether they arrived in time, adoption whether the people who should use the application do, and decision impact whether anything downstream actually changed.
In five phases: assess what the system really does, wrap it in characterisation tests, cut a seam so new code runs beside old, replace modules in business-pain order behind a routing layer, then cut over function by function. Nothing is switched off until its replacement has run in production.
Not automatically. India's DPDP Act applies to the personal data flowing through an analytics application, not to the category of software, so compliance depends on four architectural choices: what you copy into the warehouse, on what lawful basis, for how long, and who can see which rows.
Legacy application modernization services projects fail in five recurring ways: a big-bang cutover with no rollback, no safety net of tests, undiscovered business rules, data that will not reconcile, and users who were never brought along. Each has an engineering decision that prevents it, taken in the first month.
A modernisation programme is DPDP compliant when every copy of personal data it creates is inventoried, minimised, encrypted, retained on a clock and logged. The Act does not regulate your architecture; it regulates what happens to personal data while you move it, which is exactly what modernisation does at scale.