Building Sittally: The Agentic Workflow, Real-Time Feedback, and Navigating the App Store

In Part 1, I wrote about how a babysitting spreadsheet became Sittally, now live on the App Store. This post is about the build itself: the agentic workflow, the backend choices that kept velocity high, and the App Store gauntlet at the end.

I did not start there, though. Before I committed to Flutter, I toyed with React Native the old-fashioned way: tutorials, docs, and trying to build muscle memory without an AI pair. On paper it made sense. I already live in the JavaScript and React world for web work, so a React-shaped mobile stack felt like the lower ramp. In practice, the ramp was still a grind. Every new concept meant another tab of documentation. Every red stack trace meant hunting through Stack Overflow or obscure forum threads, often for hours, just to unblock a single issue. Progress happened, but it was slow enough that the hobby project risked dying in the “I’ll learn this properly first” phase.

That experience made the next decision clearer. Instead of spending more weeks grinding through tutorials, whether React Native or Dart and Flutter, I decided to lean fully into working side by side with AI. For Sittally that meant an agentic coding workflow in Cursor, with Flutter as the stack we would learn while building.

Even without a background in Dart, I could paste raw error logs directly into the prompt. The AI acted as a one-stop shop: explaining the root cause, proposing a solution, and applying the fix. That feedback loop made the initial development phase move exceptionally fast, and it was a different mode of learning than the React Native experiment. I was still responsible for taste, architecture, and saying no to bad ideas. I just was not alone with the docs anymore.

Real-time iteration and the all-in-one backend

A major factor in that speed was Cursor’s ability to switch between AI models on the fly and offer real-time visual feedback. Being able to prompt a change, refresh the simulator, and immediately see how a UI or UX pattern rendered was hugely productive. If a layout or visual component did not feel quite right, I could describe the exact pattern I wanted and watch the agent adapt the code on the spot.

For data and infrastructure, Firebase was the natural choice. Having used it on past projects, I knew it would serve as an effective all-in-one ecosystem. For Sittally that meant:

• Authentication with email/password, Google Sign-In, and Sign in with Apple
• Firestore for families, timesheets, invoices, and subscription status
• Cloud Storage for things like Pro invoice brand marks
• Cloud Functions for account wipe on delete and subscription entitlement mirroring
• Hosting for the marketing site, privacy policy, and terms at sittally.app
• Crashlytics for production crash reporting

Connecting auth, the database, PDF invoice exports, and the public web surface under a single project kept complexity low. Firebase’s generous free tier also meant near-zero overhead for a hobbyist build until the features that required a paid plan (like certain Functions) actually showed up.

Senior-level oversight: the human in the loop

That said, agentic coding is an assistant, not a replacement for engineering judgment.

Having spent over two decades in the tech industry, keeping a human in the loop remained essential. There were plenty of instances where the AI generated solutions that were architectural dead ends or simply did not meet my quality standards. My job was to evaluate those outputs, question questionable decisions, and reshape the code until it matched the caliber I expect from professional software.

A few concrete places that oversight paid off:

Client-trust vs server-trust. Sittally Pro is gated in the UI by RevenueCat, but freemium limits also need to hold up if someone tampers with the client. Clients can seed a free subscription status document. They cannot flip is_pro themselves. A Cloud Function webhook mirrors the entitlement into Firestore so security rules can enforce quotas for real.

App Store compliance is product work. Account deletion, privacy manifests, hosted privacy/terms that match the binary (including IAP and RevenueCat), forgot-password, and Sign in with Apple were not optional polish. Several of those only became obvious when we ran a structured “what would reject this?” pass before submission.

Security rules and abuse boundaries. Owner-only data isolation, Storage size/content-type limits, and wiping user trees on Auth delete are the kind of details an agent will sketch if asked, but a senior reviewer still has to insist they exist and are deployed before anyone hits Submit.

The pattern that worked best: let the agent move fast on scaffolding and fixes, then slow down for anything that touches money, identity, deletion, or App Review.

Overcoming the App Store bottleneck

The final hurdle was distribution. While I have plenty of experience architecting web applications, launching a mobile app on Apple’s App Store was entirely new territory for me.

Apple’s submission and distribution pipeline is notoriously convoluted if you have never navigated it before. Using agentic prompts as a step-by-step guide through portal setups, certificates, provisioning profiles, Transporter uploads, and App Store Connect metadata demystified the process. Even when the AI suggested steps that did not line up with the current Connect UI, the interactive back-and-forth let us troubleshoot together and get Sittally across the finish line.

A few realities that tutorials gloss over:

• Your first submission may get a “tell us more” pause. Because this was a new developer account with little review history, App Review asked for Guideline 2.1 clarification: purpose, audience, how to reach the main features, a working demo account, and a physical-device screen recording of the typical flow (including the Pro paywall and account deletion confirmation). That was not a product reject. It was homework. We answered in Resolution Center, attached the recording, and kept going.
• Legal pages have to match the binary. Shipping a paywall while privacy copy still said “no payments” is an easy way to earn a rejection. Privacy and terms had to disclose Pro, Apple IAP, auto-renew, and RevenueCat before archive day.
• Connect is its own product. Privacy nutrition labels, IAP products tied to the sittally_pro entitlement, review notes, and a seeded demo account mattered as much as a green Xcode build.

None of that required me to become an Apple portal expert overnight. It did require patience, a checklist mindset, and treating the agent as a guide who can be wrong about yesterday’s UI but still useful for the next click.

What I would tell another solo builder

1. Paste the stack trace. Do not translate it into a polite question first.
2. Keep a short “human owns this” list: auth, rules, money, deletion, store metadata.
3. Budget time for App Store Connect itself. The binary is only half the submission.
4. When Review asks for more information, answer completely once. Demo account, recording, and notes save a round-trip.

Sittally is live today: sittally.app and on the App Store.

Next in the series I want to go deeper on the product and architecture decisions that were not pure speed plays: freemium limits, PDF invoicing, and the Sittr-to-Sittally rebrand mid-flight. Those deserve their own posts.