Managing Development of my Indie Game In a CRM

Behind the scenes of planning FantasyBrawls Story Mode, from milestones and budgets to tasks, vendors, and quality assurance.

I've spent ten years building CRM systems for insurance firms, financial institutions, and healthcare organizations, and the most common way I see a project go sideways is that it ends up getting "managed" in five places at once. One healthcare client I worked with kept their client contacts in HubSpot, their patients in a claims processing system, an EHR alongside that, the budget in a spreadsheet, and task management in a SharePoint library, which meant a simple question like "where are we on this?" required opening five different systems and hoping they all agreed with each other. On top of all that, the actual plan usually lives in the project manager's head, which is the one system nobody ever backs up. So when work started on a Story Mode for FantasyBrawls, my browser-based monster taming game, I decided to run the whole initiative out of Super Easy CRM, the platform I built, and to write about it while it's still early and a little messy instead of waiting until I can dress it up as a tidy success story.

Why should a software project start as one record in your CRM?

Because a single project record gives the timeline, budget, owner, and objective one home, and everything that comes after it, from milestones to tasks to tickets, hangs off that record instead of floating around in separate tools.

The project is called Fantasy Brawls Story Mode, it's marked Initiated, and it has a start date, an end date, a budget, and a progress bar sitting right on the summary.

From that same screen anyone on the project can jump to its Tasks, Documents, Team, and Assets, so nobody is hunting through shared folders trying to figure out what belongs to Story Mode and what belongs to something else.

How do milestones make a nine-act project manageable?

Milestones turn "build Story Mode" into a series of checkpoints you can actually finish, and nine story acts happen to be a natural way to slice the work.

Right now the project has three milestone records, one for Act I and two for Act II, and the rest of the acts haven't been entered yet. Once all nine are on the board, it becomes very obvious whether the timeline is realistic, and that tells me far more than any amount of optimism over coffee. When a milestone slips, I'd rather see it slip on a dashboard early than discover it the week before launch.

What turns a creative idea into a task someone can finish?

An owner, a date, a priority, and a status, because without those four things a creative idea is just a note you'll feel guilty about later.

The task I'm using as my example is Revamp Omus Moveset. It's Open, it's Medium priority, and it has a named owner, so there's never a question about who is on the hook for it. The task record also has tabs for Description, Documents, Notes, and Project tasks, so the reference art, the balance notes, and whatever someone scribbles at midnight all stay attached to the work instead of scattered across desktops. There are also fields for Desired Time to Complete and Actual Time to Complete, and if you've read my piece on estimated versus actual time you know I think the gap between those two numbers is where project schedules get messed up.

A second task, Build mechanics around Act II Omus Battle, shows how a story beat becomes engineering work, since the narrative for Act II doesn't mean much until the battle itself plays well. A lot of my ideas show up while I'm driving or at my kid's football practice, and those already land in my CRM through the Google Tasks integration, which means the idea I talk into my earbuds doesn't die in the car.

The task board is where most of the day-to-day happens, because dragging a card between columns updates its status without leaving the project.

Why put a budget on the project record at all?

A budget forces you to choose priorities before you spend money, not after, and having it sit right next to the work makes those trade-offs hard to ignore.

The project overview shows how much of the budget has been used, which turns every spending decision into a question about what else that money could have gone toward. When the budget lives in a separate spreadsheet that gets updated once a month, nobody feels that trade-off until it's too late to do anything about it, and that's how small projects end up with surprise invoices and awkward conversations.

How do tickets keep problems from getting lost in email?

Tickets give every problem its own record tied to the project, and when a ticket type is wired to automation, the right person hears about it without anyone having to remember to forward an email.

Tickets are where anything that goes wrong during execution gets logged, from a late art delivery to a technical problem that needs its own attention. The one I care about most involves payments: if a Story Mode feature ever lets a player slip past the Pro tier without paying, that's money walking out the door, not a cosmetic bug. I already have a Stripe ticket type set up for exactly that, with an automation inside Super Easy CRM that tags every Stripe ticket as urgent and routes it to the right engineer, so a paywall problem never sits in a general queue waiting for someone to notice it. I wrote about this pattern in more depth in why ticket types should drive your automation, and the short version is that the ticket type does the remembering so people don't have to.

Why does a game need QA statuses instead of one "done" column?

Because "Completed" means the person building it thinks it's finished, while "Passed QA" means somebody actually checked, and those are two very different claims.

Beyond Open, In Progress, Needs Help, and Completed, the board also supports Not Completed, Submitted For QA, Failed QA, and Passed QA. For a game, that distinction matters a lot. The Omus moveset revamp can be finished and marked Completed, but if a new move makes Omus wildly overpowered in Act II, it belongs in Failed QA with notes on what broke, not quietly shipped because the card made it to the right-hand column. Keeping a failed review visible on the same board means the fix and its history stay in one place, and nobody has to reconstruct what happened from a chat log two weeks later.

What do I learn by running my own project in my own CRM?

Using my own software on a real project shows me friction that a demo never will, and every annoying click I find is one a customer has probably already cursed at.

I've always believed software should simplify work, not create homework, and the fastest way to test that belief is to put a real project with real deadlines inside my own product. I'm not going to pretend I've found a list of fixes yet, since the project is still early, but I'm keeping notes, and I'll share what changes as a result in the follow-ups to this post.

Can a CRM really run projects that have nothing to do with sales?

Yes, as long as it has real project tools behind it, because a project is just another set of relationships, deadlines, and commitments that someone has to keep straight.

Most people think of a CRM as a sales pipeline with a login screen. What Story Mode is being built with is a project record, milestones, a task board with real review stages, a budget, a team, and tickets wired to automation, all in the same system where my contacts and calendar already live. Before you go hire a project coordinator, it's worth asking whether your CRM can carry part of that load first.

If you're juggling a project across spreadsheets, inboxes, and sticky notes, you can try Super Easy CRM free and see whether keeping it all in one place makes your life a little easier. I'll be back with updates as the acts get built, and hopefully with fewer than zero Stripe tickets, which I realize is not mathematically possible but I'm aiming for it anyway.