Arc Katalyst
Arc Katalyst is a behavioral coaching platform built around a product decision: meet people at their current stage, then make the next useful action clear. I took it from concept to private beta in 28 weeks on a one-operator team.
I set product direction, strategy, requirements, priority, acceptance criteria, and release shape. The Lead ran routine releases within that shape. Today, Board, Walker, and Dev roles carry the work through execution, review, merge, and runtime verification. The role model evolved during the project; these are its current names.
The dashboard decision
Arc holds plans, logs, coaching signals, progress measures, and long-term context. The dashboard could not give all of them equal weight. I made it answer one question first: "What should I do today?"
The resulting hierarchy places the primary coaching signal and next action ahead of raw progress data. Recent behavior provides a short mirror. Plans become actions for today. Longer-term Arc progress and accomplishments remain available without dominating the daily experience.
What I observed
Following the dashboard changes, across 20 users observed over 12 weeks, application records and user feedback indicated more frequent logging, shorter stretches without logging, and more users completing individual phases within their arcs.
These are encouraging early observations. They do not establish how much improvement the product caused or whether it increases long-term goal attainment.
The problem
Fitness and coaching products often begin with a plan and measure whether the user followed it. That framing is useful for someone already performing consistently. It is less useful when the immediate problem is starting, returning, or establishing a repeatable behavior.
Arc asks a different question before prescribing the next action: where is this person in the progression from non-action to performance?
The product bet
The behavioral model follows four stages: Non-Action, Action, Consistency, and Performance. The stage informs what kind of intervention is appropriate. Someone in Non-Action may need the smallest useful action. Someone in Consistency may need a refinement. Someone in Performance may need periodization or progressive overload.
Classification and intervention decisions are deterministic. Some coaching titles rotate by calendar day, so presentation can vary while the underlying decision remains selected by rules.
How Arc measures progress
Arc Score combines four pillars:
- Consistency: "How regularly you show up: days active, streaks, and per-domain logging rates."
- Adherence: "Did you follow the plan? Workout, cardio, nutrition, and step goal adherence."
- Results: "Are your outcomes moving in the right direction? Body comp, training output, recovery."
- Depth: "How complete is each day? Logging across all domains and quality of entries."
The weighting changes with the Arc. Early phases weight Consistency most. Adherence leads in the middle. Results lead in the final phase. Depth measures completeness and quality; learning does not feed it.
CARD scoring pillars
Phase-aware weighting
Each arc phase shifts which pillar carries the most weight in the overall Arc Score. Early phases weight consistency most, adherence leads mid-arc, and results lead the final phase.
Product architecture
The product links a person's goal to a time-bound Arc, the phases within it, the paths through those phases, and the dimensions the person tracks. Mobile, web, and backend services use that shared product model.
Product taxonomy
Intelligence engine · 38 registered layers
Generative AI powers nutrition helpers (estimating macros, parsing food logs, and suggesting recipes and meal plans). Coaching classification, prioritization, and intervention selection use explicit rules, not generation.
Explore the product architecture
Explore the intelligence engine
What reached private beta
- Mobile: The mobile experience supports onboarding, planning, daily logging, progress review, coaching signals, and communication.
- Web: The web experience supports coaching work, roster oversight, plan authoring, progress review, and accountability workflows.
- Backend: The backend supports shared product state, access controls, decision logic, notifications, and data used by both user-facing surfaces.
How it was built
Traditional product ceremonies sat above a CH(Ai)SE governance structure. Planning, refinement, acceptance criteria, review, and retrospective remained familiar. LEAD assigned responsibility for specification, execution, merge, verification, and release.
In the current model, I hold product direction and authorize the release shape. Lead performs routine releases within that shape. Board vets pull requests and merges accepted work to staging. Walker exercises the merged behavior. Devs execute one card at a time within declared scope.
Governing scope inside expanding work
Each execution card declares its file scope. Adjacent work is handled through the action gate rather than silently added to the card.
Tier 1 covers local, mechanical work inside the active scope. Tier 2 stops for a bounded card amendment and Operator approval. Tier 3 work is not implemented inside the active card; it is recorded, filed, or escalated through the applicable path.
The rule does not claim an executor lacks the capability to make a broader change. It keeps product and architectural judgment outside the execution lane and leaves a record of how additional work entered the system.
What the delivery process taught me
Early in the work, I observed that cards needing investigation or a split were not always handled through the same process. We sometimes had to revisit and realign completed work two sprints later.
That experience informed a feedback process in which a finding is recorded when it occurs and receives a documented disposition during review. Only some findings become shared rules. Others remain project-specific, create follow-up work, stay under observation, or close with a recorded reason.
After about ten sprints of using feedback to adjust the delivery process, I observed no more than one delivery-process adjustment per project per sprint. I treated that as a sign that the process was settling, not as proof that failures had stopped.
Read "One-off or pattern: where a lesson belongs"
Current state
Arc remains in private beta and active development. Work continues on the product, its verification evidence, and the conditions for a future public release.
Takeaways
Lead with the user's next decision.
The dashboard became clearer when I stopped treating every available signal as equally important. The primary product question is not how much the system knows. It is what the user should understand or do next.
Make behavioral rules explicit before they spread through features.
Some early features were built while parts of the behavioral model still lived as implicit assumptions. Formalizing those rules exposed places that needed realignment. I would establish the behavioral contract earlier on a similar rules-driven product.
Treat delivery findings as decisions, not automatic doctrine.
The delivery process improved when findings received explicit dispositions. A recurring problem may justify a shared rule. A one-off may need only a local response. Recording the distinction keeps the methodology responsive without turning every incident into permanent process.