Mobile Apps

The prompt template to vibe code a Flutter mobile app

I have decided to vibe-code a mobile app for debt tracking. I did not want to write the whole prompt from scratch, so I looked around for prompt templates that I could re-use and adapt for my needs — but I could not find any. So… I just did it myself. I this article, I'm sharing with you the prompt I wrote and that you can reuse and adapt to your needs

• By nasser •

Peef - My Debt Tracker - Prompt

The prompt start here, you can give it to any LLM.

You can find the explanation video here : https://youtu.be/on15s9k1hG4

Let’s develop together a flutter mobile app based on the attached screenshots (mock)

1. Dev Environment

  • Target OS: Android Mobile (priority) and iOS (future)
  • Flutter version (command flutter doctor)
    • Flutter : Channel stable, 3.38.3, on Debian GNU/Linux 12 Android SDK version 36.0.0
  • IDE: I have android-studio installed

2. The App

  • The app is a debt tracker
  • Name: My Debt Tracker (dev.peef.my_debt_tracker)

3. Here is how it works (functionalities)

John Doe can take 5 eur to me and give it back in one week

then he can return 3 eur

the rest will be 2 eur

then he can take again 10 eur

the total will be 12 eur

then he give back and so on

i can also take money from people, with same process as john doe to me

Example sequence:

  • 2025-11-01: John takes 5 EUR → Transaction TAKE +5.00 → John's balance = +5.00 (he owes me 5)
  • 2025-11-08: John returns 3 EUR → Transaction RETURN -3.00 → John's balance = +2.00
  • 2025-11-10: John takes 10 EUR → Transaction TAKE +10.00 → John's balance = +12.00
  • 2025-11-15: John returns 15 EUR → Transaction TAKE +15 → John's balance = +3 → My balance to John = -3 (I owe John)

balance is always equals sum of transaction amounts

Balance semantics: positive = they owe you; negative = you owe them.

4. Regarding design (UI)

  • It should use emotional design with warm and soft color palette
  • should prioritize clarity over density
  • It should show micro-notifications after actions 
  • users see themselves as someone who is improving financially

The colors should be as follows based on the interaction and screen

  • Primary - Calm Blue - #4A90E2
  • Secondary - Soft Green - #5FBF8F
  • Background - Off-White - #F7F9FA
  • Card/Surface - Light Gray - #E1E6EA
  • Text Primary - Dark Slate - #334155
  • Warnings - Soft Red - #E56C70
  • Accents - Soft Peach - #FED7C3

UI should use Material design with simple icons (simpleicons.org)

5. User experience (UX)

For UX, the app should tell by itself, it should be easy to use.

There should be no possibility to delete or update an entry: therefore, the user should confirm before saving. To correct mistakes, create an ADJUSTMENT transaction with reason.

No onboarding flow; UI must be self-explanatory with inline contextual hints

Confirm before save behavior: every new transaction shows a confirmation screen summarizing person, amount, type, date, note. After confirmation, show a micro-notification toast (Provide Undo temporary action for the last action.

Accessibility: support Roboto font size, buttons with labels, and color contrast.

It should support english (default language), french and german

it should respect privacy, there should be no authentication, no cloud sync, no push notifications.

6. Regarding architecture

Use Provider for state management and separate UI from business logic

For database it should use sqflite with explicit migrations and the data should be stored in the user device (local storage with sqlite)

7. Data model tables

  • User (me)
  • Person (who take a give me money)
  • Currency (default EUR, USD and FCFA)
  • Transaction: id, personId, amount (decimal), currencyID , type (TAKE / RETURN / ADJUSTMENT), date, note, createdAt
  • Required fields per model (IDs, timestamps, currency, locale).

Transactions are appended (sum of all transactions for use). No deletion or update of transactions; allow corrections as a new ADJUSTMENT transaction type.

Rounding currency to 2 decimals.

8. Important to take into consideration

I’m on debian, do not hesitate to give me commands and code i will just copy paste as i’m in the browser, do not create any artifact too

Note that as 9+ years of experience in python dev, i’m a newbie in mobile app dev

The demo data to use for development should be 3 people, 10 transactions.

We should go step by steps, screen after screen, do not do all at once

Attached are the screens with their name and priority of implementation

Provide a "hello world" architecture first (minimal app, Provider architecture, simple DB helper, demo data). 

Then implement screens one-by-one (screen_1 → screen_6) per attached mock priority.

then the UI/UX and then the business logic

we will start with screen_1, then 2 until 6