Framework First or Use-Cases First?
The mistake is treating 'framework' as monolithic: either build it first (slow, safe) or build services first (fast, indebted). Wrong binary. Split 'framework' into a thin load-bearing spine — identity, data, security — which must be right from day one, and everything else, which is cheap to refactor anytime. Build the spine first, ship features on the spine at full speed. Carolverse got this backwards: we shipped Carol first, then spent months retrofitting databases and governance underneath live services, and the migrations we regretted were never about features — they were always about foundations we'd skipped.
A framework mistake is silent when it doesn't break loudly — it corrupts everything built on top. Carolverse's data layer lived inside each app's folder. We didn't notice the problem until we wanted to delete apps without losing data: now the databases were scattered in live code, and migrating them under production load was a real incident. That's a load-bearing decision — it doesn't fail during design, it fails during scale, and the cost is everyone's blast radius. The lesson: identify the load-bearing decisions — identity, data isolation, policy gates — and get them right first. Everything else can be loose and refactored later.
Once the load-bearing core is solid, ship features as fast as your developers can code them — those are cheap to refactor because the foundations are right. Carolverse's build pipeline is still being hardened (we run in 'Bypass' mode while we retrofit automation), but because identity and data are locked down, new services onboard cleanly even while the build infrastructure is in flux. The expensive refactors in an agentic system are never the features — they are always the foundations. Get those right first, then go full speed.
