Switchback SDLC

It’s Tuesday morning. A PM is waiting on comps that were promised last Thursday. The designer is waiting on answers product owes her from a meeting that keeps moving. The engineer has the ticket open, knows the fix in his head, and has nothing he’s allowed to build yet. Three capable people, all blocked, all busy. That’s not a dysfunctional team. That’s the relay working exactly as designed. Hold the picture; we’ll run it again at the end.

This is an opinionated account of how we actually build, not a balanced survey of AI in software. It’s written for people who want to change how they work, and it’ll ask a real trade of you: async by default with live workshops when the climb needs them, throwaway builds treated as a tool, design done in the running product, and a habit of seeing the next turn and taking it rather than waiting to be handed it. This is how we build at Frequency. We run it every day. It cost us the daily standup, the comprehensive comp, and the comfort of being the only hands on the work — and we’d make the trade again. And if you run an engineering org, read it as an economics argument first: the unit cost of a working version collapsed, and most processes still price it like it’s expensive. Everything below follows from repricing that one input.

Building software used to be a relay race. A spec slid from product to design to engineering, each discipline taking its turn, each waiting for the one before. That made sense for a long time. It doesn’t anymore, and the reason is smaller than it sounds. Almost nothing about how we build needs to change. The steps are the same ones the industry already trusts. The disciplines are the same. The loop is the same. What changed is that AI touches a few specific points along the way, and those touches quietly rearrange everything around them. Product development and software development used to take turns.

Now they climb together. And the titles blur as they do: a PM can stand up the working prototype that used to require an engineer, and an engineer gets pulled into the product calls that used to arrive already decided. AI lets anyone produce the asset a given step demands, so who does the work stops being fixed by job title and starts being whoever’s closest to the question. None of these moves are new. Being able to afford them is. Once you can, the old order stops fitting, and a different one falls out almost on its own. Switchback is what you get when you stop bolting AI onto the old order and instead ask, at every single step, where it actually does its best work, and where it does none, then let the honest answers redraw the sequence. Map keeps its hands off the vision. Explore hands it the wheel. Every step uses AI exactly as much, and as little, as that step rewards. The name comes from how a trail takes a mountain too steep to walk straight up — it cuts back and forth across the slope, and every turn is what makes the climb possible. Hold that picture too; the whole method lives inside it.

Picture the old ways of the software development life cycle for a second. Not one way, really. We tried a lot of them, and we kept trying to fix them. Waterfall marched a spec down a line of specialists. Scrum chopped the march into two-week pieces and called the pieces sprints. Kanban put the work on a board and watched it flow. The V-Model folded the line into a V so testing finally answered back to requirements. Boehm’s Spiral wrapped it in risk-driven loops. Agile made short iterations the default. They argued about cadence and ceremony and who owned what, and the arguments were real. But pull any one apart and underneath they all kept the same shape: requirements, design, build, test, passed between the same people in the same order, work mostly moving between disciplines in well defined handoffs. We made the loop smaller and faster, and never touched its shape. The wall just got repainted every few years.

Fidelity only climbed. An idea started as a sketch, became a comp, became a build, and each step cost more than the last. So going backward was expensive. You committed to a direction early, while everything was still cheap, and then you poured your real effort into raising the fidelity of that one bet. Trying five ideas for real? Building the thing twice on purpose? Nobody could afford that. We called it process, and we shipped, eventually.

That shape only ever made sense because building was the expensive part. So you protected it. You front-loaded everything cheaper than code, you handed off cleanly between specialists, and you waited your turn. Reasonable. For about thirty years.

Then the cost of reaching a working version fell through the floor, and the relay stopped making sense at all. Suddenly anyone could reach working software, and everyone went their own way with it, improvising in every direction with AI and no shared shape to climb.

So here’s where most teams actually landed. The old walls came down and nothing went up where they’d been. What you get instead is a quieter kind of mess. Nobody’s sure who’s holding what. An agent runs a research spike, hits a fork, and stops to ask the one question only product can answer, and product is heads-down in another meeting, so the spike either stalls or engineering guesses. You try ten directions in a week and throw most of them away, which is the whole point, except now you can’t tell what any of it added up to, or whether the codebase got better or just bigger. Progress stops being something you can feel. You shipped a lot of motion. You’re not sure you climbed.

It flips the math on bite size, too. Agile shrank the bites to keep risk survivable back when building was slow and expensive. Now that a working version is cheap, you can afford bigger bites again: a whole microapp built in one pass to a working plateau — a real, usable version you stop and stand on, the resting point this method is named for — not a single feature nibbled off per sprint. Bigger bite, then stop and decide.

Before we walk the trail, three words have to mean something, because the whole climb runs on them: Value. Learning. Progress.

Value is working software in front of someone who can react to it. Not a deck, not a comp, not a description of what we’re going to build. It’s the earliest version a customer or a stakeholder can actually use and push back on. The sooner that exists, the sooner you know whether you’re building the right thing at all. Learning is what that reaction hands you. Every plateau is a question put to a real person: is this it, or did we just find out it isn’t? You don’t earn that answer by guessing harder up front. You earn it by getting something real in front of someone early and listening to what comes back.

Progress is the one that’s easy to fake — ten experiments and a busy changelog can be pure motion. Progress is climbing: the summit visibly closer because something real was learned, together, not in turns.

That’s the why. The rest of this is the how. We break the climb into twelve steps, grouped into four phases: Discover, Frame, Plateau Loop, and Ship. Each step has a job to do, a point where AI earns its keep and a point where it stays out of the way, and a gate to clear before you move on. Laid out on the page they look like a straight line, and they aren’t: you’ll cut back and forth between them all day, which is the whole point and the name. But you have to know the steps before you can leave them on purpose, so we’ll walk them in order first, starting where every climb starts: Discover.

So what’s a Switchback?

Look at how a trail climbs a steep mountain. It never goes straight up. It cuts back and forth across the slope, each turn trading a little extra distance for a grade you can actually walk. Try to march straight at the summit and you burn out a quarter of the way up. The hiker who zigzags looks like they’re going sideways half the time, and they reach the top first. The doubling back isn’t lost ground. It’s the only thing that makes the climb possible.

Building works the same way now. A switchback is the move you make the moment the climb tells you something you didn’t know at the bottom. You decide who it needs next and you pull them in, right at the altitude where they matter. Sometimes that’s product, sometimes design, sometimes no one but you. Each turn looks like sideways motion. Each one is how you keep your footing on a slope too steep to take head-on.

None of this is new behavior. Every row is something a good team always wanted to do. What’s new is that you can afford to. AI collapsed the cost of each step, so doubling back stopped being a detour you dread and became a turn you take without thinking. And once it’s that cheap, you don’t do it once a project. You do it several times a day. Agile said respond to change over following a plan, then made changing course cost a ceremony. This is that promise with the cost finally taken out. You don’t schedule the turn and you don’t apologize for it. You see the better line and you take it.

Here’s a real one, so the table isn’t hypothetical. Monday, forty minutes at the map. Tuesday, four directions on the screen by lunch, three killed by two o’clock. Wednesday, a walking skeleton the stakeholders clicked through themselves — and clicking it surfaced a story no doc would have found, which went onto the map before the meeting ended. Thursday, Reckon said rebuild: the foundation was wrong, and finding that out cost us a day, not a quarter. Friday, the second pass shipped its first two components to production while the feature they belong to stayed an open question. One week, five switchbacks, nothing lost. Check that against your current calendar — that’s the whole pitch.

That’s also the part most teams aren’t ready for. A process built to absorb one reluctant change of course will buckle when the team is switchbacking by the hour. The speed is the easy part. Being built for it is the work. Anyone can be pulled in at any altitude, which means everyone has to be reachable at any altitude. No one disappears into a two-week silo, because the climb might need them on the next turn.

And here’s what makes the doubling back sustainable instead of exhausting: you never climb back down past the last ledge. Every phase leaves one. Discover leaves you stories and a map. Frame leaves you named components and a spec. The Plateau Loop leaves you working systems. Each one is solid ground that holds while you cut back and try a different line above it. That’s why a switchback costs an afternoon instead of a sprint. You’re not starting from the bottom. You’re standing on everything the climb has built so far, and taking the next turn from higher up.

The walls were holding up deliverables

The walls weren’t bureaucracy. They were load-bearing. Every discipline needed weeks of solo work to produce its deliverable before the next one could start: design couldn’t move until product handed over a finished spec, and engineering couldn’t move until design delivered comps.

What changed isn’t the walls. It’s the deliverables. A spec, a comp, a working prototype — the things each discipline used to disappear for weeks to produce — got cheap and fast. And once a deliverable is cheap to produce, the person who makes it doesn’t have to be the specialist who always made it. Product spins up an experimental branch with a clickable preview, not to ship it, but to put a real thing on the table and argue for it. Design weighs in on UX against that running preview, then tweaks the components after they’re built, in the real interface, not in a file the build will only imitate. Anyone with the tools can move a deliverable forward. So the waiting dissolves. Not because we tore down the walls, but because the thing the walls were holding up got light enough to pass around. The disciplines stay. The twelve steps stay. We just reach for the right one at the right moment, instead of running all of them, in order, every time.

The real shift: who’s holding the pen

Look back at that walk up the trail. The interesting thing isn’t any single step. It’s who shows up for each one, and who steps away. That movement is the actual shape of Switchback.

One climb, three threads, no batons: the pen moves to whoever is closest to the question.

Here’s the unlock that makes the weaving possible. AI means non-engineers can actually do the steps now, not just describe them and wait. A PM can map and shape with real artifacts instead of a slide. A designer can generate concepts and refine components directly instead of filing a ticket and losing a sprint. The work moves to whoever is closest to it, because the tools finally allow it. We only ever handed off because one role physically had to do each part. That wall is mostly gone.

To be clear, this isn’t vibe coding . As Simon Willison and Thoughtworks keep saying, the discipline was never in the vibes. It’s in pulling the right people in at the right moment, and getting out of the way the rest of the time.

What it asks of you

None of this is free. The speed is the easy part to fall in love with. The hard part is what the model asks of the people running it and the process holding it together, and it asks something real of both. Every role gives up a comfort it’s had for years. And the whole thing leaks if you don’t build it to hold.

What it asks of people

Underneath all three is one demand that doesn’t sort by role: you have to move without being moved. The relay told you when it was your turn. Switchback doesn’t. Work goes to whoever’s closest to it, which means you pick it up, you don’t wait to be handed it. There’s no one assigning the next turn and no standup where your task gets read back to you. The model has no oversight to give and can’t afford the oversight you’d need. People who drive themselves forward thrive here; people who wait to be told what to do quietly stall the climb, and at this speed the stall is expensive. If you need someone standing behind you, the climb leaves without you.

Product has to stop being afraid of the codebase. Not to become an engineer, but to stop treating “the build” as someone else’s country. The unlock is vibecoding: spinning up an experimental branch and putting a clickable thing on the table instead of writing a document describing the thing you wish existed. You don’t have to make it work. You have to be willing to make it real enough to argue over. The comfort you give up is the spec as a finished handoff. The thing you gain is the ability to show an idea instead of pitching it.

Design has the harder adjustment, because it gives up the most. Two shifts. First, you stop thinking in screens and start thinking in design language and components, because the screen is the throwaway and the system is the substrate that carries forward. Second, and this is the one that stings, you weigh in on UX early with minimal exploration and let go of the comprehensive comp. You will not surface everything up front. Edge cases and rough spots will go unnoticed because you didn’t spend two weeks hunting them in a static file. And at this pace, that is fine. The thing you didn’t catch surfaces when the real build runs, and that’s the moment you get tagged back in to fix it against working software instead of guessing at it in advance. The comfort you give up is exhaustive certainty before anyone builds. What you gain is your fingerprints on the real thing, not on a picture of it.

Engineering shifts from writing every line to steering the work. You spend less time at the keyboard and more time shaping the spec, scoping work so it can run in parallel, managing the context each agent gets, and owning what clears the gate. You stay in the code, switchbacking as you go, not handing it off wholesale and walking away. The keystrokes were never the value. The judgment was, and now it’s nearly all judgment: what to build, what to reuse, what to throw away, what’s good enough to ship. The comfort you give up is being the one whose hands were on every line. What you gain is leverage you could never reach one keystroke at a time.

What it asks of process

Here’s the failure mode nobody warns you about. When doubling back is cheap, things fall through the cracks cheaply too. A user story surfaces mid-build and lives only in the head of whoever saw it. A stakeholder who should have been pulled in wasn’t, because pulling them in took three seconds and you were moving fast. A step got quietly skipped because the climb felt obvious. None of these hurt today. All of them compound. This is drift: the climb slowly diverging from what’s actually recorded, agreed, and known, until the map and the mountain are two different things.

The answer is not to slow down. It’s to build the connective tissue that makes a switchback safe. When you cut back to add a story, the story gets captured before you climb on. When you pull someone in, the loop knows they were pulled in. The gates earn part of their keep here: they’re not just quality bars, they’re drift checks, the place where you confirm the work still matches what everyone thinks it is. A team switchbacking by the hour with no process to catch what scatters isn’t agile. It’s just losing things quickly. The discipline is what turns speed into progress instead of motion.

What it asks of the org chart

And one ask sits above the roles, because it belongs to whoever runs the org. Switchback changes what you hire for, and what you stop hiring for. The team gets smaller and more senior — judgment is the input that multiplies here, so a five-person team of people who can make the Reckon call outruns a fifteen-person team that escalates it. Coordination roles thin out, because the gates and the one-home-per-artifact rule do most of the coordinating that used to take a layer of management.

Your own attention moves too. You stop reviewing effort — the standups, the status decks, the burndown theater — and start reviewing gates, because the gates are where the work either matches what everyone thinks it is or quietly stops matching. That’s the audit surface where a CTO’s attention actually changes outcomes. The trade runs all the way up: less oversight of motion, more judgment at the moments that bind.

How to actually run this

The model is only as good as the discipline under it. Here’s how to keep a fast, switchback-heavy team from turning speed into chaos. The principles hold no matter your toolchain. The specifics are how we run it at Frequency, offered as a worked example, not a mandate. Steal what fits.

What has to exist first

Switchback is an iteration model, not a from-zero one. It describes how you climb fast once the mountain is equipped, and it quietly assumes the equipment is already there. You don’t cut switchbacks up a bare rock face; you cut them into a slope that already has a trailhead, fixed lines, and a base camp. For software, that base camp is engineering’s developer experience, and most of it has to exist before any of this gets cheap.

Infrastructure that’s already standing. Environments, CI, deploys, secrets, the plumbing that turns a merge into something running. If standing up infra is still the project, you aren’t switchbacking yet. You’re cutting the trailhead, and that’s its own climb with more of the old shape to it.

A preview build for every branch. The whole model runs on putting a working version in front of someone who can react to it. That only pays off if every branch gets a real, shareable URL on its own. No preview builds, no cheap “let’s just see it,” and both Explore and Refine lose their footing.

Database migrations that are safe and boring. Reckon and Rebuild only make sense if throwing a build away doesn’t threaten the data under it. When schema changes are routine, you climb again from a higher ledge without fear. When they’re terrifying, the substrate stops being something you can stand on.

A defined brand and a real component system. Refining in the running product only works if there’s a design language and a component library to refine against. Without it, every screen relitigates fonts, spacing, and color, and the broad strokes from Explore have nothing to harden into.

Project setup that’s already solved. Scaffolding an app, wiring auth, adding a service, if these are bespoke every time, the cost of a working version never actually collapsed and the premise doesn’t hold. The work has to be assembling solved pieces, not reinventing the trailhead on every climb.

Under all of it is one line: Switchback works once you’re over the hump, iterating and shipping lots of things on top of foundations that are already solved. Engineering either walks in with a mature developer-experience stack or builds one first. There’s no version of this that runs without a base camp.

Who this is not for, and where it breaks

Switchback is not a universal claim. It earns its keep on a specific kind of work, with a specific kind of team, and the honest edges matter as much as the model. Here is where it strains or fails outright, so you can tell whether you are on the trail it was built for.

It assumes a working version is cheap. The whole model leans on the cost of reaching running software having collapsed. Where that is not true, the math changes. Deep systems work, novel algorithms, hard real-time, kernel and firmware, anything where the build itself is still the slow and expensive part, keeps more of the old shape, because you cannot afford to throw a build away and climb again. The cheaper your path to something real, the better this fits.

It assumes a small, senior, generalist-leaning team, and that is the load-bearing assumption.

“Anyone reachable at any altitude, no one in a two-week silo” only works if everyone can supervise agents, cross into a neighboring discipline, and make a real call when the climb hands them one. That describes a small, senior, AI-fluent group. It does not obviously survive juniors who cannot yet supervise an agent, strict specialization where people don’t cross lanes, or scale past a single squad, where “pull in whoever the climb needs” stops fitting in one shared head. We run it on the team it suits and stay honest that we have not proven it past that. The gates and the spec give less experienced people real structure to work inside, but structure is not judgment. This is a multiplier, and it multiplies whatever judgment is already there, including none.

And reachability has a cost the relay never charged. Async-first is not the same as always-on, but a team that can be pulled in at any altitude can also be interrupted at any altitude, and deep-focus time is the first casualty if you are not deliberate about protecting it. The same property that lets a designer tag into a running build mid-climb is the one that can shred a maker’s afternoon. You have to defend focus on purpose, because the model will not defend it for you.

And it needs the connective tissue to actually exist. A switchback-heavy team with no place to capture what surfaces does not get agility. It gets fast, cheerful drift. If your org cannot commit to one home per artifact and event-driven capture at the gates, the speed will outrun the record and you will lose things quickly. Regulated work can still run this way, but the gate gets heavier and the audit trail has to be real. Switchback is for teams that can trade the comfort of the relay for the speed of the climb, and mean it.

Stop waiting your turn.

Switch back to the better line.

None of the twelve steps are new. You’ve seen all of them before. What’s new is the question underneath them: at every step we asked where AI does its best work, and where it does none, and the answers wouldn’t sit still in the old order. So you don’t run the steps once, in order, single file. You switchback — mid-build, mid-loop, the moment the climb shows you a better line. Doubling back stops being a setback. It becomes how you move. Design ships a component while its feature is still an open question; product adds a story while engineering is three plateaus up. There are no turns left to wait for.

Run that opening scene again

Remember the PM, the designer, and the engineer from the top? Run it again, the new way. It’s Tuesday afternoon and they’re looking at the same screen, and it works. It’s rough, but it runs. The designer is nudging the spacing while they talk. The engineer is reading the spec they all agreed on this morning. The PM is asking the only question that matters now: is this the right thing, or did we just learn enough to do it better? Nobody is waiting on anybody. Nobody disappeared for two weeks. They are simply on the trail together, deciding whether to refine or to climb.

Objections

The honest pushback, answered.

Glossary

The vocabulary the model runs on.

Bibliography

Every idea Switchback resequences, and where it came from.