top of page

The price you pay for choosing least privilege

Writer: sathyavenkatesh
sathyavenkatesh
Mar 18
2 min read

There is a real cost to building products on the principle of least privilege.

Nithin Kamath wrote recently about how systems designed with strict permissions, limited access, and tighter controls are harder to build, slower to ship, and often less convenient in the short term. But they tend to be safer, more resilient, and more trustworthy over time.


That observation stayed with me because this is something we run into constantly while building Aarambh and Saarthi. In theory, least privilege sounds obvious.


Give the system only the access it needs. Collect only the data you require. Ask for only the permissions you can justify.


In practice, this is one of the most expensive principles you can choose. The easiest way to build a financial product is to ask for everything upfront. Full account access. Full data sync. Broad permissions. Most users will allow it and platforms encourage it.


From an engineering standpoint, it makes the system simpler. You have fewer edge cases and conditional flows to handle and a less defensive design. But the moment you decide to follow least privilege seriously, the entire design changes. You have to think much harder about workflows and design for partial information.You need to make the product useful even when you don’t control all the data.You need to explain to users why something works the way it does instead of hiding the complexity behind access.



Everything takes longer.


Both Aarambh (build - in- progress) and Saarthi (Live on chrome store) are built design-first on this principle. We deliberately avoid asking for more permissions than necessary.We avoid storing data we don’t need.We avoid building features that require broad access just because it makes implementation easier.


This means slower progress.It also means more time spent on UX, more time on architecture, and more time on trade-offs that most users will never see.


But in financial products, trust is not a feature you add later. It is something you design for from the beginning.Least privilege forces discipline.It forces clarity.And it forces you to accept that the cleanest engineering solution is not always the one that deserves to exist.

The price is real. But over time, trust tends to compound just like money does.

Comments


bottom of page