Engineering a Yoga Platform with Gemini (Part 2: The Living Backend)
From Blueprints to Bytes: Why verifying your architecture and security rules is the most important step before writing your first SwiftUI view.
In my last post, we established the GEMINI.md mandates—the high-level rules that define how this project is built. Today, we moved from the "Why" to the "How."
As a Tech Lead, I know that a solid roadmap is only as good as its verification. In this session, Gemini and I focused on closing the technical gaps identified in our ROADMAP.md. We didn't just talk about a backend; we built, seeded, and programmatically verified a local environment that mirrors our future production cloud.
Here is how we bridged the gap between architecture and implementation.
1. The 3-Tier Strategy: Local, Staging, Prod
One of our first major decisions was the environment strategy. We established a rigorous 3-tier system:
Local: Running on the Firebase Emulator Suite. Zero cost, instant feedback.
Staging: A real Google Cloud project for integration testing.
Production: The final destination.
To manage this, we switched the project to XcodeGen. This was a turning point. By moving the "Source of Truth" for the project file to a simple project.yml, we enabled automated environment switching. We wrote a fetch-config.sh script that swaps the correct GoogleService-Info.plist depending on whether I’m coding at my desk or deploying to testers.
2. Engineering the "Privacy-First" Ethos
Yoga is a space of trust, and I wanted the backend to reflect that. We spent significant time on the Community-based Privacy model.
We didn't just say "make it secure." We wrote specific Firestore Security Rules that use an advanced "overlap check." In our system, two users are only "connected" if they share a joined community (like a local area or a studio group). If you aren't connected, the database itself refuses to return the other user's avatar.
The catch? This comes at a performance and cost penalty (one extra read per profile). But following our mandate—Security takes precedence over performance—we codified this logic directly into the architecture.
3. Hardening Against Attack Vectors
We didn't stop at just "making it work." We conducted a formal Security Risk Assessment, identifying and mitigating four critical attack vectors:
Data Leakage: Hardened community rules to prevent unauthorized PII exposure.
Data Corruption: Enforced schema validation directly in Firestore rules to block malformed writes.
Unauthorized Access (IDOR): Verified identity-based document gating.
Denial of Service (DoS): Implemented strict query limits and budget safety mandates to protect our $50/month budget from malicious exhaustion.
4. Validating Without the App
Most developers wait until the UI is built to see if their backend works. We didn't.
We implemented a deterministic seeding strategy. We created JSON seed files for users, studios, and posts. Then, we wrote an automated Security Rules Test Suite in Node.js.
By running npm run test:rules, we programmatically verified that:
User A could see User B when they shared a community.
User A was blocked when they didn't.
Unauthenticated guests were rejected instantly.
The system is safe against the identified attack vectors through rigorous automated validation.
We proved the system worked before the first import SwiftUI was even typed.
5. The Human Element: Catching the AI "Spring Clean"
This session was a significant learning experience in AI collaboration. Even with a highly capable model like Gemini 3, a human Tech Lead is essential. I had to catch Gemini several times:
The "Allow All" Trap: At one point, Gemini suggested "Allow all" rules for local development to "speed things up." I had to step in and enforce our Least Privilege mandate. We don't want "dev rules" and "prod rules" to drift.
The Deletion Habit: AI loves to optimize. During one update, Gemini deleted about 30% of our hard-earned requirements because it thought they were "redundant." I immediately added a Preservation Mandate to
GEMINI.md: Never reduce, only add or refine.Visual Alignment: We moved our UI mockups to the root for cross-platform access, but I had to remind Gemini to update the sketches whenever our textual requirements changed. We now have a Synchronization Mandate to ensure the design and docs never drift.
What I Learned: AI as a Scalpel, Not a Sledgehammer
Guiding an AI requires a scalpel. You have to be precise, you have to review the diffs, and you have to be willing to "course correct" when the AI tries to take a shortcut.
We have achieved something remarkable:
1. A verified local backend running on Java and Node.js.
2. Deterministic seed data checked into Git.
3. A formal risk assessment with mitigations for leakage, corruption, and DoS.
4. Automated security tests that validate our privacy model and confirm the system is safe.
5. Fastlane automation ready to run it all.
What’s Next?
Phase 3.0 is complete. The foundation is poured, the plumbing is verified, and the security guards are at the door. In Part 3, we finally open Xcode and start the TDD implementation of the Authentication Client.
Follow the journey on GitHub and let me know: How do you handle privacy-first engineering in your own stack?
