This Is Not a Story About AI Doing the Work
There is a version of this story that gets told a lot right now.
A business plugs into an AI tool, the AI builds something impressive, everyone is amazed. That is not what happened here.
Building Control Tower has been a deliberate, human-directed process from day one. Travis Whyte, Flight Plan Marketing’s owner and project manager, sets the direction and defines what gets built. Chris Gaudreau, our solutions architect and web developer, leads the technical sessions, makes the architectural decisions, and owns the quality bar. AI is the engine they point.
The result is a custom project management platform that a small team built to a professional standard, shipping real features on a cadence that would be impossible without the tools they’re using. Here’s exactly how it works.
The Stack
Control Tower is built on a modern web stack. The front end is Vue.js. The back end is Laravel. GitHub handles version control, code review, and deployment. Notion is where ideas live before they become features. Claude Code is the AI build partner in active development sessions. And Control Tower itself tracks how the finished product gets used through built-in usage telemetry.
Each tool has a distinct job. None of them overlap in ways that create confusion about who or what is responsible for a decision.
This Stack Wasn’t Downloaded From a Tutorial
None of this came together overnight, and none of it came from a template.
The tools Travis and Chris use today are the result of years of deliberate study, experimentation, and hard-won experience across real client projects. There is no shortage of platforms promising to do what Control Tower does. Base44, Lovable, Bolt.new, Bubble — the AI-powered “describe your app and we’ll build it” category has exploded, and for good reason. For quick prototypes and simple internal tools, some of them are genuinely useful.
Control Tower is not a prototype, and it isn’t simple.
Those platforms make speed possible by making decisions for you: they choose your database, your infrastructure, your architecture, your hosting. That works until it doesn’t, and it tends to stop working at exactly the point where a real business needs the tool to do something the platform didn’t anticipate. You hit the ceiling, and there’s no way through it.
Vue.js and Laravel weren’t chosen because they were trending. They were chosen because Chris knows them deeply and can architect around their strengths and limitations. The GitHub workflow wasn’t adopted from a blog post. It was shaped over time into a process that fits how this team works and what they need to trust. The way Claude Code gets used in a session, the way Notion structures a brief before the session opens, the way telemetry closes the loop after a feature ships: none of that is default behaviour. It’s the product of years of knowing these tools well enough to compose them into something that functions as a system.
The AI in the workflow makes an expert faster. It doesn’t replace the expertise, and it certainly doesn’t replace the years it took to build it.
Where Every Feature Starts: Notion
Before anything gets built, it gets written down.
Travis and the Flight Plan team use Control Tower every day. When something breaks or a gap becomes obvious, it goes onto one of two Slack canvases: Bugs or Wishlist. Chris pulls items from those canvases and brings them into Notion, where they become structured feature briefs.
A good brief answers a few questions before the build session opens. What is the current behaviour? Why is it a problem? What should the new behaviour be? Are there edge cases that need to be thought through first?
That discipline matters more than it might seem. Time spent clarifying a feature in Notion is time saved not rebuilding something that was half-specified. It also means the development session has a clear target rather than an open-ended prompt.
Larger features get an additional step before code: a layout plan.
Wireframing With Claude
For anything with meaningful UI complexity, Chris and Travis plan the layout before a line of code is written.
Claude produces annotated wireframes that define the structure of a screen, the zones of information it needs to carry, and how those zones relate to each other. These aren’t pixel-perfect mockups. They’re thinking tools: a way to stress-test a layout decision before it’s baked into components.
The Control Tower dashboard, for example, was designed across seven named zones before it existed as code. A KPI strip across the top. A task panel showing what’s due this week and what’s overdue. A favourites section for pinned businesses and projects. A right-side panel carrying the timer, a live calendar feed, and team workload at a glance. A recent activity stream at the bottom right.
Each zone was defined with its contents, its purpose, and its relationship to the rest of the screen. When Chris opened the build session, he wasn’t figuring out the layout as he went. He was executing a plan.
The business cockpit view went through the same process: six zones, each annotated, each with a clear rationale. Dark header for client context and status. Health chips for open, overdue, in-progress, and done task counts. A full task panel with view toggles and filters. A projects and campaigns section. A business details rail. A notes panel running full height on the right.
Getting that structure right on paper first is what makes the cockpit actually useful instead of just full of information.
Building With Claude Code
Once the brief is clear and the layout is planned, Chris leads the build session with Claude Code.
The session is a conversation. Chris describes the change, discusses the approach, and makes every decision about what gets built and how. Claude Code handles the implementation: writing the Vue components, building out the Laravel logic, wiring the pieces together, and keeping the changes consistent with the existing codebase.
Work always happens on a separate branch. The live app keeps running for the team while a change is being developed. Nothing touches production until it’s been reviewed.
A few things are worth being direct about. Claude Code moves fast. A feature that would take a solo developer a full day to implement can move through a session in a fraction of that time. But speed without direction produces fast wrong answers. The quality of what gets shipped is a direct function of the quality of the thinking Chris brings into the session. The AI executes. The human decides.
That distinction is not a disclaimer. It’s the actual reason the output is good.
The GitHub Safety Net
Every change goes through GitHub before it reaches the live platform.
Chris opens a pull request for each feature or fix. The PR triggers an automated code review and runs the full test suite, a battery of checks that verify the change works as expected and hasn’t quietly broken something that was already working.
If the automated review surfaces anything, it gets addressed before the merge. Only then does the change go out.
This is the mechanism that makes fast shipping sustainable. Moving quickly through development sessions would be a liability without a gate that actually catches problems. The test suite is what lets the loop run fast without accumulating technical debt or sending broken features to the team.
Release Notes as a Communication Layer
Every meaningful change gets documented in Control Tower’s own release notes section, before the team sees it in the app.
The format is consistent: a plain-language description of what was broken or missing, a before-and-after explanation of what changed, and screenshots of both states on desktop and mobile. Tagged by feature area and severity. Dated and searchable.
This matters for a few reasons. The team doesn’t have to read code or sit through a demo to understand what changed. They can see it at a glance and immediately understand whether the change is relevant to how they work. It also creates an honest record of the product’s history: where it started, where it struggled, and how it improved.
A recent release illustrates the format well. Three related gaps in the task UI were fixed in a single session. First: task detail pages showed no business context, so you couldn’t see client information without navigating away. The fix added a Business Overview card to every task linked to a client. Second: status and priority badges in the business cockpit task list were purely decorative. Clicking them did nothing. The fix made both badges interactive with inline quick-edit popovers. Third: project pages were showing tasks in a plain card with no view controls and a hard cap of 20 items regardless of how many tasks existed. The fix replaced the card with the full task panel, including list, kanban, and calendar views, an active/done filter, and an Add Task button.
Three issues. One release. Documented with before-and-after screenshots. Shipped and visible to the team the same day.
Telemetry: The Feedback Loop That Never Closes
The final piece is usage telemetry built directly into Control Tower.
Travis and Chris track how the platform gets used in production through a developer view inside the app. Total events, active users, feature engagement by area, top pages by visit count, and per-user activity all surface in one place.
The data tells a clear story about where the team actually lives in the product. Tasks and Businesses account for the majority of feature interactions. The Tasks Index and Businesses Index are the most visited pages. The Dashboard is third. That distribution shapes where polish and performance improvements get prioritized.
It also raises useful questions when something unexpected shows up. Low engagement on a feature that was built to solve a real problem might mean the feature isn’t working as intended, or it might mean it’s buried somewhere the team doesn’t naturally navigate to. Telemetry doesn’t answer that question on its own, but it surfaces it in a way that a conversation can resolve.
The loop it creates is tight. The team uses the platform, telemetry records where and how, that data informs the next round of canvas items, and the next session addresses them. The tool gets a little sharper every cycle.
What This Model Actually Enables
A custom platform of Control Tower’s scope, built by a traditional agency or development shop, would represent a significant multi-year investment. What Travis and Chris have built is a professional-grade tool, maintained and actively improved, on a timeline and budget that reflects the actual size of the team it serves.
The AI tools in the stack didn’t make that possible by removing humans from the process. They made it possible by compressing the distance between a well-specified idea and a shipped, tested, documented feature.
The humans still have to do the hard thinking. The product has to be defined, the architecture has to be sound, the quality bar has to be held. What’s changed is how much raw time and technical overhead sit between good thinking and a working result.
That compression is the real story. And it’s one worth paying attention to.
Final Thoughts
Control Tower isn’t finished. It’s never going to be finished, because the team’s needs keep evolving and the loop keeps running.
What it is, right now, is a platform built exactly for the people using it, by the people who understand their work best, using tools that let a small team move like a much larger one.
The AI didn’t build Control Tower. Travis and Chris did. The AI just helped them get there faster.