Planning for small projects

This post will be a bit different. This time, I want to explain how I plan things with Shitlings and other small projects. I’ve noticed that many people struggle with organizing their work and breaking down tasks.

I’ll use the Shitlings announcement milestone as an example but will also cover how I plan for the long term.

So first: the tool. I've tried several options before, and to be honest, the simpler the tool, the better. I've worked with Jira, Asana, Trello, etc. But in the end, for smaller projects, something quick to use and easy to visually move things around works best for me. Bonus points if it makes adding images easy.

For Shitlings, I just use a Miro board. It allows me to quickly snap sticky notes wherever I need, move them around, cluster them visually, and paste whatever graphics I need. It really outweighs the complicated features other tools offer, which can end up being more of a burden than a help.

This is what my main board looks like:

Pretty, right?

Current tasks

For a long time, I didn’t really bother with larger milestones. I just had a section for current tasks, which I would fill with whatever came to mind at any given time, plus some small planning sessions every three weeks or so—just to set aside dedicated time to focus on the bigger picture. This is how my current tasks are structured:

Basically, I have several categories of tasks waiting to be tackled. There’s a section for tasks I want to work on first, along with sections for things to test, dropped ideas, and finished tasks.

When working solo or even in a small team, there’s no need for overly detailed descriptions or rigid priorities that will likely change over time. Even in large professional projects, managers struggle to keep task details from becoming outdated—so I just dropped that entirely.

Having everything in one board also makes it super easy to visually assess how much is left in each category, move tasks to the prioritized section, and keep track of progress.

Milestone

At some point, after most of the prototyping is done, it’s important to start hitting key production milestones. Sometimes, these milestones align with important events (Playtest, Announcement, Demo release), while others are more internal, like the end of the prototyping phase, vertical slice, or having the first two maps ready.

Let’s take a look at how I tackled the Announcement milestone.

First, I think of an ideal dream date for the event. Then, I write down the main categories of work that need to be done. This is important because some of the work will be outsourced, some done by me, and some handled by others.

Next, I list the key work items I can think of for each category. At this stage, some might be task-sized, while others are much larger. The important thing is to focus on work that directly contributes to the milestone’s success. So, I don’t add things that would be cool to work on but don’t impact the Announcement—like missing gameplay mechanics, for example. I only include what’s necessary to achieve my goal.

The next step is creating a rough timeline with more detailed tasks. I don’t assign specific dates to tasks; instead, I break the work into 2–3 stages, adjusting for the expected workload. This step is crucial because it highlights task dependencies and helps me predict whether my initial date is realistic.

It might look something like this (this is fake data—there were actually many more tasks):

Since I have multiple categories and stages, if I’m waiting on something in the Game path at any given time, I can see what tasks from other categories I can already work on. This is really useful because it’s easy to get consumed by one path and forget about other things that also need attention. If I had only one stage, I might end up rushing everything in Game or Steam while neglecting Social or Outreach. This structure helps balance the workload and makes progress more predictable.

At this point, I can start assigning dates. Here’s how I did it: I took my Announcement date from step one, added two weeks for the Milestone End (to allow for final outreach and posts), and then estimated how much time I’d need in between for finishing game development and Steam preparations.

This made it very clear that my initial date idea wasn’t realistic, so I adjusted everything accordingly. But I wouldn’t have realized this without proper planning. That’s why this process matters—not just the number of tasks, but also their relationships and waiting periods (like Steam verification or outsourced trailer sound and editing).

Highest level

After the announcement, it’s time to plan the entire game production. Of course, it’s impossible to map things out in the same level of detail as the closest milestone, but I want to have at least a rough estimate of whether the game can be released this summer, fall, or even next year. There are plenty of reasons why this estimate is important, but let’s not focus on that right now.

I start with the key production milestones. For me, these are:

• A big open playtest with most gameplay mechanics completed

• A high-quality public demo that I can showcase to the world and influencers

• The full release

Then, I break down the work for each of these key points into categories of tasks that need to be completed for the game itself (so no marketing here). Some tasks can be worked on in parallel, while others will mark major milestones. But at this stage of planning, that distinction isn’t too important.

Next, I assign optimistic time estimates (in weeks) to each task card. To do this, I need to assume a certain quality level that I want to achieve—which is probably a topic for a separate post.

This process allows me to start making assumptions about the overall production timeline. I use it to predict major external events I could participate in, determine when I’ll need the most funds for asset production, and plan accordingly.

Summary

And that’s how I do it. This process probably isn’t perfect, but so far, it’s worked really well for me. I have to say, using Miro and having everything in one massive dashboard makes it all feel seamless. I also keep separate dashboards for things like gathering ideas, defining the game’s visual identity, and quickly communicating core concepts to contractors.