The Best Workflow for Building in Public as Solo Dev

The Best Workflow for Building in Public as a Solo Game Dev

Being a solo game developer can feel like shouting into the void. You pour your heart and soul into a project, battling feature creep and motivation dips, all while wondering if anyone will ever actually play your game. Feedback feels sporadic, unfocused, and rarely translates into tangible progress.

I want to share a strategy that helped me break through that void: building in public. But not just passively collecting feedback. I mean actively using public accountability to drive development.

My “Build in Public” Milestone: Implementing Core Combat

Let’s rewind to three months ago. I was stuck. My action RPG had beautiful environments, but the core combat felt… unsatisfying. I had a vague sense of what I wanted (think Dark Souls meets Hades), but couldn’t translate it into code.

Motivation was plummeting. I was adding features I thought were cool, instead of focusing on the core experience. The anticipated hurdles? Animation blending, input buffering, enemy AI… basically everything.

My “before” state was a mess. I needed direction and, honestly, a kick in the pants.

The “Build in Public” Implementation: A Step-by-Step Walkthrough

Here’s how I weaponized public accountability:

Documenting Goals: Clarity is Key

First, I defined clear, achievable targets specifically for the combat milestone. “Improve combat” wasn’t enough. Instead, I aimed for:

• Implement basic attack animations for the player character.
• Create a simple enemy AI with basic attack patterns.
• Implement a dodge roll mechanic with invincibility frames.
• Get the core combat loop feeling “fun” (subjective, but measurable via playtesting).

Choosing a Platform: Where to Share the Journey

I chose Twitter. Why? It’s immediate, accessible, and perfect for short, visual updates. My target audience (action RPG fans and fellow indie devs) hangs out there. I avoided a full devlog for this milestone, since the commitment felt too high upfront.

Regular Updates: Transparency Builds Trust

I committed to posting at least three times a week. These weren’t polished trailers. They were raw, unfiltered glimpses into the development process:

• Short gameplay clips showcasing attack animations (even if buggy).
• Screenshots of the enemy AI behavior tree.
• Progress reports on the dodge roll implementation.
• Asking simple question to followers.

I included #gamedev and #indiedev hashtags to maximize visibility.

Soliciting Specific Feedback: Asking the Right Questions

This is where I shifted from passive feedback collection to active engagement. Instead of asking "What do you think?", I framed specific questions:

• “Does the attack animation feel impactful? What could be improved?”
• “Is the enemy AI challenging but fair? Or just frustrating?”
• “Does the dodge roll provide enough invincibility? Is it too long/short?”

The key is to focus the feedback and make it actionable. Avoid general opinions that don’t lead to progress.

Lessons Learned & Iteration: A Post-Mortem

Analysis of Feedback: Filtering the Noise

I received a mix of helpful and… less helpful feedback.

• Helpful: Specific critiques on animation timing, suggestions for enemy attack telegraphing, and pointing out input lag issues.
• Not Helpful: “The graphics look bad” (without specifying why), feature requests unrelated to the core combat, and overly negative comments with no constructive criticism.

I learned to prioritize feedback that directly addressed my goals for the combat milestone. I also developed a thick skin and learned to ignore irrelevant or purely negative comments.

The helpful feedback directly influenced development. I adjusted animation timings based on viewer suggestions, improved enemy attack telegraphing to make combat fairer, and implemented input buffering to address the input lag.

Addressing Common Mistakes: Avoiding the Pitfalls

• Oversharing: I initially shared everything, including internal code struggles. This bored most people. I learned to focus on the player-facing aspects of development.
• Getting Derailed by Negative Comments: Early on, a few harsh comments threw me off track. I realized that not everyone is your target audience, and some people just want to be negative.
• Scope Creep from External Suggestions: People suggested cool features, but I stayed focused on the core combat loop. Saying “no” to distractions is crucial.

The Impact on Motivation and Project Direction: The Power of Accountability

Building in public was a game-changer. The public accountability kept me motivated. Knowing that people were following my progress, I felt obligated to deliver.

It also helped me refine my project direction. The specific feedback I received helped me identify and address weaknesses in the combat system.

The Studio Retrospective

Looking back, building in public wasn’t about getting endless praise. It was about forcing myself to be accountable. It wasn’t about getting all the feedback, it was about getting the right feedback at the right time.

It wasn’t about endless feedback, it was about being accountable. It forced me to clarify my goals, stay focused, and iterate based on real user input. It also helped me overcome the isolation of solo development.

If you’re a solo dev struggling with motivation or direction, I highly recommend giving building in public a try. Start small, document your goals, share your progress, and ask specific questions.

The real power of building in public isn’t the feedback itself, it’s the accountability that drives you to finish. It’s about showing up, making progress, and letting the process keep you on track.

Want to keep a detailed record of your game development journey, track your milestones, and analyze the feedback you receive? Start your game dev journal today and take control of your project’s destiny. Start your free game dev journal here