Building a financial application is rarely just about putting numbers on a dashboard. The real challenge is making complex financial information understandable, useful, and trustworthy for its users.
When we started working on Finanion(our first-ever client project), the initial requirement was relatively straightforward: capture personal financial information and present it in one place. As the product evolved, that requirement became much more interesting.
The platform moved from simply capturing and displaying financial data to helping users understand their financial position, analyze it, and use predictions to plan.
For CreoWis, this became a practical example of what modern financial application development really involves: combining domain understanding, UX design, product thinking, architecture, full-stack development, testing, and rapid delivery.
The Problem: Financial Data Is Complex by Nature
Personal finance is fragmented.
A person’s financial picture can include investments, insurance, loans, income, expenses, emergency funds, financial goals, tax information, and other assets and liabilities.
The data itself is not necessarily the hardest part. The harder problem is answering a simple question: How do you present all of this information without overwhelming the user?
A financial application can technically expose hundreds of data points and still provide a poor user experience. Users do not want to understand the database structure behind their finances.
They want to understand questions such as:
Where do I stand financially?
Am I making progress toward my goals?
How much should I save?
What happens if my circumstances change?
What should I be planning for next?
This became one of the central product and UX challenges while building Finanion. The goal was not simply to make financial data look good. The goal was to make financial data understandable.
Designing UX for Personal Finance
Financial products have a particularly interesting UX challenge. Users are often dealing with concepts they may understand only partially. Terms such as emergency corpus, insurance coverage, loans, investments, asset allocation, and taxation can quickly become intimidating when presented without context.
The Finanion experience therefore had to balance three things:
Financial depth
Simplicity
Trust
The interface needed to accommodate a significant amount of information while remaining approachable. We worked on a friendly visual language, responsive layouts, mobile usability, and information presentation that made financial concepts easier to understand. The dashboard became more than a collection of charts. It became a single view of the user’s financial situation.
The product brought together areas such as financial goals, financial data, notifications, emergency corpus, insurance, investments, loans, and income tax information. This is an important principle we have learned from building complex products: Complexity should exist in the system, not in the user’s interface.
A sophisticated backend and data model can support a sophisticated product. The interface should still feel simple.
From Data Capture to Financial Intelligence
One of the interesting parts of the project was how the product evolved during development.
The initial requirement was primarily about capturing financial information and presenting it to users. As the product matured, analytics and predictions became part of the experience. That changed the role of the application.
It was no longer simply a system for storing financial information. It became a system that could help users interpret that information and plan ahead. This evolution illustrates an important consideration when building financial software.
A financial application’s data model should not only support today’s screens. It should also leave room for future analytical and planning use cases. That influenced how we approached the underlying data structure.
The Data Model: PostgreSQL and Relational Data
Finanion’s data model was designed using a relational table structure in PostgreSQL. This was a natural fit for a domain where different financial entities have relationships with one another.
Users have financial information. Financial information can belong to different categories. Goals relate to financial planning. Investments, loans, insurance, income, and other financial records have their own relationships and attributes.
A relational database provides a structured foundation for representing these relationships while maintaining data consistency. More importantly, it gives the product a foundation that can support increasingly sophisticated queries and analytical requirements as the application evolves.
For financial software, the data model is not simply an implementation detail. It becomes part of the product architecture.
Why We Used GraphQL?
The application needed to present different combinations of financial information across different screens and experiences. A conventional REST approach can sometimes result in clients receiving more data than a particular view actually requires, or needing multiple API requests to assemble the information needed by a screen.
GraphQL provided a useful alternative. The client could request the specific fields required for a particular experience. That was particularly useful for a dashboard-driven application where different components may require different portions of the user’s financial data.
Instead of designing every response around a fixed screen, GraphQL allowed the frontend to describe the data it needed. This helped us keep the data consumption layer flexible as the product evolved.
Why Hasura?
Hasura was used as the GraphQL data access layer over PostgreSQL. This allowed us to expose the relational data through GraphQL without having to build a large amount of conventional API boilerplate from scratch.
For a project operating under a tight delivery timeline, that mattered. The objective was not to build infrastructure for its own sake. The objective was to get a reliable product into users’ hands quickly while maintaining a clean architecture.
The backend approach also provided capabilities that supported efficient data access and the application’s performance requirements. The broader lesson was more important than the specific technology choice: Choose infrastructure that accelerates product development without creating unnecessary abstraction.
The Frontend: React, Next.js and Tailwind CSS
The user interface was built using React and Next.js, with Tailwind CSS used for styling.
React provided the component-based foundation required to build a complex dashboard-driven interface. Next.js provided the application framework around it. Tailwind CSS helped the team move quickly while maintaining consistency across the interface.
This combination worked particularly well in a project where UX was continuously evolving alongside implementation. The design was not completed and handed over as a static specification. UX work continued while the interface was being developed. That allowed the product and engineering work to move forward in parallel.
How We Delivered the Product in 3.5 Weeks?
One of the most interesting aspects of the project was the delivery timeline. The initial product was delivered in approximately 3.5 weeks.
The delivery team consisted of:
One developer
One QA engineer
One project manager
The timeline worked because the team did not treat UX, development, and QA as completely sequential activities.
Week 1: Establishing the UX Foundation
The first week focused heavily on the initial UX. The team worked through the information architecture, user experience, financial information presentation, and overall product structure.
The objective was to establish how users would understand and interact with the financial information before implementation moved too far ahead.
Week 2: UX and UI Development in Parallel
The second phase introduced parallel execution. UX continued to move forward while UI development started implementing the completed portions of the design.
This meant development did not have to wait for the entire UX process to finish. At the same time, UX could continue refining areas that had not yet entered implementation.
Week 3: Refinement, Testing and Delivery
As the application came together, the focus shifted toward completing the core experience, validating responsive behavior, addressing usability issues, and testing the application.
This approach reduced the amount of sequential waiting between design and development. The lesson is simple: Speed does not always come from adding more developers. Sometimes it comes from reducing dependencies between teams.
Quality Assurance: Manual Testing Plus Automation
Rapid development can easily create a false tradeoff between speed and quality. We did not want that tradeoff.
Finanion used manual QA alongside automated browser testing with Playwright. Manual testing helped validate the actual user experience and functional behavior. Playwright automation provided repeatable browser-level validation for important application flows.
This combination is particularly useful for applications with substantial UI interaction because changes in one part of the application can unexpectedly affect another. Automated testing gives the team a safety net while manual testing provides the human perspective that automated tests cannot fully replace.
Deployment Architecture
The frontend was deployed on Vercel. The backend was deployed using Nhost as a backend-as-a-service platform, with Hasura and PostgreSQL forming the core backend data and API architecture.
This allowed the team to focus on product development without spending disproportionate effort building and maintaining infrastructure from the ground up.
For a small delivery team working against a compressed timeline, this was an important architectural consideration. The infrastructure should support the product team rather than become the product team’s primary workload.
Security Matters in Financial Applications
Financial applications naturally involve sensitive user information. Security therefore cannot be treated as something added at the very end of development. For Finanion, protection against common web application vulnerabilities such as cross-site scripting was considered during implementation.
This is only one part of financial application security, of course. Production financial systems require a broader security strategy covering authentication, authorization, data protection, secure API design, secrets management, logging, monitoring, infrastructure security, and regulatory requirements where applicable.
The broader lesson is: In financial software, trust is part of the product experience.
A user needs to feel that their information is being handled responsibly, not simply that the interface looks polished.
What Changed During Product Development?
One of the most valuable parts of building a real product is discovering that the first requirement is rarely the final product. Finanion started primarily around capturing financial data and presenting it to users.
During the product journey, analytics and predictions became increasingly important. That meant the application had to move beyond simple data visualization. The product needed to help users understand what their financial information meant and how it could support future planning.
This is a common pattern in digital product development.
The first version answers: What data do we have?
The more mature product starts answering: What does this data mean?
Eventually: What should the user do with this information?
For us, this reinforced the importance of designing an architecture that can evolve as the product’s intelligence grows.
The Impact
The Finanion project produced measurable and practical outcomes.
The project reported:
40% increase in new user registrations
58% reduction in onboarding time
82% improvement in operational efficiency
125 families impacted over three years
The platform also helped bring financial information together into a single experience, allowing families to understand their financial position more easily and use analytics and predictions for planning.
These numbers matter, but the bigger story is what they represent. A successful financial application is not simply one that stores more data. It is one that helps people make better decisions with the data they already have.
What We Learned Building a Finance Application
Building Finanion reinforced several principles that apply beyond this particular project.
Domain understanding comes before technology selection
Choosing React, GraphQL, PostgreSQL, or any other technology is only one part of the problem. Understanding what the financial product actually needs to accomplish comes first.
Financial complexity should be hidden behind simple UX
Users should not have to understand the underlying financial model to use the application effectively. The architecture can be complex. The experience should not be.
The data model should anticipate future product capabilities
A product that starts with data capture may eventually require analytics, reporting, prediction, and planning. Architecture needs enough flexibility to support that evolution.
APIs should serve the product experience
The API layer should not exist independently of how the application consumes information. GraphQL gave Finanion flexibility to request the data required by different experiences.
UX and engineering should not operate as isolated phases
Keeping UX moving while UI development begins can significantly reduce delivery time. It also creates a tighter feedback loop between design and implementation.
Automated testing becomes increasingly valuable as the UI grows
Manual testing remains important. Automation provides repeatability and confidence as the application changes.
Financial UX is also trust engineering
When users are looking at their money, investments, insurance, loans, and financial plans, clarity matters. A confusing interface can undermine confidence even when the underlying technology works perfectly.
What Does It Take to Build a Financial Web Application?
A modern financial web application typically requires much more than frontend development.
It needs a combination of:
Product and domain discovery
UX and UI design
Information architecture
Financial data modeling
Database architecture
API development
Frontend engineering
Responsive and mobile-friendly design
Automated and manual testing
Security engineering
Cloud infrastructure
Analytics and reporting
Ongoing product evolution
The technology stack will vary depending on the requirements.
For Finanion, the stack included React, Next.js, Tailwind CSS, Hasura, GraphQL, PostgreSQL, Playwright, Nhost, and Vercel.
The important part is not the number of technologies. It is how those technologies work together to solve the product problem.
How Does CreoWis Approach Financial Product Development?
Finanion is an example of how we approach product engineering at CreoWis. We do not see UX, architecture, and development as independent services that are simply handed from one team to another. They are interconnected parts of the same product development process.
Our capabilities span:
Product and UX
Financial product UX, information architecture, user journeys, responsive design, design systems, and complex data visualization.
Software Engineering
React, Next.js, API development, GraphQL, databases, cloud infrastructure, testing, and deployment.
For companies building financial products, fintech platforms, personal finance applications, financial dashboards, or related digital products, this combination can be particularly valuable. Because the hardest part is rarely just writing the code.
It is understanding what the software needs to accomplish and then designing the right experience and architecture around it.
Final Thought
Finanion started as a problem of capturing and presenting financial information.
It evolved into something more useful: a platform that brought financial information together, helped users understand it, and introduced analytics and prediction to support better planning.
That evolution is representative of what happens with many real products. Requirements change. Users reveal new needs. Data becomes more valuable when it can be interpreted. And architecture has to evolve with the product.
The technology matters. But the real differentiator is knowing why you are building each part of the system.
At CreoWis, that is how we think about product engineering. Understand the domain. Simplify the experience. Design the architecture. Build the product. Measure the impact.
If you are building a financial web application, fintech MVP, personal finance platform, financial dashboard, or another complex digital product, the same principle applies. Start with the problem. Then build the technology around it.
I hope it was helpful. If you want to understand more about us and the work we do, these links will be helpful:
Browse our projects and learn how we approach problems, build solutions, and deliver meaningful outcomes: https://www.creowis.com/resources
