What we learned building Prudentum

Building a personal finance application sounds straightforward at first.

You record income. You record expenses. You organize transactions into categories. You look at the numbers. Maybe you add a chart or two.

It is tempting to think the product is mostly a database with a nice interface on top.

It isn't.

The moment we started thinking seriously about Prudentum, the problem became much more interesting. Money is personal. People do not interact with their finances in exactly the same way.

Some people want detailed categorization. Some want a simple record of where their money went. Some want dashboards. Some want nothing more than a quick way to record a transaction. Some are comfortable creating an account immediately. Others would rather use the application first and decide later whether they want synchronization.

And if the application is supposed to become something people trust with their financial information, then technical decisions around privacy, reliability, storage, synchronization, and authentication stop being implementation details. They become part of the product.

Prudentum started as an idea for a personal finance manager. The more we built it, the more we realized that the real problem was not simply how do we track money? It was how do we make managing money feel simple enough that people actually want to do it?

That question changed the way we approached the product.

§1. The problem is not accounting

The first lesson was probably the most important.

A personal finance application is not fundamentally an accounting application.

Accounting asks questions like: what is the balance, what was the transaction, which account does it belong to, what is the category, what happened during a period.

A person asks different questions. Where did my money go? Am I spending too much? Can I afford this? How much did I spend this month? What do I usually spend money on? Am I making progress? Why does my balance feel lower than expected?

Those questions are about understanding, not merely recording.

This distinction matters because the database can be perfectly correct while the product is still unhelpful. A transaction table can tell us that ₹500 was spent. It does not automatically tell the user what that means.

The product has to turn records into understanding.

§2. Financial well-being is bigger than a number

This became clearer when we looked at how financial well-being is discussed outside software.

The Consumer Financial Protection Bureau describes financial well-being in terms of both financial security and freedom of choice. The framework includes four broad dimensions.

That is a much richer definition than "having a high balance."

It changes how we think about a finance product. A dashboard should not simply answer how much money do you have? It should help someone understand how am I doing?

Those are not the same question. A person with a large balance can still feel completely out of control. Another person with a modest income can have a clear understanding of their expenses, savings, obligations, and goals.

So Prudentum should not be designed around making financial data look impressive. It should be designed around making financial information understandable.

§3. The first interaction should be extremely cheap

One of the biggest practical problems with personal finance software is data entry.

If recording a transaction takes too much effort, people stop doing it.

Imagine this: you buy lunch. To record it, the application asks you to open the application, navigate to transactions, select an account, select a category, enter an amount, choose a payment method, enter a note, choose a date, and save.

Every field may be individually reasonable. Together, they create friction.

This led us to a simple principle: the easiest transaction to record is the transaction that gets recorded.

That is one reason we became interested in voice entry. Instead of requiring someone to fill a form, the user should eventually be able to say something like "Spent 250 rupees on groceries using UPI."

The interesting engineering problem is not speech recognition alone. It is understanding financial language.

§4. Natural language is messy

People do not speak in database schemas.

These sentences mean roughly the same thing. This is why we started thinking about the voice system as a pipeline rather than a single AI feature.

This architecture matters because each stage has a different responsibility. The speech recognizer does not need to understand finance. The amount extractor does not need to understand payment methods. The category extractor does not need to understand authentication.

Breaking the problem into smaller pieces makes the system easier to reason about.

§5. Offline-first changed the architecture

Another major lesson came from asking a simple question: what should happen if there is no internet?

For a finance application, the answer should not be you can't use the application.

Money management often happens in ordinary situations — while travelling, in stores, in places with poor connectivity, on unreliable mobile networks, or when someone simply does not want to wait for a server response.

We therefore wanted Prudentum to be offline-first. Offline-first means the application should continue to work when the network is unavailable, using local data and synchronizing when connectivity returns.

That sounds like a small feature. It isn't.

Offline-first is therefore not simply "add a cache." It changes how the application thinks about data.

§6. Offline-first is not the same as local-first

This distinction is worth understanding.

These architectures have different consequences. For Prudentum, this distinction matters because financial data is important enough that we cannot casually choose a synchronization model simply because it is convenient to implement. The architecture has to reflect the trust model of the product.

§7. We did not want account creation to be the first wall

Another decision followed naturally from the offline-first philosophy.

We did not want the first screen of Prudentum to effectively say create an account before you can use anything. That creates an unnecessary barrier.

This is more than an onboarding choice. It represents a broader philosophy: the user should not have to surrender their data or create an account merely to try the product. An account should provide a meaningful benefit. Synchronization is one such benefit.

§8. Privacy becomes part of the product

The moment you build a finance application, privacy stops being a checkbox.

The application may contain transaction history, spending patterns, income information, financial habits, notes, categories, and account-related information. Even if a user never thinks about the database schema, they are trusting the product with sensitive information.

The backend must never assume that because a request is authenticated, it is automatically authorized to access every record. A user's transaction belongs to that user. That ownership needs to exist at the data and application layers.

§9. The database taught us something about product design

Prudentum's data model initially looked simple. A transaction might contain an id, a category id, an amount, a payment mode, a transaction type, a note, a date, and a user id. A category might contain an id, a name, and a user id.

But every field raises product questions.

These questions demonstrate an important lesson: a database schema is a model of the product's assumptions. If the assumptions are wrong, a technically elegant schema can still produce a difficult product.

§10. Store financial facts; derive representations

One of the decisions we became particularly careful about was currency.

Suppose someone records 100 USD and later changes the application's display currency to INR. Should the original transaction become a different transaction? No.

The original financial event happened in USD. The application can represent that value differently for display, but it should not rewrite history simply because the user's preferred display currency changed.

The distinction is subtle but important. The application should not confuse the event with its representation. This becomes particularly important when historical exchange rates are involved. Financial software has to respect time.

§11. Multi-currency makes "amount" more complicated

A number such as 100 does not mean anything financially without a currency. These are all different: 100 INR, 100 USD, 100 EUR, 100 GBP.

So an amount should really be understood as something closer to (amount, currency).

Once multiple currencies are supported, analytics also becomes more interesting. Suppose a user has ₹5,000, $50, and €100.

This is another example of why product requirements eventually become architecture requirements.

§12. We learned not to build the dashboard first

Dashboards are attractive to engineers. They look like progress. You can build beautiful charts, spending breakdowns, monthly comparisons, category graphs, and trend lines. And it feels like the product is becoming sophisticated.

But a dashboard built on incomplete data is mostly decoration.

If users do not consistently record transactions, the chart is not useful. That means the real product problem may be transaction capture rather than visualization.

Instead of asking what chart should we build next? we increasingly ask what prevents the user from maintaining accurate financial records?

That question is much more valuable.

§13. The product should help without becoming a financial authority

There is another boundary we want to maintain. A finance application can help users understand their information. That does not mean it should pretend to know what financial decisions are universally correct.

So one principle for Prudentum is: explain the user's financial data before trying to prescribe what the user should do. The product should increase understanding first.

§14. We learned that "simple" products are technically difficult

One of the biggest misconceptions about simple products is that simplicity means fewer engineering problems. Often the opposite is true. A simple interface can hide a complicated system.

The interface is simple because the complexity has been pushed into the system. That is good complexity. The user should not have to understand the architecture in order to record a transaction.

§15. We stopped treating features as isolated features

Voice entry is not just a voice feature. It touches speech recognition, natural-language parsing, transaction validation, categories, payment modes, confirmation, local storage, and synchronization.

Multi-currency is not just a currency dropdown. It touches transaction storage, exchange rates, dates, analytics, display logic, and user settings.

Offline mode is not just a cache. It touches local persistence, synchronization, authentication, conflict resolution, and failure handling.

This is one of the strongest lessons we learned: features are rarely isolated. A feature is usually a change to a system of connected assumptions.

§16. Building for yourself is useful — but not enough

Prudentum is particularly interesting because it is the kind of product that can easily become an internal tool first.

You can build it because you personally want a better way to understand your finances. That is valuable. It gives you a concrete problem. It lets you use the product yourself. You can notice friction immediately.

But personal use has a limitation. You are only one user. Your preferences are not universal. The fact that something makes sense to you does not prove that it makes sense to everyone.

So the next step after building for yourself is not to assume everyone needs this. It is to ask which parts of this problem are actually shared by other people?

§17. The smallest useful product matters

It is tempting to add everything. Budgets. Goals. Investments. Bills. Subscriptions. Bank integrations. AI advisors. Predictions. Tax tools. Reports. Social features. Gamification.

The list never ends. But every feature creates additional state, edge cases, maintenance, and cognitive load. So we started thinking about Prudentum as a sequence rather than a giant feature list.

§18. Reliability beats cleverness

There is an understandable temptation to put AI everywhere. A finance application could theoretically have an AI assistant that analyzes spending, predicts expenses, categorizes transactions, answers questions, and provides recommendations. Some of those capabilities may eventually be useful.

But an intelligent system built on unreliable transaction data is not particularly intelligent. If the user has missing transactions, incorrect categories, duplicated records, or wrong currencies, sophisticated analysis simply produces sophisticated-looking mistakes.

The intelligence of a financial product ultimately depends on the quality of the underlying financial model.

§19. The parts we rewrote twice

The most useful engineering lessons rarely come from the code that worked on the first attempt. They come from the code that seemed correct until we understood the problem better.

Prudentum has forced us to revisit several assumptions.

These rewrites were not failures. They were evidence that our understanding of the product was improving.

§20. The product is becoming a system, not a collection of screens

At the beginning, it is natural to think about a product visually. There is a home screen. There is a transaction screen. There is an analytics screen. There is a settings screen.

But as the product matures, those screens become the visible surface of a deeper system.

That changed how we approach product development. Instead of asking only what screen should we build?, we increasingly ask what underlying capability does this screen depend on? That question leads to better architecture.

§21. The product should disappear into the habit

The long-term goal for Prudentum is not to make people obsessed with managing money. It is almost the opposite.

We want the process to become lightweight enough that recording a transaction becomes an ordinary habit.

Record. Understand. Adjust. Move on.

A personal finance application should not make someone feel like they are running an accounting department every evening. It should make financial awareness easier to maintain.

That is why simplicity, offline capability, fast entry, good defaults, and clear analytics matter so much. They are not isolated UX improvements. They all reduce the cost of maintaining financial awareness.

§22. What we are still figuring out

A product studio should be comfortable saying: we don't know yet.

There are still questions around Prudentum that need real-world validation.

These are not questions that can be completely answered from a database diagram. They require users. That is the next stage of product development.

§23. The bigger lesson

The most important thing Prudentum has taught us is that building a product is not primarily about adding features. It is about reducing uncertainty.

At the beginning, we had an idea: people need a better personal finance manager.

Every engineering decision has helped us turn that vague idea into more specific questions.

For Prudentum, that direction is becoming clear: financial software should help people understand their money without making managing money feel like another job.

That is the product we are trying to build. Not the biggest finance application. Not the application with the most charts. Not the application with the most AI. Just a system that makes an important part of everyday life a little easier to understand.

And that, for us, is a much more interesting problem to solve.