---
title: "From AI to Finished Products: FinTech Case Study"
description: "My experience in creating a web platform and iOS application from scratch using new technologies such as Cursor, Claude, v0, Trae, etc."
slug: from-ai-to-finished-products-fintech-case-study
publishDate: 2025-01-14
author: Igor Dobzhanskiy
tags: [Case Study, FinTech, AI Tools]
---

Technology is developing so rapidly that even now (a couple of months after starting work on the app), I could have completed most of the project much faster and easier. But the most important thing I gained from this project is experience, which I want to share with you.

It all started with the fact that I can't stand Excel spreadsheets. But somehow you have to keep track of your finances, and given the large number of subscriptions, as well as various income and expenses, it's difficult to understand how much money you have right now. So I thought it would be a good opportunity to practice my vibecoding skills and solve a personal problem at the same time — to remove Excel from my life.

## The Traditional Design Approach

As a true product designer, I started with familiar design processes. Now I understand that this only took my time, and I should have immediately worked through AI tools. But why exactly — I understood later.

*Initial design exploration: moodboard, branding concepts, and ideation phase*

The only benefit I got from the research was discovering many similar applications that seemed to do the same thing but had so much additional functionality that they were simply inconvenient. My idea was much simpler: I just wanted to understand how much money I have, how much I spend monthly on recurring expenses (subscriptions, rent, utilities, etc.), and how much income I receive from various sources (work, business, advertising).

Well, as I already wrote, it was a way to learn how to create products from scratch using only AI tools, so I didn't plan to do anything super complicated (there was something complicated in the following products, but more on that another time).

## Creating the Product Documentation

After developing the design concept, I decided it was time to create a detailed prompt for my AI tool. Having learned from my previous mistakes, I realized that a prompt like "make it beautiful, don't make it ugly" wouldn't work, so I went to someone who could help me describe what I wanted in understandable language.

I started working on this project before I knew about Claude, so I prepared the documentation through Google AI Studio. I can't say anything bad about this tool: it handles both code and technical documentation very well. Now you can even make full-fledged prototypes and toys there, and it has a large free limit.

*Application design concept*

I started by asking him to prepare a PRD for AI Tool v0.

In general, to create the first MVP, you need to describe:

- Problem Statement,
- Target Users,
- Solution Concept,
- Core MVP Features.

Overall, for the best results, AI needs to understand the reasons and specifics of the project in order to make the best decisions. I also decided to describe the essence of the product and the user flow to the AI and show it the screens as I saw them. The screens were simpler than the design concept because, in my opinion, it would be easier to add features and UI goodies after the prototype was ready — which, in general, turned out to be completely true.

*Detailed PRD documentation with visual style guide and technical constraints*

It is also important to note that at the very beginning of the project, I did not plan to create an iOS app — it seemed too difficult for me. Therefore, I decided to develop a simple web platform, but with a mobile-first approach. I planned to store data locally (then I changed my mind because Trae suggested how to make it easier and better, but more on that later — we're just getting started).

## The First Prototype with v0

From my experience, I can say that if you want to create products using AI — never try to shove all the functionality into your idea at once. There's a high probability that AI will misunderstand you and create something terrible.

*My first mistake: the prototype without proper UI elements looked nothing like my design concept*

Yes, I completely forgot to add any UI elements (gradients, icons, etc.) to the prompt and got a prototype that looked nothing like my design concept. BUT it worked! It actually counted my money, and except for some problems with not being able to view the calendar, everything worked great.

I could add subscriptions and income that directly affected my balance. For me, it already seemed like magic, but I didn't stop there. I'm a designer — how could I not want to make it beautiful?

## Iterative Improvements

My next step was to add a calendar and slightly improve the UI. Again, I did everything step by step, afraid that AI couldn't handle a larger amount of information. Considering the current capabilities of AI tools, this isn't necessarily true. For example, I recently used a 74-page prompt for one of my projects — and yes, the AI handled everything. But back then, either it didn't work that way, or I just didn't know about it.

*Gradual UI improvements: adding calendar and styling components*

So from then on, I simply updated component by component, explaining almost like to a child. I asked to add stroke to tabs, redesign the button, etc. With each prompt, I added a screenshot from Figma showing exactly how I wanted it to look. I also gradually added logic that would make my life easier (for example, the date when this subscription should be canceled).

*Intermediate result: getting closer to the final design*

## Currency Conversion API

The next challenge was currency conversion — I understood that this required a special API, but I didn't know exactly how it worked. But after searching the internet a bit and delegating the responsibility for connection to AI, I got the result I wanted: fully working conversion according to the current exchange rate.

*Connecting the National Bank of Ukraine API for real-time exchange rates*

There were many iterations and fixes to set up the needed UI. And so, after 42 versions — that is, 42 prompts — I got a result that I was already satisfied with. It was a fully working prototype that completely solved my problem. But it still didn't save data, so to solve this problem I decided to bring in heavier artillery — AI Code Editor Trae.

*42 versions later: the evolution of the prototype*

*Final result of the Web application*

## Enter Trae: The AI Code Editor

Trae AI is an AI Code Editor, i.e., a code editor with a built-in "smart assistant." Unlike v0 and similar platforms, Trae, like Cursor, allows you to edit code at a more professional level, almost like a novice developer (and sometimes even better).

The first question you might have: why not Cursor? Cursor already existed and worked very well at that time, so why not use it?

Actually, the answer is quite simple — since I was just testing these products, I didn't want to pay a lot for a subscription. And Trae offered a free version plus a subscription for only $3 per month. So my choice was obvious.

## Local Development and Bug Fixing

I'll say right away that Trae did everything incredibly well. From the first prompts and communication with Code Editor, all my doubts and fears disappeared. It turned out to be much easier than I imagined.

*Running the project locally and fixing bugs that v0 couldn't handle*

By the way, as you can see, I wrote prompts in quite ordinary language — as if I were communicating with a real developer, and it worked. Technical language isn't even necessary when working with AI Code Editor.

*Writing prompts in natural language — like talking to a real developer*

## First Steps with GitHub

And of course, my first acquaintance with GitHub: Trae really helped me understand how exactly it works and helped with connecting through a personal token. Now, of course, everything is simpler, but back then I didn't know that you could connect the tool directly to GitHub.

*Trae helped me understand GitHub and set up the repository*

## Database Integration with Supabase

Next was the plan to connect the database, and I chose the very easy-to-use Supabase. I must admit: Trae did everything very well and explained all the nuances of connection, as well as every step that needed to be done for everything to work.

*Step-by-step Supabase setup: credentials, environment variables, and deployment*

### Important Security Note

One very important detail I realized after I finished working with this product: never throw your secret keys into AI tools like this. This is done through a special .env file, which is added to .gitignore for local development. And in hosting like Vercel/Netlify there is an Environment Variables / Secrets section. And of course, don't paste the key in the prompt and don't ask the tool to "hardcode the key in the code." Generate the code so that it reads the key from env, for example: `process.env.EXAMPLE_API_KEY`. I strongly recommend that you familiarize yourself with this issue in more detail, as there have been cases where attackers have obtained vibecoder keys in this way and stolen money. Be careful!

*Complete guide for database persistence: Trae provided SQL code and step-by-step instructions*

And finally, the most interesting part of Trae — connecting the database. At that time, I didn't even know about Supabase, but Trae explained to me in detail what it was and how to work with it, and even wrote the code that I just had to insert where needed (he also explained where exactly). And so, after simple prompts and communication with Trae, I had a ready and working product with a connected database that was stored on my Google account and which I had access to (through this platform) from any device. Isn't this magic?

## The iOS Adventure Begins

But by that time my appetite could no longer be stopped: then I realized that I could develop more complex products and work not only with the web. Then I wanted to make a full-fledged iOS application. And here Cursor came in handy. Considering that it is more powerful than Trae, I was sure that it would handle the iOS app. But that's not where I started.

Since I had no idea how to even work with and run iOS applications, I started with questions to someone who always helps — Claude. Here I want to note a person without whom the integration of projects into Claude would have been much more difficult — this is [Volodymyr Merlenko](https://volomydyr.com/), because it was thanks to his prompt (which I slightly adapted for migration from web to iOS) that I managed to create detailed and structured technical documentation. Which became the basis for my iOS app.

*Claude Projects: organizing documentation, memory, and files for iOS migration*

*Detailed documentation and screenshots provided to Claude for context*

Unlike building the web version, I already had some logic developed, as well as part of the documentation, and, of course, ready-made code that Claude could read and understand the structure of.

## Creating the Cursor Context Package

After quite a long conversation with Claude, who suggested the best framework for working with iOS (I was choosing between React Native and SwiftUI and eventually settled on SwiftUI), I received a number of documents with all the necessary information. At this point, I have already clarified for myself the workflow with Cursor and Xcode (yes, you need your own tool to work with applications, because you can no longer run them locally via localhost, but more on that later).

*Complete Cursor Context Package: 7 documents with everything needed to build the iOS app*

And so, having created everything necessary, I created a folder on my desktop, added all the files there, opened this folder in Cursor, and started working.

### Key Learning: Agent Management

Here was the first mistake that you, hopefully, won't make — working in one chat (currently — agent). The thing is that each agent has an information limit that it can process, and if you communicate with it for too long, the limit runs out — and the agent starts to "forget" information it worked with earlier. This causes many bugs and inaccuracies.

Currently, I use different agents for different tasks: there are agents that fix the backend, there are agents purely for pushing to GitHub, and there are simply those that run localhost.

## Working with Cursor and Xcode

*Cursor reading context and building the iOS app phase by phase*

After finishing my work at Cursor, I started figuring out how to launch this app, and Cursor provided me with detailed instructions on how to integrate Xcode into my life.

In fact, it wasn't difficult at all: all I had to do was open the project (in my case, a folder on my computer) via Xcode, then simply run it locally (using the launch button in Xcode) and fix any bugs, if there were any: send them to Cursor and ask him to fix them. Essentially, Xcode was like a "server" where my code was stored and where it ran locally. I know that this is not a completely accurate description technically, but it makes the logic much easier to understand.

After launching the project in Xcode, I started implementing all the necessary logic and connecting all the needed databases and authorization. Well, not me... Cursor did all this (thanks to the detailed prompt from Claude).

Although, of course, I also had to get involved at these stages — for example, answering questions (which Cursor asked when he didn't know something, which, by the way, is a must-have in the settings of any project), or when it was necessary to work with third-party services such as Google Auth or Supabase.

*Cursor's actionable to-do list: systematic approach to building the iOS app*

## The Final Result

*Running the iOS app in Xcode simulator with SwiftUI code*

Of course, not everything was perfect: I had to test and fix a lot of things. But it was my first experience, and, in my opinion, everything went much easier than I had imagined. Cursor explained everything in detail, gave advice on how to fix mistakes, and fixed those mistakes himself as needed.

Overall, there was almost no difference between working with the web. If you don't understand TypeScript, then Swift will be like Chinese to you. But Cursor helps with everything, and after launching the project in Xcode, you can also visually see what's wrong. In general, working with Xcode was similar to working with Console in a browser: you looked at the errors that popped up, took a screenshot, sent it to Cursor, and it fixed everything, and so on.

*The final iOS app: native SwiftUI interface with full feature parity*

The result was a full-fledged iOS application that works, connects to a Google account, and pulls all the information from the database. This means that regardless of where I make changes — through iOS or through the web platform — all changes will automatically be pulled to the database if I'm connected to my account.

## Final Thoughts

Once upon a time this would have seemed like magic to me, because where would a designer go to develop working prototypes? But now this is our reality.

Of course, this was my first case, and there were many mistakes here that I wanted to write down so that you don't make them. Now I work more consciously, but I'm still happy to make mistakes — because it helps me move forward and feel incredible joy from learning.

Now I am working on other projects and have put this one on hold due to security gaps that I allowed at the beginning. But it is thanks to this project that I was able to learn what I know now.

I hope this article was useful to you and you took something interesting for yourself or simply got motivated to create something of your own. Thank you for reading, I'll be happy to hear your feedback! Learn, create, and enjoy what you do!