Leonardo Ferigutti - Full-Stack Developer

I built this project mainly to play with AI, my creativity, and my skills as a programmer.
This is not a step-by-step tutorial or a definitive guide. It’s simply a way to share how I approach a personal project today, in a world where AI is already part of the process.

The goal is to share the mindset, the decisions, and some of the mistakes, so it can serve as a reference if you’re building something yourself.

Exploring Ideas (Before Writing Any Code)

The first thing I did was brainstorm ideas with ChatGPT. In my experience, it’s still one of the best models for open-ended discussions. It has a lot of context about my professional goals, which makes it useful when you’re looking for direction rather than “correct” answers.

The key here is to use it as inspiration, not as an automatic idea generator. You need to ask, challenge, and iterate until something genuinely interests you.

This leads to the first important point:

If you’re not genuinely interested in the topic, you won’t have the motivation to push through once the novelty wears off.

After a lot of back and forth, I decided to build a role-playing game to explore the personalities of different startup roles.
This wasn’t random — I’m passionate about startups, and I currently work at one in Munich, Germany.

Planning the App (Thinking Before Coding)

Once the idea was clear, I moved to one of the popular IDEs at the time (Cursor) and started planning the app.
I created a simple .md file describing the core idea, the user flow, and a first version of the infrastructure.

I knew I wanted to use FastAPI for the backend and React for the frontend. Other stacks would have worked just as well, but I wanted to go deeper into FastAPI, so it was a personal choice rather than a purely technical one.

Backend: Collaborating with AI, Not Delegating Judgment

Since I’m more of an engineer than a designer, I started with the backend.
Here, I alternated between my own code and code generated by the agent. When I felt comfortable with the framework, I wrote things myself and used autocomplete as support.

When parts became boring or repetitive, I delegated them to the agent, for example, setting up SQLite or generating boilerplate.

Agents are great for tasks that are boring or repetitive, especially when you already know how they should work.

That said, I always reviewed the generated code to make sure it made sense. I also enforced test generation.
To be honest, most of the endpoint tests were generated by a model, and my role was to check coverage and, more importantly, whether the tests were actually meaningful.

Frontend: Using Tools Without Losing Control

For the frontend, since I’m not a designer, I looked for inspiration using tools like v0 or Lovable.

Before jumping into those tools, I used a Cursor agent to generate a clear .md describing the app and the intended UX. That document helped avoid generating random screens without direction.

From there:

I generated a visual starting point
picked a base design
and continued working locally

I know it’s possible to “vibe-code” entirely online, but I prefer working locally and building from there. I’ve never liked putting all my eggs in one basket.

From that visual base, I connected the backend and frontend and refined the features needed for the MVP.
That iteration cost me a lot of tokens and many hours, but that’s where you really learn how to work with AI and stay critical of what you generate together.

Final Product: Thinking Like a User (and a PM)

I played the game myself and kept polishing UX details as issues appeared.
This is where being your own manual tester matters, and where you inevitably have to think like a product manager — something I mentioned in the previous post.

Once I was happy with the result, it was time to ship.

Deployment (A Personal Choice)

There are many ways to deploy an app today. In my case, since I have experience with self-hosting, I chose:

a VPS on Hetzner
Cloudflare for the domain
Coolify to manage deployments

That required creating a Dockerfile and serving the frontend as static files from the API root.

This is not the easiest setup, and it’s definitely not what I’d recommend to everyone.
If you’re starting out, Vercel, Firebase, or similar platforms are more than enough. It’s very unlikely your app will reach a scale where infrastructure costs matter early on.

Sharing the App

Once the app was online, I shared it with friends and people I trust to get feedback. I also posted it on Reddit and Twitter/X.

I don’t have a strong community yet, which is crucial for fast feedback and iteration — but that’s part of the journey.
If you want to try it out, you can find it here:
👉 Startup Role Simulator

Conclusion

This is just one way to build projects today. There are many others, all with their own pros and cons.
Personally, I’m curious to try other tools like Claude Code and compare that more explicit pair-programming approach with the one I used here.

The goal is to keep experimenting, iterating, and refining until you find a workflow that fits you and your style.

Thanks for reading.