I used to think that if you had talented engineers and a good project manager, delivery would take care of itself. That belief lasted until about three months into my time at White Rabbit Group, when I was asked to review a project that had gone sideways in ways that had nothing to do with the quality of the people working on it.
The team was capable. The engineers were writing solid code. But there was no structured rhythm to how updates reached the client, no defined process for how fixes were prioritized, and no single place where anyone could look and understand where the project actually stood. It wasn't that people were doing poor work, it was that the system around them wasn't built to keep that work visible, organized, or predictable.
That project became the turning point because it made me realize we were managing tasks when we should have been designing a delivery system, and those are two very different things.
The thing nobody tells you about delivery
When I joined White Rabbit Group, the team was good. The engineers were sharp, the work shipped, the clients came back. What we did not have was a system you could promise. Every project had its own rhythm, its own surprises, its own version of "we'll figure it out as we go." That works for a while, until it doesn't.
The instinct, when delivery feels shaky, is to throw more management at it. More standups, more dashboards, more people checking in on people who are checking in on people. We tried some of that and it made things noisier without making them better.
So we did something less glamorous. We sat down and designed the actual system. Not a methodology lifted from a book, not Agile theater or Waterfall nostalgia. Just an honest answer to the question, what does an agency partner need from us to look great in front of their client every single time.
Plan like Waterfall, build like Agile, drop the rest
From Waterfall, we kept the discipline of planning before you build. Our architects lead an estimation and requirements phase before any code gets written, where we raise every question we can think of, confirm scope, and lock the technology decisions. That step sounds obvious, but I've watched enough projects bleed time in the middle because nobody asked the right questions at the beginning to know it's worth protecting.
From Agile, we kept the iterative execution model, sprints, reviews, retrospectives, and the constant feedback loops that prevent a project from drifting for weeks before anyone notices. If a standup isn't surfacing problems, we change how we run it. If a retro keeps recycling the same three observations, we restructure the format. We care about the outcome of a meeting, not whether the meeting happened.
The flow goes through seven phases: estimation, planning, kickoff, sprint execution, testing, launch, and then a formal retrospective where we capture what worked and what didn't. But the phases themselves are less important than the exit conditions between them. We think of these as gates, and the gates are the part of the process we protect most aggressively. Requirements have to be clear and agreed before planning can begin. The plan has to be approved before engineering starts. Work has to be tested before it goes live. And nothing closes out without a formal sign-off from both sides. We can compress timelines, run things in parallel, simplify steps when a project demands speed, but those gates don't get skipped, because every time a team skips one of them, the cost shows up later in rework, missed expectations, or a client who loses confidence.
Where projects actually fall apart
The most fragile handoff we deal with is design to development. The way it used to go: designs would land in Figma looking solid, and the development team would start building. Two weeks in, someone would notice that mobile layouts were missing, or that real content breaks the layout because placeholder text is a third the length of actual copy, or that an interaction nobody documented is now being interpreted four different ways. By the time any of this came up, we were already deep in the sprint.
What we changed was the principle behind how we treat assumptions. Now, every design includes a full working prototype with interactions and animations defined, not just static screens. Developers are in the design review before development begins, not after. They raise questions at that point. We run a checklist before a sprint opens to confirm every required screen and state is accounted for. The goal isn't perfection upfront; it's that the team is solving real problems during the build, not discovering missing context.
The same thinking applies to knowledge continuity when someone joins or rotates off a project. The handover is a structured session with a clear agenda, not a casual catch-up. Everything lives in ClickUp, in the scope document, in the change tracking sheet, so that when someone new comes in, they're reading decisions that were made, not trying to reconstruct them from memory.
The system is the system, the tools just help
We started with an internal project management tool that worked fine until the team grew past 50 engineers and the projects got complex enough that we needed better visibility across workstreams. We moved to ClickUp because it let us structure workflows the way we actually work instead of forcing us into someone else's idea of how project management should look, and because it handled both high-level planning and day-to-day task execution in one place rather than requiring us to stitch together three different tools.
But I want to be honest about something. The tool choice matters way less than most people think. ClickUp is good for us. Jira would be fine for someone else. The thing that actually makes delivery work is the discipline around how information is captured, where decisions live, and how changes get tracked. Our project specs are built in ClickUp docs or Google Sheets during the planning phase and locked in at kickoff, and every scope change gets documented in a separate tracking sheet that records what changed, why it changed, and how it affects the timeline. That sheet is the source of truth for the project, not a Slack thread from three weeks ago, not somebody's memory of what the client said on a call.
For communication, we keep it simple. Slack handles the day-to-day coordination. Email handles anything formal or client-facing that needs a paper trail. Google Meet handles structured discussions and walkthroughs. And when something critical comes up, the project manager picks up the escalation and pulls the engineering lead into a call immediately rather than waiting for the next scheduled check-in.
AI helps when the system is already there
We've been deliberate about where AI fits into the work, because the way most teams try to use it doesn't actually help them. You can't bolt AI onto a disorganized process and expect it to create order. What happens instead is it generates more output, faster, from a system that was already producing the wrong things.
The way it works for us: We do not use it to think for us, and we do not pretend it is a substitute for actual engineering judgment. We use it to chip away at the manual overhead that piles up in a busy delivery cycle. Summarizing long threads, drafting first-pass scope docs, accelerating repetitive UI work, running automated code reviews before work hits an architect's desk. These are the places where it pulls real weight.
AI works inside structure. Without structure, it just produces faster noise. So start by building the system, then let AI make it faster. That is the order, and reversing it is how teams end up with confidently wrong code in production.
How the process held up on a recent build
I want to walk through a recent project because I think the theory only makes sense when you see how it bends under real conditions, and the Lani Fischer build was a good example of that. The requirements were well-defined from the start, which was a relief, but the timeline was tight enough that we couldn't afford to run every phase sequentially the way we normally would.
So we started where we always start, with a full design review in Figma to make sure every screen, every interaction, and every edge case we could anticipate was accounted for. Then we built a sprint plan that broke the scope into phases we could deliver and validate incrementally, and we assigned resources specifically to this project so nobody was splitting their attention across two or three builds at the same time, which is one of the fastest ways to lose momentum on a tight timeline.
Where the process adapted was in the middle. We ran refinement alongside development on lower-risk components rather than finishing all the planning before writing any code. Approval cycles got shorter because we had already built the trust and the documentation habits that let us move faster without losing track of decisions. We leaned more heavily on AI for UI development and repetitive tasks than we normally would. And the whole thing worked, not because we pushed harder, but because the underlying structure was predictable enough that compressing it didn't cause it to fall apart.
Speed and quality are not a trade-off, they are a conversation
When clients want speed, teams feel that pressure. The default response is quiet compromise, where corners get cut and nobody mentions it until something breaks at the worst possible moment. We do something different, we make the trade-offs explicit in writing before we move. Faster delivery means a smaller phase one, tight timelines mean phased releases, and edge cases get a written plan and a post-launch slot. Nobody is surprised, because nothing is hidden.
Three quality gates run on every project regardless of size. Developers test their own work. QA reviews it independently. An internal call with leads and architects happens before anything ever reaches the agency. Same gates on a three-week build, same gates on a six-month one. Over the last year we added peer code reviews between developers and automated quality checks before architect review, both of which cut bottlenecks without lowering the bar. We also tightened the definition of done so every task has a clear end state going into the sprint. That single change took a surprising amount of fog out of the back end of our work.
The thing I wish more people said out loud
Most teams operate on the belief that good engineers produce good projects. It is a comforting idea, but it's also wrong. Good engineers produce inconsistent projects without a system around them, because every project becomes its own improvisation and every win depends on which engineer happened to catch which problem. Good systems are what let good engineers deliver the same quality on every project, not just the ones that go right by luck.
We are still building this. Mid-project scope changes are still slower than I want them to be. Consistency across teams, making sure the process feels the same regardless of who is leading, is something we are actively working on. The system works, but it can work better, and both of those things are true at once. If I had to give one piece of advice to someone building this from scratch, it would be this. Get your clarity right before execution starts. Always. Once you have that, everything else turns into an execution problem, and execution problems have answers. System problems do not, until you build the system.