Building Sittally: The Product Loop, Freemium Reality, and What Comes After Ship

This is Part 4, the last post in the four-part Building Sittally series, and I want it to feel like a landing rather than another checklist.

Part 1 started with a spreadsheet for my daughters’ sitting work. Part 2 was about leaning into Cursor, Firebase, and the App Store grind. Part 3 covered renaming Sittr to Sittally after the product was already real. Here I want to pull those threads together: the workflow that actually made the app useful, the freemium setup that keeps Pro honest on the server, what I think this agentic experiment proved, and the part I have barely started, which is getting the app in front of people who might care.

Sittally is live on the App Store. For this series, shipping was the finish line. For the product, it is closer to the starting line.

The product loop: from sit to PDF

The original Google Sheet only existed to turn hours into something a parent could reasonably pay against. That is still what Sittally is for. You keep the family and their rate rules in one place, log the sit with a timer or after the fact (or skip the timer entirely for flat-rate work), bundle open timesheets into an invoice, share a PDF through Messages or the iOS share sheet, and mark it paid when the money shows up. That loop is the whole point. Everything else in the app is there to support it.

Cursor made it easy to scaffold screens and iterate on PDF layout. Deciding what was actually good enough to send a parent was slower and more opinionated. Pro is where fees, tax, brand colors, logos, and payment handles live, including QR blocks that point people toward Venmo or Cash App without pretending Sittally moves the money itself. The app tracks work and produces invoices. It is not a payment processor, and drawing that line clearly mattered for product copy, privacy language, App Review notes, and my own comfort with what I was putting in the store.

If Part 1 was the frustration of ugly spreadsheet exports and hunting through rows for who owed what, this loop is the thing I was trying to get to the whole time.

Freemium reality: UI trust is not server trust

I wanted a free tier so someone could try the workflow without paying first, and a Pro tier for the pieces that turn a personal tracker into something closer to a small sitting business: more families and services, unlimited timesheets, recurring calendar sits, invoice fees and tax, custom branding, and payment links on the PDF.

RevenueCat made the App Store subscription plumbing much more tractable than rolling my own. The entitlement is sittally_pro, and the UI reads it for paywalls and feature gates, which is great for feeling snappy after a purchase or restore. It is also incomplete on its own. Firestore security rules cannot call RevenueCat, so if Pro only lived in the client, a modified build could waltz past the paywall. I ended up with two layers on purpose: the app trusts RevenueCat’s CustomerInfo for the interface, while a Cloud Function webhook mirrors the entitlement into Firestore as is_pro so rules can enforce quotas for real. Clients can seed a free status document. They cannot promote themselves to Pro. Free limits like one active family and lifetime timesheet caps live in both app code and rules so those two sources of truth do not quietly drift apart.

That was one of the clearest human-in-the-loop moments of the whole project. An agent will happily wire a polished paywall. Making money and quotas hold up under less friendly assumptions is still an engineering call I had to own.

What this series actually taught me

Looking back, the useful lesson was not “AI built an app for me.” It was that agentic coding can get a senior engineer productive in an unfamiliar stack without months of tutorials first, as long as you bring taste, architecture judgment, and a willingness to slow down around money, identity, deletion, and store compliance. Speed without that oversight just ships liabilities faster: auth gaps, missing account deletion, privacy pages that contradict the paywall, weak security rules, Connect metadata that does not match the binary. The Sittr-to-Sittally rename drove the same point home from another angle. Identity work is system work. Bundle IDs, OAuth clients, App Store Connect, and an immutable Firebase project ID do not care how quickly you can rename strings in a repo.

The other lesson is simpler. The product has to close a real loop. Families, timesheets, invoices, and PDFs are why Sittally exists. Subscriptions, Crashlytics, and marketing sites only matter because that loop is worth protecting.

What this series did not prove is that building the app was the hard part of getting people to use it. That is a different problem, and I am only now standing in front of it.

The next hurdle: marketing

I know how to ship software. I am much earlier in figuring out how to put a niche iPhone app in front of babysitters, mother’s helpers, and other sitters who are still stuck in notes apps and spreadsheets. Being on the App Store is necessary, and it is nowhere near enough. A listing does not create discovery by itself.

I still need to learn what messaging actually resonates, where those sitters already spend time, which content or community efforts are worth the hours, and how to tell whether any of it is working without lying to myself with vanity metrics. That is the next experiment, and I plan to approach it with the same bias I used on the build: try things, keep notes, adjust, and stay honest about what flopped. I expect some of that journey (the attempts, the dead ends, and whatever surprisingly works) to show up in future posts outside this series. This one stops at the edge of that map on purpose.

If you are a sitter, or you know one who might benefit, I would love the straightforward help: try Sittally, poke around sittally.app, and tell me what is missing.

Series map

From Google Sheets to the App Store
Agentic workflow and the App Store
The Sittr-to-Sittally rebrand
This post: product loop, freemium, wrap-up, and marketing as what comes next

Thanks for reading along. Building Sittally with AI as a primary assistant was the hypothesis. Getting it into the App Store under the right name was the proof. Finding the users is the sequel, and that story is just getting started.