Code

Building Sittally: The Sittr-to-Sittally Rebrand Mid-Flight

What it took to rename Sittr to Sittally after the product was already real: domain, bundle ID, OAuth, marketing site, and the Firebase project ID I could not change.

Building Sittally · Part 3
FlutterFirebaseiOSBrandingSittally

This is Part 3 of a four-part Building Sittally series. In Part 1 I covered why Sittally exists. In Part 2 I covered how Cursor and Firebase got it built and into review. This post is about the plot twist in the middle: the product already had a name, and that name was wrong.

The working name was Sittr. It was short. It fit the sitting niche. It was already wired through the Flutter app, legal placeholder URLs, and an iOS bundle ID. Then I found out Sittr was already out there in use. Keeping it was not an option.

So I bought sittally.app and treated the rename as a real project, not a find-and-replace afternoon.

Renames are never just strings

An agent can swap Sittr for Sittally across a codebase in minutes. That is the easy layer. The hard layer is identity: every place the outside world pins the product to a unique ID.

For Sittally, the full rebrand meant I chose the deep path on purpose:

  • User-facing name and wordmark (UI ALL CAPS: SITTALLY)
  • Dart package rename from package:sittr to package:sittally, plus Sittr* types and filenames
  • New assets: logo and app icon regenerated for launcher icons
  • Public domain and support email on sittally.app
  • Marketing site copy, privacy, terms, and support pages
  • A new iOS bundle ID: com.chrissloan.sittally instead of com.chrissloan.sittr

That last bullet is the one that turns a rename into a mini migration. Apple treats a bundle ID as the app’s identity. Changing it means a new App Store Connect app, new signing, new Sign in with Apple capability, and a fresh Firebase iOS client registration. There is no keeping the old listing and just editing the title.

I considered keeping com.chrissloan.sittr and only changing the display name. That would have been faster. It would also have left “sittr” in the DNA of every certificate, OAuth client, and store URL forever. Given I was still pre-launch, burning the old identity was the cleaner call.

The thing I could not rename

Firebase project IDs are immutable. Mine is still sittr-481ab.

That is fine, and it is also easy to get wrong if I let an agent “helpfully” invent sittally-481ab or try to migrate the project. Product branding and backend project ID do not have to match. What does have to stay honest is the documentation: display name can say Sittally in the Firebase console; the project ID, storage bucket, and hosting fallbacks keep the old slug. Those hosts stay trusted in the app. I cannot pretend the rename reached places Google will not let me change.

I captured that map in a branding doc so future-me (and future agents) would stop guessing.

What had to move in lockstep

A mid-flight rebrand fails when one surface updates and another still points at the ghost of the old name. The checklist that mattered:

  1. App binary: display name, drawer wordmark, invoice/share copy, legal URL constants.
  2. Auth: FlutterFire reconfigure for the new iOS bundle; Google Sign-In client ID and URL scheme kept in sync across Info.plist, Dart constants, and firebase_options.dart.
  3. Apple portals: new App ID with Sign in with Apple; new Connect app with privacy and support URLs on sittally.app.
  4. Marketing site: domain cutover from the temporary/wrong hosts to sittally.app, then matching privacy and terms.
  5. Cold launch test: Google and Apple sign-in on a device with the new bundle, because OAuth is where silent mismatches show up.

Cursor was excellent at the mechanical sweep and at drafting the checklist. I still had to own the decisions: deep rename vs cosmetic, new bundle vs keep, which domain was canonical when an early draft of the site used the wrong host.

What the episode taught me about agentic work

Rebrands expose the difference between editing code and changing a system.

Agents are fantastic at:

  • Package and symbol renames at scale
  • Updating URLs and copy across app + site
  • Regenerating icons and spotting leftover strings
  • Writing the “do not forget Connect / DNS / mailbox” list

I still owned:

  • Whether to burn a store identity before launch
  • What is immutable (Firebase project ID) vs what only feels permanent
  • The order of operations so auth and legal pages do not briefly disagree
  • Verifying the product still signs in and still looks like itself after the dust settles

Sittally shipping under the right name was worth the disruption. The App Store listing live today (Sittally) is that new identity, not a sticker over Sittr.

If I am mid-build and discover a naming collision again, I will decide early whether I am renaming a label or renaming an identity, then make the agent follow that decision everywhere, including the places that only exist in browser tabs.

Series map

  1. From Google Sheets to the App Store
  2. Agentic workflow and the App Store
  3. This post: the Sittr-to-Sittally rebrand
  4. Product loop, freemium, and what comes after ship