Chepatapa Apps

How this all gets built

Five products, one developer, one shared codebase underneath. Notes on how Flare, Kin Compass, Bloomelle, Perchly, and Publy actually get made — updated as things ship.

One developer, six products

Chepatapa Apps isn't a company in any formal sense — it's Tsimafei Lemeshchanka building small, focused apps and developer tools solo, alongside a full-time job. Flare (hot flash tracking) and Kin Compass (ADHD parenting routines) are consumer iOS apps; Perchly and Publy are private package registries for Swift and Dart/Flutter teams; Bloomelle (cycle-phase planning) is live on the App Store too, and Naveli (postpartum recovery yoga) is the newest, still in development.

The apps are deliberately small in scope — no team, no funding, no roadmap beyond "does this solve a real problem for a specific person." Perchly and Publy exist because Publy's own team/org/billing layer turned out to be almost entirely reusable for a second, unrelated package-registry protocol.

One SDK, not six codebases

Flare, Kin Compass, Bloomelle, and Naveli share another1DD_flutter_sdk, a local package monorepo with the Redux state container, dependency injection wiring, navigation, theming, and localization every app needs. Kin Compass started as a literal clone of Flare's skeleton with the hot-flash domain code stripped out; Bloomelle was scaffolded the same way from Flare a few months later, and Naveli the same way from Bloomelle. New apps start from a working, battle-tested foundation instead of a blank Flutter project.

Perchly and Publy follow the same idea on the web side: Perchly's org/auth/billing layer was ported from Publy's, because a private package registry's account and subscription model doesn't actually depend on whether it's serving Swift packages or Dart packages.

Built with Claude Code

Most of the day-to-day implementation across all six projects — and this site — is done with Claude Code. Each feature starts as a written spec and plan checked into the repo before any code exists, gets implemented against that plan, and goes through an adversarial review pass looking specifically for what the plan or the implementation got wrong, before it's considered done. That discipline is what makes solo development at this pace hold together — the spec is the source of truth, not memory of what was decided three weeks ago.

It doesn't replace product decisions or judgment calls — positioning, what not to build, what a screen should actually say — those stay human. It replaces the hours of boilerplate and repetition that used to be the real cost of running six codebases alone.

Timeline

RSS ↗