There was no single moment. No dramatic breaking point where everything fell apart. It was more like a slow drift — or death by 1000 cuts to be really dramatic — another tool added to the stack, another login to remember, another paid tier to unlock the feature you need.
We have been using third-party project management tools for years. The honest version of that story is that none of them ever quite fit. We compromised. We adjusted our workflow to fit the tool instead of the other way around. That is a reasonable trade-off when a tool does most of what you need. It stops being reasonable when you are doing it across five different tools and the friction starts eating into the work itself.
Notion was supposed to fix this. Fully customizable, infinitely flexible — it felt like the answer. And it worked reasonably well on our side of the table. When we brought clients in, though, the flexibility became part of the problem. A client managing a product launch or a fundraise already has a full plate. Adding a workspace to their mental load is asking a lot. Asana was cleaner but brought its own friction — we were paying for features we never touched, and those features cluttered the experience for everyone. Neither tool addressed the deeper issue, which was not the software itself, It was the accumulation of software and the overhead that comes with it.
The real cost of tool creep is not the line items on a credit card statement—as annoying as they are. It is the context-switching. It is onboarding every new client to a platform they have never used before and hoping they engage with it consistently. It is keeping five tools pointing in the same direction and finding out they have drifted when something falls through.
The problem that we were desperate to solve was not the overhead. It was the project lifecycle mismatch.
We often start a client relationship as a sprint — time-bound, focused, structured around a clear set of deliverables. Discovery, strategy, design, development. When that wraps, many of those clients convert to ongoing retainer work. The engagement does not end, it simply changes shape. It shifts from a sprint cadence to something closer to a software scrum model: a backlog, active work in progress, things blocked, things completed. These are two fundamentally different ways to think about work. Sprint thinking and scrum thinking are not compatible inside the same board layout. Every tool we used forced us to treat them as separate workflows — often in separate workspaces — even when they were the same client relationship evolving naturally over time.
So we built something.
Track was designed to map to the way we actually work. A project can start as a sprint and convert to a scrum without leaving the tool, without starting over, without creating a new workspace and migrating context. The board adapts. The template changes. The client never notices the seam between the two because there is not one. The relationship just continues.
That is the clearest way to explain what Track does that nothing off the shelf did for us.
What we did not fully anticipate was what building it would teach us. It is one thing to build a copy of something that already exists. It is harder and more interesting to build something that reflects the way you have actually been working for nearly two decades. Every feature in Track came from a real experience, a real friction point, a real decision we had made on a project somewhere along the way. That process validated things we had been doing instinctively and forced us to articulate why they worked — which made us better at explaining our process to clients.
It also freed up something less tangible. Project management is overhead. Necessary overhead, but overhead. The goal of any tool you use to manage work should be to get out of the way so you can do the actual work — the thinking, the creating, the problem-solving that clients hire you for. Track gave us that. Less tool-switching, less explaining where to find things, more time on the work itself.
We are not software engineers. We are builders and creators, and learning to work with the tools available to get a job done is how we have approached client work for a long time. Many of our clients are in deep-tech categories — physical AI, biotech platforms, highly technical fields that require real curiosity and a willingness to go deep before you can add value. We took the same approach to building Track: do the deep dive, align with what we know from experience, make a plan, and build.
The opportunity to build things that would have been too costly or technically out of reach even a few years ago is genuinely remarkable. We are not treating that lightly.
Track is not a product we sell. It is what we use. And the way we built it is exactly the way we approach problems for our clients — figure out what you actually need, then build that.
We think this is only the beginning of what that kind of partnership looks like.
The how is a different story. The stack we chose, the architecture decisions, the role AI-assisted development played in compressing what would have been a months-long build into weeks — that deserves its own breakdown. We are covering all of it in an upcoming Lab Notes post. If you are the kind of person who wants to know why we chose Next.js over the alternatives, how we structured the database for multi-tenant client access, or what it actually looks like to build a production tool with Claude Code, that is where we are going next.
