DEV Community: Cesare Bramante

Several AIs, one app: the rules I wrote because they all remember things wrong

Cesare Bramante — Thu, 12 Nov 2026 10:36:59 +0000

I built a native app with several AIs. The most useful thing I wrote in the whole project wasn't code. It was a short list of rules about not trusting their memory.

In the last episode I told how most of my bugs started with a word and not with code. This one is about working with more than one AI: who did what, what went wrong and the method that came out of it.

Who did what

January: Gemini. The first prompt, the first analysis, the first ideas.
February: Gemini writes the code. The first custom widgets and functions came from Gemini. I also tried FlutterFlow's own page generator, as I told in episode 2. I dropped it.
March: Claude becomes the backbone. Funny detail: the first time Claude appears in my notes, it's because another AI recommended it for writing texts (privacy policy, onboarding, notifications). By April it was reviewing the code. By June the main working prompt was written for Claude.
Cross-checks. I kept asking the same question to other AIs. Gemini stayed my source of creative proposals: in spring it suggested QR codes, recurring events, an automatic check-out and an escape-room style game. Some of those ideas came back months later in a different shape. I also tried ChatGPT. For what I needed it was too agreeable and not concrete enough. A project like this needs someone who tells you when you're wrong.

Gemini's ideas were often new and interesting. Claude had a better view of the whole project and stuck to the rules I had set. In the end I had one AI as the main developer and the others as reviewers and idea generators.

The handoff document

The core of the method is a document I call the handoff: the state of the code, the decisions, the limits I discovered and a changelog. Every working session starts by loading it, together with a fresh export of the project.

It grew with the app:

When	Size	Sections
June 1	300 KB	57
mid September	976 KB	n/a
October 4	721 KB	143

At almost a megabyte I had to condense it. The document itself was becoming the problem.

When the AI connected to the project

In May I connected the AI directly to the FlutterFlow project through MCP. It could read pages and apply small changes itself. The first batch went well: fourteen fixes applied that way. Then one write corrupted a custom code file. New rule, still valid: the AI can read the project and change settings, but custom code is pasted by me, in the editor, every time.

The worst AI mistake

In the same weeks a chat produced a new version of the file with my push notification functions. It looked complete. The functions were there, with the right names. Their bodies were empty, with only a comment saying where the logic should go.

Deploying it would have replaced working functions with functions that did nothing. Every notification in the app would have stopped without a single error. It was caught before the deploy. From that day a file that looks complete is not code for me until I've compared it with the one that's running.

Rules against AI memory

Most of the method is a list of rules, each with the date of the mistake that created it:

August 4: never paste texts written by another AI into the project's knowledge. They contained behaviors of the app that didn't exist.
August 17: if I report the same symptom twice in a row, the AI's source is old. Stop diagnosing and ask for a fresh export.
August 17: a file is produced by editing the one in the export, never rewritten from memory.
September 7: never use values "remembered" from previous sessions.
September 7: when another AI makes a proposal, compare it point by point and say who wins, even when the winner isn't you.
September 25: a number had been copied into six sections of the handoff and it was wrong. Every number now comes with the command that produces it.

The common thread: an AI's memory sounds exactly as confident when it's wrong as when it's right.

Asking five AIs the same question

In September I had a product decision to make about which features to include. I gave the same prompt to five assistants: Gemini, ChatGPT, DeepSeek, Kimi and Perplexity. Then I had Claude compare the answers against the rules I had already set. Claude was judged too and lost a point for one of its own earlier proposals.

The result surprised me: most of the proposals were things I had already decided. My note that day: when five assistants propose the same things you already decided, the list is complete, not poor. Asking more AIs didn't give me more ideas. It gave me confidence that I wasn't missing any.

The honest limit

The method doesn't make me immune. I work on many fronts in parallel: the app, the backend, the website, the store pages, the outreach. Information still gets lost between them. A recent example: the invite page had been showing its countdown for weeks while my own facts document still listed it as missing.

The handoff reduces these gaps. It doesn't remove them.

What I took from it

Use one AI as the main developer and the others as reviewers. Merging two developers' ideas by hand is a full-time job.
An AI that agrees with everything is not helping. Look for the one that tells you no.
Keep one document that every session starts from. Keep it a photo of the code, not a diary.
Never deploy what an AI wrote without comparing it to what is running.
Write a rule every time the AI's memory fails you, with the date. In a few months you'll have a method.

Next and last episode: the finished app. What held, what I'd redo and why building it turned out to be the easy part.

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

Most of my bugs started with a word, not with code

Cesare Bramante — Thu, 05 Nov 2026 11:38:52 +0000

My app went public on the App Store and Google Play on July 13 and I've rebuilt it more times than I'd like to admit. When I look at the list of fixes, most of my bugs started with a word, not with code.

In the last episode I told how the colors of my first prompt survived while five languages turned into four different places to keep in sync. This one is about how the app changed between the first sketch and today and about the fixes that taught me something.

The model that kept changing

Some parts of the app changed shape three or four times:

"I'd like to go". In January it was one of three states of an event. In February the states became times: now, in one hour, tonight. In April "I'd like to go" was removed. In June it came back as its own feature, the Wish. Later it got its final name: "Vorrei", "I would like".
Login. Google, Apple and Microsoft in January. Google and Apple a week later. Then, in March, a phone number with a code, which fits an app built around the contacts you already have.
The map. In February it was a web map inside a WebView. Two weeks later it was a custom widget drawing OpenStreetMap tiles directly.
Onboarding. Four pages with six animations in July. Two pages on September 1. One screen with a single "Create" button on September 10.
Ads. There was a small banner at launch. I removed it at the end of August because the benefit was close to zero. Removing it took more work than adding it because in my case Google Play kept blocking updates while an older build with ads was still active.

At the end of August I rebuilt the whole interface. The screen to create an event went from 2,895 lines to 464. The code worked. People got lost: too many steps, too many choices, too much to read. To be honest it's the most expensive lesson of the whole project and I'll come back to it in the last episode.

Bugs that started with a word

"In 1 hour" created the event now. In May, in the Italian version, picking "In 1 hour" created an event starting immediately. The code decided the start time by checking the text of the button for English words like "now" or "1h". In Italian the button said "Tra 1 ora": nothing matched and the code fell back to "now". The fix was to map every visible label to a stable internal code first and compute from the code.

Four months later, the same bug came back in Romanian. In September a native review improved the Romanian translation: "Peste 1 oră" became "Peste o oră", which is more natural. Somewhere a piece of logic still depended on that label and the event started immediately again. The note I wrote that day: a translated label is a value, not a text. Translating it is a code change when something depends on it.

A sentence in the app wasn't true. One screen said the address book never leaves the phone. To match contacts, something derived from the numbers does leave it. Nobody had lied on purpose: the sentence had been written before the feature changed. I rewrote five texts that day and the lesson surprised me. Searching for words like "never" or "always" didn't find the false sentences. Only reading each one against what the code does found them.

The website promised more than the app did. The site said the invite "works even without the app". The invite page said "to reply, you need the app". Both were true. Read together they made a promise the app didn't keep. The sentence now is: anyone with the link sees the event; to reply, they install the app.

Bugs that started somewhere else

Not everything was about words:

Location check on future events. Creating "Saturday at my place" while at home made the app think you had checked in. When you left the house, it closed the event, with all the replies. Found in September.
A timer that read too much. The home screen refreshed every 4 seconds and re-synced data at every tick, which by my estimate meant around 900 database reads per hour for each user. On a free tier that's the fastest way to a bill. Today it refreshes about every minute and a half. With a slow network it keeps showing the last good result instead of emptying the map.
"Tomorrow" that wasn't tomorrow. In October, checking the code against daylight saving time, I found two places where "tomorrow" was computed as now plus 24 hours. On the day the clocks change a day lasts 23 or 25 hours, which can put the event on the wrong day. Now the date is built from the calendar parts (year, month, day plus one). The fix goes out with the next update.
A space at the end of a name. A settings collection created by hand in the console was called app_config with a trailing space. The games didn't start and the error made no sense until I copied the name character by character.
A push that opened an empty page. The notification carried the event's ID instead of its full path. Tapping it opened a blank event.

Some fixes I already described in my first article, the one about how events expire.

What I took from it

Never put logic on a text the user can read. Decide it before the second language arrives.
When you change a feature, reread every sentence that describes it, in the app and on the website, against what the code does now.
The most expensive bug is a confusing screen. It doesn't crash. People just leave.
Write down why you removed something. Removing is often harder than adding.

Next episode: working with several AIs and the rules I had to write because they all remember things wrong.

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

The four colors from my first prompt are still in my app. Almost nothing else is.

Cesare Bramante — Thu, 29 Oct 2026 06:56:08 +0000

The four brand colors I wrote in my first prompt in January are still in my app today, to the exact hex code. Almost nothing else from that first sketch survived: not the logo, not the font setup, and certainly not the way I handled five languages.

This episode is about the visual identity and the language of the app, and about the AI's role in both. It's the part of the project where I disagreed with the AI the most. In the previous episode I told how one rule in the data model fixed the direction of the whole spec.

Colors decided on day one

My first prompt didn't just describe the app. It listed fourteen colors, each with a name and a job:

Primary #E040FB, a bright purple, for the main buttons;
Secondary #7C4DFF, an electric violet, for links and active states;
Accent #FF4081, neon pink, for notifications and social elements;
Accent #40C4FF, bright cyan, for status indicators;
then backgrounds, text colors, success, warning and error.

Today the theme file of the app has the same four codes. It even keeps custom colors named after my January descriptions, translated into English: primaryVibrantPurple, secondaryElectricViolet, accentNeonPink, accentBrightCyan. Some things changed: a different red for errors, the dark backgrounds, and a lime green added later for public events.

In August, during a redesign, the AI proposed a calmer look: one single accent color and warm neutrals. It applied it. I looked at it for a day and reverted it. Neon colors read better in both light and dark mode, and the neutral version looked flat. I wrote it down as a product decision not to reopen, because I knew the next session would propose it again.

The AI was right about one thing, though. My brand purple on a white background has a contrast ratio of 3.2, below the 4.5 recommended for text. Links moved to a darker violet. The purple stayed for buttons and highlights, where it works.

A font chosen for legibility

The same January prompt chose the font: Atkinson Hyperlegible, a typeface designed to be easy to read for people with low vision. I wanted an app that anyone could read at a glance, outside, on a small screen.

It's still there, but only for titles. In the August redesign the body text moved to Inter, which is denser and works better in lists and small labels.

And here is the honest part. The app uses Atkinson and Inter. The website uses three other fonts. A printed flyer I made in August uses yet another family. Three type systems for one small product. The only thing they really share is the logo. If I started again, I would decide one type system for everything on day one, the same way I decided the colors.

The logo I threw away

The first logo, from January 22, was three intertwined circles with a small lime star in the middle. Circles of friends overlapping. I liked it, and I used it in the first test builds.

I dropped it after the very first builds for testers, before the public release, and redid it. The new one is a map pin with an orbit around it: a place, not a group of people.

Looking back, the logo changed direction before I could say it in words. The app moved from "who" to "where" in the drawing first.

Five languages, the hardest part

I wanted Italian, English, Spanish, French and Romanian from the first prompt, because I knew who I wanted to reach. It still turned out to be the hardest part of the identity, for reasons that had nothing to do with translation.

The AI dropped a language. On February 18 the master prompt listed the supported languages as "Italian, Spanish, French, German". Romanian had disappeared and German had appeared. The work plan of the next day set English as the main language and enabled Italian, Spanish and French. Nobody had asked for German. I only noticed because I reread the list.

The first screens weren't translated at all. In February the texts were written directly inside the widgets, in Italian: "Sono qui", "Mi piacerebbe". The spec then said every fixed string must go into FlutterFlow's language panel. That worked for labels, but not for everything: messages in snackbars, dialogs and custom code don't live in that panel.

So for a while I made a rule: whatever isn't in the panel stays in English, as a common language. In July some screens showed Italian buttons next to English labels. I reversed the rule and translated everything. Today the app has 264 texts in five languages in the language panel, about 145 more translated field by field inside pages and components, and twelve custom code files that carry their own translation tables. The text of the permission requests lives in yet another place. "Five languages" turned out to mean four different places to keep in sync.

A language audit found the leaks. An audit in August found sentences where one language had leaked into another: "Bienvenido par" (Spanish with French inside), "Pas besoin di rester" (French with Italian inside), and French that switched between formal and informal "you" across nineteen strings.

Words that changed

Some of the best decisions were about words, not code:

Concept	Italian	English	Spanish	French	Romanian
Wish	Vorrei	Wish	Me gustaría	Je voudrais	Aș vrea
Ghost mode	Evento invisibile	Invisible event	Evento invisible	Événement invisible	Eveniment invizibil
History	I miei eventi	My events	Mis eventos	Mes événements	Evenimentele mele
Tags	Gruppi	Groups	Grupos	Groupes	Grupuri

The Wish is a noun only in English. In the other four languages it became a verb in the conditional: "I would like". It sounds like something you say to a friend, not like a feature.
Ghost mode and Vault were good internal names. Users read "invisible event" and "my events".
Tags became groups. Nobody tags their friends.
The animated intro had a play on words, "orbit to me". I removed it: it doesn't survive translation.

What I took from it

Decide colors early and write down why. They are the part of a brand that lasts.
Decide one type system for everything you'll ever publish, not only for the app.
An AI will happily "improve" your identity every session. Write your decisions down as decisions, or you'll defend them again every week.
Five languages is not a translation task. It's an architecture task: know where every string lives before you write the first one.
Reread the AI's lists. It replaced a language and nobody would have noticed.

Next episode: evolutions and fixes. Most of my bugs started with a word, not with code.

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

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.