DEV Community: Cesare Bramante

Every revision made my app spec better. The fix was one rule about data.

Cesare Bramante — Wed, 14 Oct 2026 04:28:03 +0000

I shipped a native app on both stores, in five languages, on my own, with a general-purpose AI as my developer. Between my first prompt and the first screen that did what I wanted, there were six versions of a "master prompt". This episode is about those versions, and about why the fix I needed wasn't in any of them.

In the first episode I told how the AI took my first line literally: I wrote "share your position", and it gave me a map of friends. This is what happened next.

The master prompt

Every chat with an AI starts from zero. So from the first week I kept one document that I pasted at the start of every new session: what the app is, who it's for, how it works, which decisions are already made. I called it the master prompt.

It changed nature faster than I expected:

January 26: vision, user flow, colors. Basically my first prompt plus the AI's answer, cleaned up. One line in capitals that I still like: "remove the word 'invite' completely".
February 13: a technical spec. Tables, pages, triggers.
February 18: the same spec rewritten in FlutterFlow's own vocabulary: page state, actions, conditional visibility.
The same day, seven minutes apart: a new version "synced with what I actually built in the editor".

That last one was the real change. The master prompt stopped being a description of what I wanted and became a photo of what existed. An AI that reads a wish will build the wish. An AI that reads a photo will start from where you are.

By spring I had two branches of the document, numbered in a way that makes no sense today (a v4.0 in March, then a v3.2 and v3.3 in April and June). More on that in episode 5.

The spec that ran every ten seconds

In late January the AI generated two files for me and called them FlutterFlow exports. The simple one had exactly the five screens it had recommended. The "advanced" one had this:

"actions": {
  "update_live_location": "runs every 10 seconds",
  "share_location_event": "writes to locationShares",
  "join_event": "adds user to events.participants"
}

Plus friends' pins on the map, a live location field on every user, and a collection to share your position with an expiry.

Three problems, in increasing order of importance:

Battery. A position update every ten seconds is the fastest way to get uninstalled.
Stores. Both stores are strict about location in the background as a main feature. The app would have had a hard time getting approved.
It was the app I didn't want. People on the map, not events.

And a fourth one, smaller and funnier: the file couldn't be imported in my version of FlutterFlow, and in the same configuration it mixed a Mapbox style address into a MapLibre map. A spec that looked perfectly plausible and couldn't run anywhere.

I also tried FlutterFlow's own AI

In February I tried FlutterFlow's built-in page generator for the first screens. One of my prompts started with:

Create a map UI like Zenly.

Zenly was the best-known app for seeing your friends on a map. So I was asking a second AI to build, again, the version of my idea I didn't want. The generator was quick for empty layouts. I didn't like what it gave me, so I built the pages myself in the editor. The logic code came from the general-purpose AI, and FlutterFlow compiled it.

The fix was one line about data

Rewriting the pitch didn't change the direction. Every new answer still leaned on "position". What changed it was a rule in the data model.

On February 13 a line appeared in the spec: no position saved outside an active event. On February 18 the users table no longer had any location field at all. A position existed only as the place of an event, and the event had an expiry date. The cloud database became, in the words of that spec, a bulletin board for pins on a map.

After that, the AI could not drift back even if it wanted to. There was simply nowhere to store where a person is. You can argue with an AI about intent for weeks. A missing field ends the argument.

The revision loop that came later

The real cycles of revision started in April, with a working app and a second AI reviewing the code. In one week:

April 22: first audit;
April 23: nineteen fixes;
April 24: second audit, 23 problems;
April 26-27: final audit before release, 31 bugs;
April 30: verification. Eleven of the thirteen "pending" fixes were already in the code.

The documentation was behind the code, not the other way around. From then on the rule was: when the code and the document disagree, the code wins. And one more, learned the hard way: a fix declared "applied" must be checked against the previous export, because one of them had introduced a new bug.

To keep the document up to date I ended up with a very short prompt, which I still use (translated from Italian):

Scan <chat> and <audit>, extract every fix and decision.
Output: ONLY a diff 🟢/🟡/🔴 per section. No preamble. Nothing unchanged.
Priority: audit > chat > document.

What I took from it

Revisions improve the form of a spec. They rarely fix its intent.
If your idea goes against the common version, put it in the data model, not only in the description. A rule on data is the one thing the AI can't reinterpret.
Keep your main prompt as a photo of what exists, not a list of what you want.
When the code and the document disagree, believe the code. Then fix the document.
A generated spec has to be read line by line. "Every 10 seconds" was right there.

Next episode: the first sketch. Colors, a font chosen on day one, a logo I threw away, and five languages that turned out to be the hardest part.

I'm building orbiTome solo, with FlutterFlow and Firebase. More at orbitome.com.

I gave an AI my first app spec. It cut half of it and took the other half too literally

Cesare Bramante — Thu, 08 Oct 2026 07:58:06 +0000

A native app on both stores, in five languages, built by one person with an AI as the developer. This is how it started: the day an AI took my first spec apart.

"Computers are good at following instructions, but not at reading your mind." Donald Knuth, 1984

Forty years later, it turns out this is still true when the computer is an AI.

I'm a solo developer. I didn't write the app the classic way: a general-purpose AI was my developer, and FlutterFlow was my compiler. This series is how that went, from the first prompt to the stores, including the parts that didn't work.

This first episode is about the idea, and about what the AI did to it.

Who I am, briefly

I'm 56 and I come from IT. I started as a computer technician, then worked as an IT security consultant, then spent years building web portals. For a while I also taught at university as a subject expert, without a degree. So I'm not new to software, but I had never built a mobile app. I work alone, and the app is meant for people a lot younger than me.

Where the idea came from

Having kids, and looking around me, I had the feeling that people see each other less. Not because they don't want to, but because organizing anything takes a group chat, fifty messages and a decision nobody wants to make.

And most social apps push the other way. They are built to keep you on the phone, and they reward showing a life other people can't reach. I wanted an app you open in order to put the phone down: you see where something is happening, you go.

I looked for an app that did this. Some had been born, had an early success and then closed. Others were very niche: only parties, only sports, only public events. Nothing for the simple case: a few friends who want to meet tonight.

So I installed a bunch of these apps, used them for a while, and in January I wrote my first prompt, to Gemini.

The first prompt

My original prompt to Gemini, January 2026 (in Italian). The first line says "share your current and future position".

It was a full spec. Contacts imported from the phone and turned into tags. Three states for every event: "I'm here", "I'll be there", "I'd like to go". Email invites for people without the app. A cloud backup. Five languages to pick from at install. A color palette, a font, even the ad banner position.

Reading it today, it's a wish list. And the first line has a problem I didn't see at the time.

What the AI told me

The beginning of the AI's answer (in Italian). The bold line at the end is the rule I still use.

The answer started kindly and then went straight to the point: the idea was clear, but too complex for the value people would perceive. The user had to understand too much before getting anything back. And then one sentence that I still use as a test for every new feature:

In 30 seconds I must be able to say "I'm here" and invite someone.

Then it went through everything. Onboarding in three steps at most. The map as the home screen, not as a feature. Tags that look like groups with an emoji, not like a database field. Invites through a link you can paste in any chat, with email only as a fallback. Cut the manual backup, cut the advanced history, use the system language.

It also took my first line at face value. I had written "share your position", and it built on that: friends' avatars visible on the map, a "social map" where you see who is going where, a live "I'm here" position with a two hour timer. To be fair, that is exactly what my words said. It wasn't what I meant.

What survived, and what didn't

Looking at the app that is on the stores today:

Kept: the map as the home screen, with different pins for different kinds of plans. The invite link, which became the most important feature: whoever opens it sees the place, the time and who's coming, even without installing anything. Tags became groups, and you can filter the map by group. Every event got a QR code. A ghost mode, although today it means something else: the event is visible only to the people you invited. And "I'd like to go", which became the Wish: you post an idea and see who's in before organizing anything.
Kept, but moved: the idea of a timer. It's no longer on my position, it's on the event: an event leaves the cloud shortly after it ends.
Refused: the advanced history cut. I kept the history, but it stays on the phone, not in the cloud.
Dropped, further than the AI suggested: email invites. The AI wanted email as a fallback; I removed it completely, because people get too many emails and ignore most of them. I looked at SMS too, but it felt archaic and every message costs money. And sending invites through messaging apps meant the answers would come back scattered across different chats, with no way to collect them. A link solved both problems: it travels in any chat, and you see who's coming in the event, not in a thread.
Dropped: the viral mechanics. Some were mine (invite three friends to unlock premium), some were the AI's (badges).
Refused outright: people on the map. It was the one thing I was sure about.
Ignored, then came back to: languages. I wanted five, and I kept five. But at first I only filled in FlutterFlow's language panel, and it turned out to be a dead end: snackbars and alerts weren't translated. Today the app follows the localization of the device, with English as a fallback for the few strings I missed. Not far from what the AI had suggested on day one.
The part I only understood later

The cuts were the easy part. The real lesson was in the first line.

"Share your position" is what location sharing apps do, so the AI gave me the most common version of that idea, and every following answer built on it. What I wanted was almost the opposite: show where things happen, not where people are. The AI read my words, not my intent. It took me months, and a lot of rewriting, to make the spec say what I meant.

What I took from it
A first spec is a wish list. Writing it is useful; building it as it is, isn't.
AI is very good at cutting. It has no attachment to your features.
AI fills every ambiguity with the most common version of your idea. If your idea goes against the common version, say it in the first line.
The 30-second rule works for every screen, not only for onboarding.
Some of its cuts were right, some I refused, some I had to undo months later. It didn't know my users, and it couldn't.

Next episode: the revision loop, and the day a generated spec put my friends' live position on the map every ten seconds.

How I made events (and their data) expire in a FlutterFlow + Firebase app

Cesare Bramante — Thu, 01 Oct 2026 13:37:22 +0000

Most apps are built to remember. I wanted to build one that forgets on purpose: as little as possible left in the cloud, and what's worth remembering kept only on the phone of the person who lived it.

I'm an indie developer, and I build orbiTome. You drop an emoji pin on a map, pick a time, invite people from your contacts, and meet up. It's built with FlutterFlow and Firebase, and it's live on iOS and Android in five languages.

One design rule shaped most of the backend: an event should leave the cloud shortly after it ends. Plans with friends usually live in group chats, and group chats keep everything forever: where you were, when, with whom. I wanted the opposite. The map shows events, not people. When the event is over, its cloud document is deleted together with the guests' replies. Your own history (what you created, what you joined, the photos you took) stays on your phone.

This post covers how that works in practice, and what I'd tell anyone trying the same thing in FlutterFlow.

1. "Expires" is not one number

My first version had one rule: delete the event two hours after it starts. It didn't survive, because events aren't all alike.

When you create it	Starts	Expires
Now / In 1 hour / In 2 hours	the chosen time	start + 2 h
Tonight	21:00 (if that's past, in 3 hours)	23:59 the same day
Tomorrow night	21:00 tomorrow	23:59 tomorrow
Pick a date	chosen date and time	start + 4 h
Wish with a time ("anyone up for a hike Saturday at 9?")	the proposed time	at the proposed time, no buffer
Wish, no time set	none	7 days after posting
Public event from an organization	set by the source	end set by the source, or start + 4 h; never more than 30 days

On top of the table, two rules apply to every event created in the app:

Ceiling: no event lives more than 6 hours past its start. (A Wish with no date has no start, so it isn't affected.)
Floor: no expiry falls less than 2 hours from now. A Wish set for 30 minutes from now still lives two hours.

The expiry in the table is a default, not a promise. While the event is running, the app checks the organizer's position every time the app is open on their phone, never in the background. If the organizer is within 50 meters of the pin and the expiry is less than 30 minutes away, the expiry moves to one hour from now, as many times as needed: a meetup that runs long doesn't vanish halfway through. The 6-hour ceiling still applies. It also works the other way: if the organizer checked in and then moves more than 150 meters away, the event ends there, or after a 30-minute grace period if someone else is still on site. Wishes are never extended or closed this way: they're intentions, not places.

A plan for the evening that starts at 21:00 shouldn't vanish at 23:00 while people are still out. An unanswered Wish, on the other hand, is a loose proposal: it has no reason to exist past the moment it was about. If someone replies and the creator confirms, the Wish becomes a real event and its expiry is recalculated: start + 2 h.

I didn't design the ceiling and the floor on a whiteboard. Each one came from a bug.

The floor. A Wish created with "Now" had its expiry equal to its start, which was now. It was born expired and disappeared from the map without any error. When I tightened the security rules, the same creation started getting rejected. An expiry that isn't in the future is always a mistake, so now there's a two-hour minimum.

The ceiling. "Tonight" picked after 21:00 starts the event three hours later, after midnight, and "23:59 of the start day" became 23:59 of the following night: an event starting at 1:30 stayed alive for 22 and a half hours. The 6-hour ceiling closes that case, and other parts of the app (check-in, photos) can rely on it as a rule instead of an assumption.

A third bug was about languages. The code recognized "Tonight" by comparing the button's label, and in French, Spanish and Romanian it never matched: in those languages every "Tonight" expired after 2 hours. Now the visible label, in any language, is first mapped to a stable code (tonight, tomorrow, pick…), and expiry is computed from the code. With five languages, no logic should depend on a string the user can read.

The lesson: decide expiry per type of plan, not per database. It also changed how I write the app's copy. I no longer say something "disappears after 2 hours", because it isn't true for every event. What I can say is that an event leaves the cloud shortly after it ends.

2. Where the expiry is computed

The expiry timestamp is computed when the event is created, by a small FlutterFlow Custom Function, and stored in the event document as expires_at. After creation, only two other places change it: turning a Wish into an event (start + 2 h) and the on-site check while the organizer has the app open (extend or close). All three respect the same 6-hour ceiling; everything else only reads the field.

Computing it at creation keeps everything else simple. The map queries, the cleanup and the invite page all read one field, and none of them re-implements the rules.

The trade-off is that the client computes the value. The security rules don't recompute it, but they constrain it: on create, expires_at must exist, must be a timestamp, must be in the future and no more than 400 days out, and the same cap applies on update. The 6-hour ceiling lives only in the client, so a tampered client could keep its own event online for up to 400 days. It's a known limit, and I accepted it because it only affects the person doing it.

The "must be in the future" check wasn't there from day one, for a specific reason: security rules also apply to the old app versions still installed on people's phones. I only turned it on once the version with the 2-hour floor was effectively the only one in use. Before that, it would have rejected events created by older versions.

There's one exception. Some events are public and come from city bodies, non-profits and public institutions. They are never created from the app: they come in only through a dedicated web portal, via a private Cloud Function that writes with admin privileges and sets expiry server-side (the end given by the source, or start + 4 h, and never more than 30 days). The security rules reject any client write that tries to create an event in that category or convert an existing one. In short, the client decides expiry only for its own private events.

3. Who actually deletes the data

Two mechanisms, with two different jobs.

The first is a scheduled Cloud Function that runs every 60 minutes: it looks for events whose expires_at has passed and deletes them in batches. In practice an event leaves the cloud within about an hour of expiring.

The second is a Firestore TTL policy on the same field, as a safety net: if the function misses a run, Firestore deletes the documents anyway. On its own it wasn't enough for me. Google's docs say expired data is "typically deleted within 24 hours", and until then expired documents still show up in queries.

That's why every query that shows events filters out those whose expires_at has passed, and the client drops them again before drawing them. "Expired" and "deleted" are two different states: the UI hides an event the moment it expires, even if the backend removes it later.

What goes away with the event:

Guests' replies and scheduled reminders. A function triggered on the document's deletion removes them, whatever the cause: the creator deleting the event, the hourly cleanup or TTL. One cleanup point instead of three. Before it existed, replies to deleted events stayed in the database forever, because the security rules (rightly) don't let the creator delete other people's replies.
The guest list, which is a field of the document itself.
Subcollections (for example game data inside an event). Firestore doesn't delete them with the parent document, neither on a normal delete nor through TTL. So each of their documents carries its own expiry, slightly after the event's, with its own TTL policy.
Files in the cloud: none to delete. Event photos and videos are never uploaded (see section 4). Firebase Storage only holds profile pictures.

The rule I took from this: for every piece of data born around an event, ask who will delete it, and when.

4. Keeping history without keeping it in the cloud

Events leave the cloud, but people still want to remember them. So the events that involve you are copied into a local SQLite database on your phone, which I call the Vault.

For each event the Vault keeps the title, emoji, date and time, place name and coordinates, description, organizer's name, your role and your status ("I'm here now", "I was there", "Cancelled by the organizer"). It doesn't keep the list of participants.

The copy is created right away, not at expiry, because by then the cloud document may already be gone:

when you create an event or a Wish;
when you reply "I'll be there";
when you get an invite, but as a provisional copy: if you don't reply, it goes away after the event starts, unless you checked in or added photos. If the organizer cancels before the start, it stays marked "Cancelled by the organizer" for 7 days;
when you open the app on site, check-in moves your status to "I'm here now" and then to "I was there".

Why not Firestore's offline cache? Because the cache mirrors the server: when the event is deleted in the cloud, it disappears from the cache at the next sync. And the cache isn't an archive anyway, Firestore prunes it on its own. I needed the opposite: a copy that outlives the server document.

The Vault can leave the phone only as an encrypted backup that the user saves wherever they want.

Event photos and videos follow the same logic. They go into the app's private folder, not the gallery. Before saving, metadata is stripped, location included, and if it can't be stripped the file isn't saved. They're never uploaded, nobody else sees them, and they stay as long as the event stays in your Vault: delete it, or sign out, and they go with it. The encrypted backup doesn't include them.

Three FlutterFlow + SQLite lessons that cost me hours:

In SQLite queries defined in the FlutterFlow panel, parameters must be written as ${name}. FlutterFlow doesn't pass arguments to the query, so ? placeholders stay empty and the WHERE filters nothing: no error, just wrong results. Careful, though: ${name} inserts the text as-is, it's not a real bound parameter. An apostrophe in a search term breaks the query, so escape it. In Custom Action Dart code, ? with an argument list works normally.
Migrations. CREATE TABLE IF NOT EXISTS doesn't change a table that already exists, and the database bundled with the app only applies to new installs. Users who update need ALTER TABLE with nullable or defaulted columns, a check that the column doesn't already exist before adding it, and a schema version (I use PRAGMA user_version) that only moves forward when the step succeeded. Users update from different versions, and a restored backup can carry an older schema than the installed app.
Panel queries are for reading. FlutterFlow runs the SQLite queries from the panel with rawQuery, which is meant for reads: an INSERT, UPDATE or DELETE written there fails silently. Writes belong in a Custom Action, with rawInsert, rawUpdate or rawDelete.

An unplanned side effect: reading history from SQLite instead of Firestore takes the Vault's reads to zero. That matters on the free tier, and it matters more as users grow.

5. What happens to the invite link

Every event has a link that works without the app: whoever opens it sees the emoji, title, organizer, place, time with a live countdown, and how many people confirmed. The page is served by a Cloud Function that asks getJoinPreview for the data (an endpoint that returns a closed list of fields, one read per open) and rewrites the Open Graph meta tags. WhatsApp, Telegram and iMessage don't run JavaScript, so without that step link previews would only show generic text.

Anyone with the link sees the preview, even without an account, so the link should only go to the people you want. Inside the app, the event stays visible only to the organizer's contacts or, in Ghost mode, only to the invited guests.

After expiry:

in the app, opening the link of an expired event shows "This event has ended." and a "Propose again" button that starts a new event from it;
on the web, between expiry and deletion (about an hour at most), new previews say "This event has ended." instead of organizer and place; the title with the date stays;
after deletion, getJoinPreview answers that the event doesn't exist and the link shows orbiTome's generic invite page, with no event data. A CDN-cached copy can survive two minutes at most.

One last thing deserves a check in any app like this: a link preview already pasted into a group chat keeps showing title, date, organizer and place, because the chat stored the preview, not your server. You can't take back what's already been shared. You can only stop serving it, and decide from the start what goes into the preview.

6. What I'd tell someone starting today

Decide expiry per type of plan, write your copy to match, and don't promise a fixed number of hours.
Store one expiry timestamp at creation, with a ceiling and a floor. Keep the places that can change it few, make them all respect the same ceiling, and let everything else just read it.
Compute on codes, not on translated labels.
Hide data on expiry, delete it later, and filter in every query. Firestore TTL is a great safety net, but if latency matters, pair it with a scheduled cleanup.
For every piece of data born around the event (replies, reminders, subcollections), decide who deletes it.
Tighten security rules only when the client version that respects them is the one almost everyone runs.
If history matters, copy it to the device when it's born, not when it's about to disappear.
Check what shared links show once the data is gone.

Building an app that forgets turned out to be harder than building one that remembers. But it changed how I explain the product: "the event ends, and so does its data" is something people get in one sentence.

I'm building orbiTome solo, with FlutterFlow + Firebase. If you're working on something similar, I'd love to compare notes in the comments. More at orbitome.com.