01 The problem
Small teams don't lose projects to a single catastrophe — they lose them to drift. A review sits for three days. One person quietly owns three blockers. A mid-week standup gets skipped and nobody notices the frontend has been waiting on an API for a week. The signals are all there, but they're spread across GitHub, Slack, and people's heads, and by the time they add up to a visible problem, the deadline is already in trouble.
The hard constraint was trust. A tool that tries to reprioritize the roadmap or write code gets switched off the first time it's wrong. So the design problem wasn't "how smart can this be." It was "how do we surface real delivery risk early without overstepping into decisions that belong to the team."
02 What I built
Archeta is an ASP.NET Core backend with a React frontend that connects to a team's GitHub and Slack. It runs async, Slack-first standups, monitors issues and PRs, and folds everything into a single unified delivery state: each task snapshot combines GitHub facts, Slack standup references, live risks, active constraints, and intervention state into one canonical record instead of a pile of disconnected events.
On top of that sits a persistent learned-memory layer. A scheduled pass turns history into reusable patterns: review latency by weekday and by author, mid-week participation drops, frontend work that repeatedly stalls behind backend changes. Each is stored with a confidence score and the evidence behind it, then fed back into summaries and nudges. The operator surface reads from a backend-authoritative next-move selector: the dashboard surfaces one dominant next move, and approving or escalating it runs through the coordinator lifecycle rather than client-side guesswork.
03 Key decisions & tradeoffs
-
Draw the boundary in code, not the marketing
Archeta owns delivery state, risk detection, intervention, and outcomes. It explicitly does not do roadmap prioritization, business calls, or code. That refusal is enforced in the product, not just promised.
Tradeoff Less "magic" and a narrower pitch, bought in exchange for being a tool teams keep switched on.
-
Backend-authoritative next move
The one recommended action is computed server-side and executed through lifecycle endpoints (
approve/escalate), not derived from client heuristics that drift between sessions.Tradeoff Heavier backend and more state to maintain, in exchange for recommendations that are consistent and auditable.
-
Thresholds that learn per team
Repeated delays and failure modes feed back into effective monitoring thresholds, so stall, ownership, and review interventions fire earlier for teams that keep hitting the same wall.
Tradeoff Harder to reason about than fixed limits, so every learned insight carries confidence and supporting evidence instead of being a black box.
-
Fail fast on schema drift
Startup never auto-applies EF migrations; instead it validates that the physical SQL schema still matches the model and refuses to boot if it doesn't.
Tradeoff A drifted database is a hard startup failure rather than background workers silently spinning on missing tables, which is exactly what I want in production.
-
Respect human hours by default
Per-project working windows are enforced at send time: off-hours nudges queue for the next valid window, while explicit operator actions can still bypass quiet hours.
Tradeoff More scheduling machinery, but a coordinator that doesn't ping people at 11pm is one people don't mute.
04 Outcome
Archeta was accepted into Microsoft for Startups (Tier Two) and runs a public pilot intake with admin-approved provisioning. The operating model is built out across eight phases, from the constraint engine through a closed-loop verifier to the adaptive learning loop, and the whole thing is designed to be configured per project rather than hard-coded.