How to Stop Feature Creep from Killing Your Game with Hovgaard Games

Hovgaard Games is a Danish studio behind the sim games Big Ambitions and Startup company. Big Ambitions launched in Early Access expecting modest success, but found a strong player base. Two years later, Hovgaard Games has grown to 10 people working remotely, steadily shipping updates every few months.

Same as most Early Access games though they also faced the question: how do you decide what’s core versus what’s post-launch? This isn’t about lacking vision. It’s about the reality of Early Access: every feature request feels valid, every complaint feels urgent, and saying “no” to engaged players feels risky.

I sat down with David, Producer and Community Manager at Hovgaard Games, to understand how they structure production when community feedback threatens scope, how they manage remote workflows, and how they prioritise what really matters.

The Early Access Reality: Success Can Create Scope Problems

Hovgaard Games initially started as a solo project but quickly attracted a strong player base, which led to the studio growing to 10 people. More players meant more opinions, more play styles, more feature requests.

David’s take: “The game did way better than expected, which is a great problem to have. But more players means more opinions, more features they want.”

Every feature request has logic behind it. Every complaint points to something real. You go from “let’s keep building” to “wait, are we just cramming in everything everyone wants?”

How they’re solving it:

Define What “Done” Actually Means

They’re releasing a roadmap that draws a line: “This is Big Ambitions 1.0. This is the core game. Everything beyond this is post-launch content.”

“At what point are we just taking everyone’s ideas? We have to say, this is the scope of the game, and here’s maybe some features that can come out later.”

Separate Core from Nice-to-Have

The question they ask: Does this feature make the game complete, or does it just make it different?

Some requests are required for the game to feel done. Others are “that feels like a post-content update—not required for the core.”

Accept You Can’t Please Everyone

“Everyone wants something specific. They all disagree. Some would hate what others love. You always risk when you add something new—you risk alienating what some people liked.”

If you’re two years into Early Access without a locked feature list for 1.0, you’re in feature creep territory.

The Staggered Production System: Don’t Wait Until You’re Ready

When Hovgaard was small, they could just start building ideas. As they grew to 10 people, that broke down. Artists waited on design. Developers waited on art. Bottlenecks everywhere.

The solution: David brought workflow structure from 15 years in TV animation. In animation, writers work on Episode 3 while storyboard artists work on Episode 2 and animators finish Episode 1.

How it works:

Design Works 1-2 Updates Ahead

While the current update is in testing, designers write documents for the next update. Design must be locked before artists create assets.

“You can’t wait until you’re ready for the next update to start designing. You have to create that flow.”

Lock Design Before Asset Creation

“We need design documents done first. So when artists start working, we’re not still figuring things out.”

This prevents wasted work. If design changes mid-production, artists redo assets. Expensive and frustrating.

Prevent Bottlenecks

“If five people are waiting on me, and I’m only one person, four people are gonna be waiting.”

Staggered production prevents this. Work always flows. If artists are creating assets for systems still “in testing,” you’re burning money on rework.

The Sprint System: Two Weeks, Flexible, Reality-Based

The structure: Two-week sprints. Not rigid—they adjust for holidays or urgent patches. But mostly two weeks.

Sprint Planning:

• All hands meet via Discord with cameras on
• Review what’s getting done
• Teams split off for detailed planning

Sprint Review:

• End of sprint, everyone presents work
• Cameras on to see reactions
• Critical for remote morale

What Goes In: They ask developers: “Here’s what we want. How much can you actually do?”

Accounts for vacations, patch work, unexpected bugs.

“We don’t plan sprints in the future. We see what we accomplished, adjust, and approach each sprint fresh.”

Designers and leads look long-term. But for individual developers: “That can be overwhelming. It’s easier to just say, I’ve got these 10 tasks. Next week is next week’s problem.”

Planning sprints 3 months out in detail? You’re lying to yourself.

The 3-Month Update Cadence

Push an update, patch it, and within 3 months, the next update hits Experimental branch on Steam.

The Experimental Buffer

Updates go to Experimental first. Players opt in, test, find bugs. This gives time to catch issues before full release.

“If we release too fast, there’s not enough time to test. If it’s too long, players feel like the game is dead.”

What’s In Each Update

• A few main features
• A few smaller features
• Quality of life improvements (“if there’s time, add as much as you can”)

“We pick main features, then have quality of life items. If something needs extra weeks, we have flexibility.”

Been in Early Access over 18 months and your roadmap keeps growing? You’re in trouble.

Remote Workflow: What Keeps Teams Connected

The setup: 10 people, fully remote, scattered time zones.

Discord as Office

Always-on Discord. Not just meetings—it’s their office.

Structured Face Time

• Sprint planning and reviews: cameras on
• Daily designer sync: 10-minute check-in
• Lead syncs: dev and art leads meet daily

“We try to make sure everyone feels like they can show off. People want to have something cool to show.”

Annual In-Person Meetups

Once a year, entire team meets. Critical.

“That first time you meet in person, something clicks. After that, you feel so much closer even on camera.”

Async Through Codecks

Not everything needs a meeting. They use cards for feedback, questions, tracking conversations.

“That lets us desync our syncs. We can communicate fluidly without all being online simultaneously.”

If your remote team only interacts in formal meetings, you’re missing human connection.

The Factory Mistake: What Happens Without Structure

The factory feature didn’t land well. Players like the concept but certain elements hurt experience.

Why: “Some things weren’t quite landing, but structure wasn’t in place, and things kept going forward.”

Design wasn’t locked before production started.

The fix: Current update reworks factories. They learned. Now design locks first.

How they recovered: Transparent communication. “We didn’t hit it out of the park the first time. We need to try again.”

Players gave them grace: “We’ve had players say they’ll wait till we fix it to play again. Not great, but they’re saying ‘wait until you fix it’ not ‘I’m done.’”

If you’re afraid to admit mistakes to your community, you’ve already lost trust.

The Feature Creep Prevention Checklist

Scope Control:

• Have you defined what “done” looks like for 1.0?
• Can you explain core features vs nice-to-have?
• Have you drawn a line between launch and post-launch content?
• Are you saying “no” to requests that don’t serve the core?

Staggered Production:

• Is design working 1-2 updates ahead?
• Are design docs locked before asset creation?
• Have you eliminated bottlenecks where people wait?

Sprint Structure:

• Are sprints 1-2 weeks (not longer)?
• Do you plan based on what was just done (not 3 months ahead)?
• Do developers have input on sprint capacity?

Update Cadence:

• Do you have a consistent update schedule?
• Are you using experimental branches to test first?
• Do you communicate timelines to your community?

Remote Connection:

• Do you have structured face-to-face time?
• Are you using async tools for ongoing communication?
• Do you have at least one in-person meetup per year?

Organization:

• Do you have separate decks for each update?
• Are you using tags to categorize work?
• Have you created templates for repeated workflows?

Closing Thought: Structure Serves People

What struck me most wasn’t Hovgaard’s Codecks setup or sprint cadence. It was David’s clarity about why structure exists.

It’s not about perfect processes or hitting every deadline. Structure exists to make people’s work lives better. To prevent bottlenecks. To let people focus. To make sure nobody’s waiting around.

As David put it: “Sometimes work sucks. But listening to that frustration and saying ‘I hear that’—that’s the difference between feeling motivated like ‘let’s make it better as a team’ versus ‘I’m just writing code into a void.’”

Your production structure should do the same.

---

Woww you read all the way through! 😻👏

You now have a blueprint for stopping feature creep. If you want more tactical breakdowns, check out our YouTube channel and join our Discord where game devs share real systems.

And if you need project management for remote teams, check out Codecks—built by game devs who get it.