How I Built Anılog: A Decision Log From Idea to Store

The hard part of building an app is not writing code. The hard part is deciding which code not to write. Anılog — an app where a group of friends records a few seconds at times they choose, and everything merges into one vlog at the end of the day — turned out to be a good example.

This post is about the decisions rather than the code: what I picked, why, what bit me later, and what held up.

What it came out to:

• 39 Dart files, roughly 7,400 lines
• 15 PHP files, roughly 2,000 lines — no framework, no composer
• 8 MySQL tables
• iOS and Android, both with a home screen widget

Decision 1: Use Firebase for identity only

This was the first and most consequential call. Using all of Firebase (Auth + Firestore + Storage) would have been the fastest path. I didn't.

The reason is storage cost. Anılog is a video app: every user uploads several clips every day. On Firebase Storage that means a bill that scales with your user count and is hard to predict. I already had a Hostinger plan; disk and bandwidth were sitting there at a fixed price.

So the line was drawn like this:

• Firebase Auth → sign in with Google and Apple. Proving who someone is is Google's job; I'm not rewriting it.
• My own PHP + MySQL server → groups, clips, comments, reactions, media files. All the data and all the cost.

The price of that split is that the server has to verify Firebase's ID token by itself. I wrote up how to do that in plain PHP without composer in a separate post.

Decision 2: Don't build social media

The first sketch of Anılog had an explore feed, public profiles and a follow system. I deleted all of it.

Not just for simplicity. Public content means:

• Content moderation. Reporting, blocking, a review queue.
• App Store guideline 1.2. Apps hosting user-generated content are required to have reporting and blocking.
• A storage bill that doesn't scale.

Closed groups (up to 10 people, joined by invite code) remove all three. And they make the product better: with no follower count, people actually share their ordinary day.

Lesson: removing features saves more time than adding them.

Decision 3: The capture window is the product

An app where anyone can record whenever they want is just a shared gallery. What creates a shared moment is the constraint.

The model: a group sets a few capture times (at most 8). After each time, a window opens; when it closes, that moment is gone. The group also picks how long the window stays open — 10 minutes, 30 minutes, 1 hour or 2 hours. Default is 30 minutes.

I put this logic on the server, not the client. The clock on the client belongs to the user; anyone who changes their phone's time could open the window at will. After moving it server-side I tested 13 scenarios locally, including midnight rollover and upload grace. A window crossing midnight (23:50 + 30 min) was writing to the wrong day in the first version — without the tests I would never have caught it.

Decision 4: Don't force the user into anything

My first camera screen forced the phone into landscape so videos would be horizontal. I hated it while using my own app, and ripped it out.

The final behaviour: the interface is locked portrait, but the camera is free. Record vertically or horizontally, your call. The vlog step accepts both (how, in the ffmpeg post).

The same principle went into the shutter: a single tap records, and so does press-and-hold. While holding, sliding your finger up zooms; a double tap flips the camera — even mid-recording. Instead of guessing how someone holds their phone, I supported every case. The technical details are in a separate post.

Decision 5: Render the vlog on the phone, not the server

Merging the day's clips into one video means running ffmpeg somewhere. On shared hosting that is either impossible or painfully slow.

I moved rendering onto the phone. Counting the wins made it obvious:

• No CPU cost on the server
• The vlog file is never uploaded → no storage, no bandwidth
• Output that never leaves the device → the privacy claim is honest

The price: a few minutes of processing on the phone, and separate ffmpeg testing per platform. An acceptable price.

Picking the name

A boring but practical step: the name has to be free in the stores. I searched every candidate on both the Play Store and the App Store. "Anılog" survived because it carries both the Turkish word anı (memory) and log, and because searching for it turned up nothing else.

The domain and the package name were checked at the same time: com.anilog. Locking the name before writing code means never having to change a package name later. You only need to live through that once.

Where does AI fit in?

Anılog was largely written with AI assistance — the vibe coding approach. But the model made none of the five decisions above. Where it genuinely sped things up:

• Standing up the first version of a screen
• Iterating on the ffmpeg filter chain (and measuring the iterations against real files)
• Writing PHP endpoints
• Carrying the same screen into three languages

Where it helped not at all, because it can't:

• Deciding which feature to delete
• Guessing how someone holds their phone
• Seeing where the cost will explode

Once that line is clear, AI really is an accelerator. When it isn't, you get a pile of plausible-looking, mutually inconsistent code.

Where it stands

Anılog is being prepared for store submission. The privacy policy and the web account-deletion flow are live, and the privacy manifest (PrivacyInfo.xcprivacy) and encryption declaration are done.

Looking back, the most valuable habit was keeping every number in exactly one place: clip length, group limit, edit window, capture window. All of them in a single settings file on the server. The app, the server and the marketing page state the same number because they read it from the same place.

Rest of the series:

• Flutter camera without forcing orientation
• Firebase Auth with your own PHP server
• Merging videos on device with ffmpeg