How We Plan Projects to Ship Insanely Fast
See how Clueso plans and executes software projects to ship at lightning speed without sacrificing quality. From design to deployment, here's the exact step-by-step process we use to maintain startup velocity as we scale.
I’ve been working with my co-founder, Prajwal, for over five years now. Over this time, we’ve been on a non-stop journey of hacking together different products and chasing different customer bases.
Somewhere along the way, we developed a kind of telepathic communication. We could exchange a single sentence with each other, and that was often enough to get an entire feature built.
That one sentence would be enough for me to mock something up quickly in Figma—or skip design entirely and directly build the entire frontend on React—while Prajwal would have the backend logic and entire infrastructure ready by the time I was done. There would be no tickets, meetings or handoffs. Just building and shipping.
But over the last eight months, as we’ve started to see early signs of PMF with Clueso, we’ve expanded our engineering and design teams. And with that growth, we’ve had to radically rethink how we work.
What worked brilliantly for a two-person team of jacks-of-all-trades-and-masters-of-none doesn't scale. Now that we have specialists—designers who deeply think through user flows, and engineers focused on clean architecture—the quality of what we’re shipping has leveled up dramatically. Our product no longer feels like a huge pile of features. But that also means our old ways of working don’t work anymore.
We’ve had to get a lot more intentional about planning, collaboration, and communication, so we can maintain our speed without compromising quality.
In this post, I wanted to share the step-by-step process we now follow to take a project from idea to production, and what’s helped us move fast without breaking things.
Design the new feature
The more thought and planning that goes into the design phase, the faster everything moves later. It’s easy to put together a few concept screens in Figma—but great design goes beyond visuals.
Designers need to imagine how the feature will actually be used in the real world, anticipate edge cases, and map out complete user flows. Not just the happy path.
At Clueso, we’re building a video editing platform. Like any powerful design tool, it can lead to an almost infinite number of user states and interactions. In the past, when our designs only covered broad concepts and not end-to-end workflows, engineers would often hit roadblocks. Either they’d get stuck midway and need multiple back-and-forth meetings with designers to clarify behavior—or worse, make assumptions, build something incorrectly, and then have to redo it after more rounds of meetings.
The goal is to reduce the engineer’s job to pure implementation, not interpretation. When that happens, development becomes far more predictable, efficient, and frustration-free.
Plan out the implementation
A day spent planning can often save 3 days of development. Before we write a single line of code, we break down projects into extremely granular issues in Linear, with clear time estimates for each one. Only when you do this do you get a realistic estimate of how long the project is actually going to be.
That clarity is critical. Without it, it’s dangerously easy to fall into the trap of saying, “We can build all of this in 4 days,” and then veer completely off track.
More than once, I’ve made this mistake. When customers, designers, or even my co-founder, Neel, asked how long something would take to build, I’d confidently blurt out a number—usually something like three days. Sure, I might be able to get it done in three days—if I worked nonstop, skipped weekends, and gave up on sleep—but that’s not a sustainable bar for the team.
It’s hard to let go of that “build fast at all costs” mindset, but I’ve come to believe that it’s much better to set a realistic deadline with a small buffer—and hit it—than to set an aggressive one and miss it repeatedly.
It goes without saying, when you hit deadlines, everyone wins:
Product teams understand their real shipping velocity and can plan the roadmap more effectively
Engineering teams stay motivated because they’re working toward achievable goals. As soon as the deadline gets crossed, you’ll sometimes see an engineer’s motivation to keep working hard on that project suddenly drop.
Sales teams know what they can promise to prospects
Support teams know what they can share with existing customers
In the long run, building a system that helps you consistently predict deadlines is much more useful than blindly shipping things quickly.
Break down the deployment strategy
At the planning stage itself, we try to cut out as much as we possibly can. Not because we won’t build it later, but because it doesn’t have to go out in v1. It’s far better to get something in the hands of customers quickly and start learning.
We cut corners with the mindset of making as many intermediate deployments to production throughout the project as we possibly can. That keeps the scope focused, accelerates delivery, and ensures designers don’t feel like their work is being discarded or thrown away.
When you are phasing out the deployments this way, communication between engineering and design is extremely critical. This is something we’ve learned the hard way. When engineers or PMs take shortcuts to move fast (which is sometimes necessary!), designers who envisioned the feature need to be in the loop. Nothing feels worse than discovering the shipped version looks or behaves differently from what was designed.
Track project progress
As a project moves forward, tracking progress becomes just as important as planning it. For engineers (myself included), it’s easy to feel like you’re making solid progress, until you realize you’ve hit the classic trap: “I’m 80% done”… but the last 20% is where 80% of the work actually lives.
That’s why we rely heavily on Linear, not just to manage tasks, but to forecast delivery. When every issue is broken down granularly with time estimates, Linear’s progress graph gives us a real picture of how far along we actually are. It even predicts the delivery date based on recent velocity, which has been incredibly useful for keeping teams aligned.
Early on, we allowed everyone to manage their work however they liked—some used issues, others dumped all tasks into a checklist, some just kept it in their heads. That flexibility worked for a while, but as we grew, it started to break down. Tracking and communicating progress clearly became impossible.
So instead, we decided to mandate a single system of project tracking that everyone needs to abide by as they build.
Rather than inventing this system ourselves, we decided to follow Linear’s recommended approach. Linear is a very opinionated tool: there really is only one way the builders of Linear want us to use it, which they’ve explained in full depth across they’re docs. The further we’ve gone, the more we’ve learned to stop re-inventing the wheel and just follow their playbook. Mandating a single system and process has helped us coordinate and move much faster.
That said, there are two small but important places where we’ve consciously deviated from Linear’s recommendations:
We ask engineers to post project updates every 1-2 days. Linear recommends weekly updates, but in our world, that’s too slow. We expect our engineers to make meaningful progress every single day, and going a full week between updates makes it hard to pinpoint where things are.
We work on Saturdays: Linear’s system assumes a Monday–Friday workweek, but we’ve extended ours to keep up a high momentum.
Ship to prod!
Once we ship to prod, we jump straight into doing what we do best: making videos on Clueso to announce the new feature.
For every launch, we typically create three kinds of videos:
A launch video for social media: Aimed at people who don’t yet know us. Short, eye-catching, and focused on the “why.”
An explainer video for our docs site: Targeted at users who want to understand exactly how the new feature works.
An announcement video for existing customers: Focused on what’s changed and how this launch fits into the bigger picture of what existing customers are already used to.
This is always a fun phase. We get to use our own product (often the very feature we just built!) to create the launch content. It’s a great way to validate the user experience we just shipped.
And of course, we celebrate every deployment. Sometimes that’s cake and ice cream, sometimes it’s a team dinner. After a big push to production, we also try to give the team a few days of lighter work before jumping into the next big thing.
Run a post-mortem
At the end of a project, it’s tempting to dive straight into the next one. Rather than that, we’ve found it incredibly valuable to pause and spend a couple of hours analyzing what went well and what could be improved.
In earlier projects, we skipped this step—and we ended up repeating the same mistakes, over and over, without realizing why things were going wrong.
Our current approach to post-mortems is simple: we review all the daily project updates posted by the team during the project. This gives us a clear picture of where estimates went wrong, which parts took more time than expected, and exactly when things started to go off track.
Without that written record, it’s easy to fall into the trap of he said/she said and misremember what actually happened.
Of course, we’re only 8 months into this journey, so I’d really love to learn from other founders and product managers too. What’s worked for you? How have you changed the way you’ve worked with an expanding team?
