Introducing The (AI-)Software Development Lifecycle in Scaleups
Part 6 in Tekkr's take tech teams to the top series.
Welcome back to the A-to-C Playbook. In Part 3, we introduced the Operating Model to upgrade your “Startup Go-Kart” into a “Racing Bus.” In Part 4, we tackled the people. Now, we have to talk about the engine.
We’ve all been there. You have a major company all-hands coming up. Maybe it’s a board meeting, or a key industry conference. You’ve promised a game-changing feature that will define your next quarter. You trust your team; they’re smart, they work hard, and they’ve always pulled it off before.
But the date arrives, and the feature isn’t there.
Or worse—it’s there, but it’s fragile. It works on the demo laptop but fails under load. You are left standing in front of your stakeholders with empty hands, asking yourself: “How did this happen? We have more engineers than ever before. Why are we shipping less?”
This is the Velocity Paradox.
In the Seed stage (0-10 engineers), process is the enemy of speed. You rely on high-trust, high-bandwidth communication between people sitting in the same room sharing a pizza. But as you cross the Series A threshold (15+ engineers) and head toward Series C (30, 50, 100 engineers), that natural human collaboration breaks down. You can’t solve architecture problems over a slice of pepperoni anymore (or Milano Vice Spinach Obsession if you are in Berlin these days).
To fix this, we need an engine. The SDLC isn’t just about “coding”; it is a six-stage cycle that ensures quality in software development at scale:
Planning: Defining the problem space.
Design: Architecting the solution (RFCs + UX).
Implementation: Writing the code.
Testing: Verifying quality (Unit, Integration, E2E).
Deployment: Shipping to production.
Maintenance: Monitoring and iterating.
Two Critical Realizations for Scale-Ups
As a founder scaling from Series A to C, you should understand two distinct things about this lifecycle.
1. The “Scale-Up Fix”: Focus on the Edges You are likely introducing an SDLC because things are breaking. But they don’t break equally. In a growing startup, Implementation (writing code) and Deployment usually happen naturally because engineers like doing them. Where scale-ups fail is at the edges:
Planning: You build the wrong thing because requirements were verbal.
Design: You build it the wrong way because no one checked the architecture against the legacy system.
Maintenance: You drown in bugs because you never prioritized technical debt.
Takeaway: Don’t democratize your process efforts. Disproportionately invest in fixing Planning, Design, and Maintenance first.
2. The “AI Shift”: The Process is Changing
The ground is shifting beneath our feet. My major reason for pushing this article out on December 23rd at 11:57pm is that I’m afraid by January parts might be outdated. 😅
AI is completely rewriting how this lifecycle works: Welcome to the AI-SDLC.
Old World: 60% of time spent on Implementation & Testing.
New World: Implementation cost drops to near-zero. To survive this shift, you must double down on the creative and strategic steps (Planning & Design) while automating the execution.
Spoiler: 90% of best-practices for how this should be done from the last 10 years are flying out of the window with AI. While “best practice” will be a moving target for a few years, I’m sharing some hypotheses for the future below.
Top Learning Summary For Busy Founders
Top three learnings for tech leaders establishing an SDLC:
The Velocity Paradox: As you scale, “process” stops being a blocker and becomes the enabler of speed. Without an SDLC, you will enter “Integration Hell” where adding engineers actually slows you down.
Prototype-Driven PRDs: Text is still king, but its source has changed. PMs must build prototypes first, then generate the PRD (Product Requirements Document) from the prototype. This ensures the text accurately describes reality before engineers ever review it.
The 90/10 AI Shift: We are moving to a world where AI writes the code. The human role shifts from typing to reviewing. Your new SDLC must be built around “Human-in-the-Loop” validation, not manual creation.
The Trigger: When Smart People Stop Being Enough
In the scale-ups we are talking about, the primary engagement point for an SDLC is usually the ISO 27001 certification. You are rarely doing this for fun; you are doing it because your enterprise customers demand that you have it. This external pressure forces you to actually document your processes, define how you work, and uplevel them.
However, while compliance is the external trigger, the internal signal usually appears much earlier.
The real “canary in the coal mine” is subtler: Frustration.
You will see a team that has finished their work, but they can’t release because they are blocked by another team. You see engineers working weekends, not because they are inspired, but because they spent Wednesday and Thursday fixing a breakdown caused by a lack of alignment.
When you see good engineers building code for the trash can because requirements weren’t clear, you don’t have a people problem. You have a process problem.
Planning & Design (SDLC Steps 1-2)
The New Standard: Prototype-Generated PRDs
In the old world, a Product Manager imagined a feature, wrote a PRD, and then engineers tried to guess what the words meant. This “Telephone Game” is the root cause of rework.
Even worse, some teams don’t write PRDs at all, relying purely on verbal consensus. To be fair - this works amazingly well until you hit 10 or 15 people—then it breaks down fast and hard. Some grown, now struggling teams find themselves in fierce debates about whether introducing basic “acceptance criteria” is helpful structure or just bureaucratic friction when they should just leverage AI more for ANYTHING text-based.
In the future, Text remains super important, but the order of operations flips.
The new standard is Prototype-First, Text-Second.
The Prototype: The PM uses low-code tools or AI to build a working prototype that defines the “what” (Acceptance Criteria).
The Generation: The PRD is generated from this prototype (often by AI describing the prototype’s behavior, from understanding the code).
The Alignment: Humans (PMs and Engineers) review this text PRD. This is critical. We still need a written agreement of what we are building to ensure alignment.
The difference is that the text is now more accurate by default because it describes a working model, not a vague idea. Once this PRD is approved, it flows into the technical deep dive (RFC - Request for Comment). Small teams with simple technical architecture can also skip PRD + RFC and just have one PRD or an “Implementation Plan” document.
The AI-Native Workflow: 100x Leverage
We are entering a phase of software development that Kent Beck (creator of Extreme Programming) recently summarized perfectly:
“The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x.”
The 90%—syntax, boilerplate, memorizing APIs—is gone. The 10%—system design, architecture, and intent—is everything. Your SDLC must reflect this. We aren’t building a process for humans to type code; we are building a pipeline for AI to generate it safely.
The New “Design Phase”: The Interactive Interview Once the PRD is approved, we move to the technical “how.” Founders often worry that writing RFCs (Request for Comments) takes too long. They are right—typing takes too long. But we don’t need to type anymore. We need to curate.
Ingestion: The AI ingests the approved PRD and the Prototype.
The Interview: Instead of an engineer writing an RFC from scratch, the AI initiates a dialogue. It asks the smart questions: “How should we handle latency here?” “Is this data sensitive?” “What happens if this API fails?”
Generation: Based on the human’s answers, the AI generates the RFC / Tech Spec.
Crucial Step: The Human-in-the-Loop Review This is where the “Beck 10%” comes in. You do not let the AI proceed to coding immediately. A Staff Engineer or Tech Lead must review the generated plan.
If multiple teams are involved, multiple humans must review.
This is a critical gate. The AI is the engine, but the human must be in the loop.
Implementation, Testing & Deployment (SDLC 3-5)
Execution: AI Agents and Red Teaming
Once the human approves the plan, the “Coding Phase” changes dramatically. (More details in another post, otherwise this one explodes.)
However, you will have multiple, potentially hundreds of agents working for you:
Builder Agents: Write code based on the approved RFC.
Tester Agents: Independently look at the Acceptance Criteria (from the PRD/prototype) and writes tests to break the Builder’s code.
Red Team Agents: Scan for security vulnerabilities and logic gaps.
The human engineer stops being the “bricklayer” and becomes the “site foreman,” overseeing a squad of AI agents to ensure the house is built to spec.
Maintenance (SDLC Step 6)
Technical Debt Negotiation & The Inevitable Crash
Finally, how do you handle technical debt?
In scale-ups, this is often the source of the deepest friction. Commercially driven founders want speed; engineers want quality.
1. The Baseline: 5-15% Allocation Is Typical In Scale-Ups
Scale-ups typically allocate 5-15% of every sprint or quarter to managing technical debt. More important than the percentage are the following three items:
Clear Acceptance: Acknowledge that debt exists and requires service.
Transparency & Visibility: Every maintenance item must be a ticket, and every ticket must be tagged. Very often, commercial founders get frustrated that the team is slowing down, but they don’t see the invisible mountain of bugs and KTLO work. If you don’t tag it, you don’t track it, and you have no data to defend your velocity. You need this baseline visibility before you can even start negotiating a 15% budget.
Negotiation: Prioritization is key. These items go on the board next to features. If a commercial goal is critical, debt waits—but it is a conscious, negotiated choice, not an accident.
2. The Reality: The “Hard Way” Learning Curve
Most aggressive scale-ups will initially invest near-zero in code quality.
The Cycle: Founders push the team too far -> Quality degrades -> A major incident or escalation occurs.
The Lesson: This crash is often necessary. Founders usually need to feel the pain of a downed system or a lost client to truly internalize the need for prioritization maintenance work and technical debt.
The Fix: When this inevitable escalation happens, use it. That is the moment to institute the 5-15% rule. It is the tuition cost for teaching your founder technical debt. ;)
The Signal:
Use data (tools like Swarmia or Linear) to tag tickets as “KTLO” (Keep The Lights On).
When you see that >30% of a team’s time is spent on KTLO, you don’t negotiate a roadmap change based on feelings. You have data. Then you get to fix the root cause.
Killing the Blame Game: The Hierarchy of Action Items
When things go wrong (and they will), you need Post-Mortems. But startups often run “Blame Games” (finding a scapegoat) or “Therapy Sessions” (venting frustration) that result in zero actual change.
The core philosophy: You cannot fire your way to reliability. If a human made a mistake, it is because the system allowed them to.
To fix this, steal this rule from Google SRE culture. Every Post-Mortem must produce action items, prioritized by this hierarchy:
Prevent (Best): Fix the system so this class of error is technically impossible in the future. (e.g., “Automate the deployment pipeline to reject bad configs”).
Detect (Good): If we can’t prevent it, ensure our AI agents catch it within seconds, not hours.
Mitigate (Okay): If it breaks, make the manual fix faster (e.g., “One-click rollback button”).
Process (Weak): “Update the Wiki” or “Tell engineers to be careful.”
The Rule: If your Post-Mortem only results in “Process” items (Level 4), reject it. You cannot “scold” an AI into being more careful, and you cannot rely on “hope” as a strategy for humans. You must fix the system.
Want to learn more about the AI SDLC or building unicorn-level tech teams? Tekkr recently shared some of our hard won insights in a white paper.
Summary
Introducing the (AI-) Software Development Lifecycle in your startup is not about slowing down. It is about building the engine that allows you to drive fast without the wheels falling off.
The Scale-Up Context: The transition from Series A to C breaks natural collaboration. More formal SDLC process is the only cure for the “Velocity Paradox.”
The Strategy: Don’t invest equally. Over-invest in the “Edges” (Planning, Design, Maintenance) while automating Implementation.
Human-in-the-loop: Prototype-First, Text-Second. The PRD is critical for alignment, but it must be generated from a working model and reviewed by humans. So must the RFC.
The Maintenance: Allocate 5-15% of capacity to technical debt, tag everything for visibility, and use the inevitable “crash” to enforce prioritization.
Are you ready to build the engine? Tekkr helps Executive tech leaders in VC-backed startups scale their tech organizations successfully. We provide a digital chief of staff that delivers critical organizational improvements and business outcomes. Learn more at www.tekkr.io.