Chepatapa Apps
← Build Log

Oct 2026 · Naveli / build notes

Starting Naveli: Clone Bloomelle, Then Delete It

Naveli is a postpartum recovery yoga app. Its first commit is 482 files copied from Bloomelle. Five days later, a single commit deleted 7,400 lines of that copy. Here's why starting from a finished app is faster than starting from a blank project, and what the cleanup actually involves.

Why postpartum yoga

The idea came out of a niche-research pass: the big prenatal yoga apps stop where postpartum begins, and the apps that do cover recovery are mostly generic workout libraries. What's missing is routing by how you gave birth (vaginal or C-section), pelvic-floor safety cues in every sequence, and a gentle diastasis recti self-check. That became the product plan, checked into the repo before any code existed.

The name took longer than expected. Four earlier working names each turned out to collide with a real app, clinic, or trademark in this exact niche. Naveli was the one that held up, and it's the name that stays.

Day one: copy everything

Naveli started from Bloomelle, which itself was scaffolded from Flare. The first commit brought over the shared infrastructure wholesale: dependency injection, the Redux store, onboarding, paywall, settings, notifications, Remote Config and rate-us shells, Firebase and Adapty wiring, and the Fastlane skeleton. Everything was renamed to Naveli's own bundle id, and every real secret (Firebase keys, the Adapty key, signing keystores, store screenshots) was replaced with a placeholder.

The cycle and check-in domain code was left in on purpose, as reference only. Seeing a working version of "profile in, recommendations out" next to the new empty one made it easier to write the replacement than reading the old code would have.

Day five: delete the domain

Once the replacement design existed, the cycle and check-in domain went in one pass: 113 files changed, about 7,400 lines removed, plus the home-screen widget code and the iOS widget extension, which Naveli doesn't need. The deletion had its own written plan and its own review pass, because "remove everything that isn't relevant" is exactly the kind of task where a stray import or a leftover test quietly keeps dead code alive.

Review caught real leftovers, which got their own follow-up commit. The new domain then went in layer by layer: a recovery profile and timeline, profile storage and Redux state, a sequence model, a core-check model, and a safety-text model, each with tests written as the layer landed instead of at the end.

A privacy rule from the start

Recovery details (delivery type, birth date, diastasis check results) are sensitive in a way a hot-flash log isn't. Two small commits from the first week came from that: the profile object keeps stored values out of its toString, and error messages never include what was being stored. Neither is a feature, and both are far easier to do before the first log statement than after.

Where it stands

The store-side groundwork is in place: a Firebase project, Adapty setup, App Store Connect products, signing certificates, and an Android upload key. The six-step onboarding flow is built and tested end to end. Next up are the home screen, the sequence library, and the content itself. No release date yet.

The takeaway

The shared SDK handles what every app needs. A cloned app adds the next layer: the screens and plumbing that every app of this kind needs too, already wired to billing, analytics, and CI. The cost is a deliberate cleanup pass, but it's a bounded one: the copy shows exactly what has to be replaced, and the plan for deleting it is the same kind of spec as the plan for building the new thing.