8 Hours vs 3 Weeks: When Preparation Becomes Speed

8 Hours vs 3 Weeks: When Preparation Becomes Speed

November 22

The SEC-RBAC security epic was estimated at 2–3 weeks. It took approximately 8 hours.

Not 8 hours of heroic coding. Not 8 hours of cutting corners. Not 8 hours that would create 8 weeks of technical debt. Eight hours of systematic execution, finishing 45% ahead of even the optimistic estimates.

This isn’t a story about working faster. It’s a story about preparation front-loading the hard work until execution becomes almost mechanical.

The estimate wasn’t wrong

Sprint S1 — the security foundation sprint — was scoped at 81 hours total. RBAC alone was estimated at 20–24 hours. Encryption at rest another 24–30 hours. Supporting work for the remainder.

These weren’t pessimistic estimates. They were based on reasonable assumptions:

• Phase 1.1 (database schema): 4–6 hours
• Phase 1.2 (service layer): 8–12 hours
• Phase 1.3 (endpoint protection): 4–6 hours
• Phase 1.4 (shared resources): 4–6 hours
• Phase 2 (role-based permissions): 6–8 hours
• Phase 3 (admin and testing): 4–6 hours

Each estimate assumed some discovery work, some problem-solving, some iteration. Normal software development.

What the estimates didn’t account for: we’d already done most of the discovery work.

Phase 0 was the real work

The security sprint had a Phase 0: audit and planning. Six comprehensive reports created before any implementation began:

1. Phase -1 verification (infrastructure assessment)
2. Clarifications research (recommendations)
3. API endpoint catalog (56 endpoints mapped)
4. Service methods inventory (47 methods identified)
5. Risk assessment (P0 and P1 blockers categorized)
6. Phase 0 completion summary

This audit took time — multiple sessions, deep investigation, comprehensive documentation. It didn’t feel like progress. No code was written. No tests passed. No features shipped.

But when execution day arrived, there was nothing left to figure out.

The endpoint catalog meant Phase 1.3 knew exactly which endpoints needed protection before writing any code. The service methods inventory meant Phase 1.2 had a checklist, not a discovery process. The risk assessment meant priorities were already set.

Phase 0 wasn’t overhead. It was the work. Everything after was mechanical application of decisions already made.

Architecture decisions as force multipliers

ADR-044 decided the fundamental approach: Lightweight RBAC using JSONB columns rather than traditional role and permission tables.

This decision was made days before implementation. The Chief Architect evaluated options, documented trade-offs, recommended an approach, got approval. His assessment was blunt: “Traditional RBAC would be architectural astronauting at our current scale. Building for 10,000 users when we have <100 is how projects die from complexity before reaching users.”

The traditional approach — role tables, permission tables, junction tables — would have taken 2–3 weeks. The lightweight approach took 5 hours. Both met our security requirements. Only one let us ship on time.

When Phase 2 implementation began, nobody debated whether to use JSONB or separate tables. That question was answered.

The implementation followed directly from the decision:

JSONB upgrade: ["uuid"] → [{"user_id": "uuid", "role": "viewer"}]
Applied to lists and todos tables
Existing shares default to "viewer"

Clear architectural decisions become implementation specifications. The team doesn’t stop to think; they execute the specification.

Every architectural decision made before implementation day was time saved during implementation day. ADR-044 probably saved 2–4 hours of implementation-time debate and iteration.

Patterns established, patterns reused

The first service to get ownership validation was KnowledgeGraphService — 20 methods across service and repository layers. That implementation established the pattern:

• Optional owner_id parameter
• Conditional filtering when provided
• 404 responses for non-owned resources (prevents information leakage)
• Tests validating ownership boundaries

Once the pattern was established, applying it to ProjectRepository (7 methods), FileRepository (14 methods), and six other services was mechanical. Same pattern, different services. The second service took half the time of the first. The sixth took a quarter.

Pattern reuse isn’t just code efficiency. It’s cognitive efficiency. The agent doesn’t need to think about how to implement ownership validation. It just applies the established pattern to new services.

This is why Phase 1.2 — estimated at 8–12 hours for 67+ methods — completed so quickly. The pattern was figured out once and applied many times.

Completion matrices as execution guides

Each phase had a completion matrix: explicit lists of what needed to be done, with clear done/not-done states.

Phase 1.2 completion matrix listed every service and every method:

• FileRepository: 14 methods (done/not done for each)
• KnowledgeGraphService: 12 methods
• ProjectRepository: 7 methods
• UniversalListRepository: 11 methods
• … and so on

The agent didn’t need to discover what work remained. The matrix showed it. Progress was measurable. Scope was explicit. Nothing was ambiguous.

When the completion matrix says “67 methods across 9 services,” the agent knows exactly what success looks like. No scope creep. No “one more thing.” Just: execute the matrix.

Phase 2’s permission matrix was similarly explicit:

Twenty-four test cases fell directly out of this matrix: 4 roles × 6 operations. No ambiguity about what to test. The specification was the test plan.

Autonomous prompt discovery

Something unexpected happened during Phase 1.4. I told the Code agent “there’s a new prompt for Phase 1.4” and the agent found it.

Not because I gave detailed instructions. The agent searched dev/active/agent-prompt-sec-rbac-phase* based on naming convention, found the prompt, validated that prerequisites were complete, and executed the work.

PM coordination overhead for that phase transition: zero minutes.

This wasn’t magic. It was systematic infrastructure. Prompts lived in predictable locations with predictable names. Prerequisites were documented in the prompts. The agent had patterns for searching, reading, and executing.

When coordination infrastructure is good enough, coordination becomes invisible. The agent just finds what it needs.

Why 8 hours instead of 3 weeks

The 8-hour execution wasn’t faster coding. It was less work to do.

Each row represents hours saved. Discovery during Phase 0 instead of implementation saves maybe 6–8 hours. ADR decisions save 2–4 hours of debate. Pattern reuse saves maybe 4–6 hours of reinvention. Completion matrices save 2–3 hours of scope management. Autonomous coordination saves 1–2 hours of context switching.

Add it up: 15–23 hours of work that simply didn’t need to happen during execution day because it happened earlier.

The 3-week estimate assumed that work would happen during implementation. When it happened during preparation instead, implementation became mechanical.

The real cost

Front-loading isn’t free. Phase 0 took significant time. ADR creation and review took time. Building coordination infrastructure took time. Creating completion matrices took time.

If you measure only “time from sprint start to feature complete,” preparation looks like overhead. The security audit doesn’t ship features. ADRs don’t pass tests. Completion matrices aren’t code.

But if you measure “time from project start to feature complete,” preparation is obviously investment. Every hour of Phase 0 saved multiple hours during Phases 1–3. The return on preparation was 3–5x.

The teams that ship fastest aren’t the ones that start implementing fastest. They’re the ones whose preparation makes implementation almost trivial.

When this doesn’t work

Front-loading works when:

• Requirements are reasonably stable
• Patterns apply across multiple implementations
• Architecture decisions are tractable before coding
• The team can maintain context across preparation and execution

Front-loading fails when:

• Requirements will change significantly during implementation
• Each feature is genuinely unique (no patterns to establish)
• You need to build to learn what the architecture should be
• Long gaps between preparation and execution lose context

The SEC-RBAC epic was a good candidate for front-loading: security requirements were clear, patterns applied across all services, architecture options were well-understood, and execution followed preparation within days.

Exploratory work — figuring out what to build rather than building a known thing — might need a different approach. Sometimes you need to start implementing to discover what the architecture should be.

The transfer

Here’s what transfers to other projects:

Audit before building. Map the landscape. Catalog what exists. Identify what needs to change. This investment pays off in execution clarity.

Decide architecture separately from implementation. ADRs, design docs, technical specifications — whatever format works. The point is: don’t debate during implementation. Debate before. Document the decision. Execute the decision.

Establish patterns explicitly. The first implementation of a pattern is learning. Document what you learned. Make subsequent implementations mechanical application, not repeated discovery.

Create explicit completion criteria. Matrices, checklists, acceptance criteria — whatever makes scope unambiguous. When “done” is explicit, progress is measurable and scope is contained.

Invest in coordination infrastructure. Naming conventions, prompt discovery, handoff protocols — whatever makes coordination invisible. Time saved on coordination is time available for execution.

The 8-hour epic wasn’t a fluke. It was the predictable result of systematic preparation making execution mechanical.

Three weeks of work, done in 8 hours. Not by working faster. By doing less work during execution — because the work had already been done during preparation.