How We Think
Work done slowly,
on purpose.
There's a certain satisfaction in watching something accumulate — a resource counter, a progress bar, a game slowly revealing its depth. We think the work of making those things should feel the same way: deliberate, unhurried, and better for it.
Back to HomeOur Foundation
What we actually believe
Most of what goes wrong in game design — and honestly in creative work of any kind — comes from moving too fast, taking on too much, or treating complexity as a virtue. We started Slowburn because we wanted to do the opposite of that.
The idle game genre is peculiarly honest about what games are. Players know they're watching numbers go up. They find that satisfying anyway — if the loop is shaped well. That's a real design challenge, and it's one we take seriously. The foundation everything else rests on is the belief that careful work produces better results than fast work, and that honest communication with clients is more useful than confident-sounding approximations.
Philosophy & Vision
A slower approach to a patient genre
Idle games ask players to trust the designer. The player sets something in motion and walks away — and when they return, the game should have behaved honestly. Numbers should have moved in a way that feels fair, not manipulated. Progression should feel like a natural consequence of the game's rules, not a psychological trick.
We think the work of designing these games should carry the same spirit. Take the time to understand what the game actually needs. Don't layer complexity onto something that's still finding its shape. Deliver something you'd be comfortable explaining in full — because we always are.
In Short
Idle games are built on trust between designer and player. We extend the same trust to our clients.
Complexity for its own sake isn't a feature. A clean, readable loop is usually better than an intricate one.
Good design work takes the time it takes. Rushing rarely saves time when you account for the revisions.
We'd rather decline a project that isn't a good fit than take it on and deliver something we're not proud of.
Core Beliefs
What shapes the work
These aren't mission-statement phrases. They're the things we actually come back to when a design decision is unclear.
Patience is productive
A decision made after sitting with a problem for a day is usually better than one made on instinct. We don't treat slowness as a problem to solve.
Clarity over cleverness
A progression system a developer can explain in two sentences is easier to balance, easier to extend, and more likely to feel fair to the player than one that requires a spreadsheet to understand.
Fairness is a feature
Players forgive rough edges. They don't forgive feeling cheated. Designing around genuine fairness — in pacing, in economy, in offline progress — pays for itself.
Honest communication matters
If we think a design direction won't work, we say so. If we're not sure, we say that too. Confidence you haven't earned just creates problems later.
Scope shapes quality
Narrower, well-defined work tends to produce better output than wide-open briefs. We'd rather do one thing well than gesture at ten things.
The player is always in the room
Every design decision we make, we try to hold it up against a player who is experiencing it for the first time. Their experience is what we're actually designing for.
Principles in Practice
What this looks like day-to-day
It's one thing to write down values, another to let them shape how the work actually goes. Here's where the philosophy shows up concretely.
We don't take on more than we can do well
When incoming work exceeds what we can handle carefully, we say so. A queue is better than a rush job. This sometimes means waiting a week or two — which we think is a reasonable trade.
Deliverables explain themselves
Anything we produce is documented clearly enough that you could hand it to someone who wasn't part of the conversation and they'd understand it. Opaque outputs aren't useful outputs.
We flag problems early
If something in a project scope looks like it'll cause issues down the line, we raise it at the start. Discoveries at the end of a project are far more disruptive than conversations at the beginning.
We test our own assumptions
Progression curves get run through scenarios before they're handed over. Suggestions in a balance pass have been checked against the game's existing numbers. We don't just reason about systems — we stress-test them.
Human-Centered Approach
Every project is a different project
Two idle games with the same genre description can need very different things. One might need a cleaner first loop; another might have a fine early game and a mid-game that loses momentum. We try to understand which problem a project actually has, not just apply the same template every time.
This means asking questions before suggesting solutions. It means reading the game before making notes on it. And it means being straightforward when the service that fits your situation isn't the most expensive one on the list.
We read before we write
Any engagement starts with understanding your game, not pitching our standard approach.
We ask the uncomfortable questions
If your core loop has a structural problem, it's better to hear it from us now than from players later.
Recommendations fit the project
We suggest what your game needs, not what would make the engagement larger.
Innovation Through Intention
Steady improvement, not trend-chasing
The idle game space shifts. New mechanics get popular, players develop new expectations, certain design patterns age out. We try to stay aware of this without treating novelty as a goal in itself. Borrowed mechanics only earn a place in a project when they actually serve it.
We study what holds up
Games that stay playable for years — or get replayed — are worth understanding. We look at what made their loops durable and try to apply those lessons, not just copy their surface.
We update our reference points
What worked in an idle game from 2018 may not be what players expect now. We try to keep our sense of the genre current without abandoning the principles that stay relevant regardless.
Integrity & Transparency
We say what we mean
Pricing is clear upfront. Scope is agreed before work begins. If something goes outside what was defined, we discuss it — we don't quietly add to the invoice. If the work reveals that a different approach would serve you better than the one originally planned, we tell you.
A few specific commitments:
You'll know what you're paying for before any work starts.
If we think something won't work, we'll say so with reasoning, not just reassurance.
Timelines are estimates given honestly, not promises made to win a project.
If we can't take on your project right now, we'd rather tell you plainly than overpromise.
Community & Collaboration
This works better as a conversation
Idle game design isn't something we do to your project. The developer knows things about their game that no outside eye can — the history of decisions, what was tried and discarded, what the game is really meant to feel like. That context is genuinely useful and we try to draw it out.
Good collaboration means we're straightforward when we disagree, open when we're uncertain, and always trying to leave the developer more capable of maintaining and extending what we've built together — not dependent on us for every follow-on question.
You know your game
We know progression systems. The best work comes from combining both kinds of knowledge, not from one side lecturing the other.
Pushback is welcome
If something we suggest doesn't fit your vision, say so. Design disagreements usually surface something useful about the project's priorities.
We hand over what we know
Deliverables include enough reasoning that you could adapt or extend them yourself without coming back to us for every decision.
Long-Term Thinking
Design that holds up after launch
A progression system that looks fine in a prototype can expose problems at scale — with many more players, longer play sessions, and content that extends beyond what was originally planned. We try to design with that future in mind.
Extensibility
Systems designed with room to grow are less likely to need a full rebuild when the game expands.
Predictability
Loops that behave consistently are easier to patch and easier to communicate to players when something does need to change.
Sustainability
A game that treats players fairly keeps them longer and earns better word-of-mouth over time than one optimised for short-term engagement metrics.
What This Means for You
How this actually translates
Philosophy is only useful if it changes how the work gets done. Here's what working with Slowburn looks like when these values are actually in effect.
You'll know where you stand at every point
No vague updates, no sudden scope expansions. Progress and any complications are communicated as they happen.
The deliverable will be genuinely usable
Not a rough draft with notes. Something clean, documented, and ready to hand to a developer or build from directly.
You won't be pushed toward more than you need
If your situation calls for a Balance Pass, we'll suggest a Balance Pass — not try to convince you that you need a full Progression Build on top of it.
The work reflects your game, not a template
What we produce is shaped by what your project actually needs, not recycled from a previous engagement with different numbers plugged in.
Sounds like a reasonable way to work?
If what we've described here feels like a comfortable fit for your project, we'd be glad to hear about it. No pressure, no commitment — just a conversation.
Get in Touch