
Here is the trap. Your engine has a dropdown that says "export to Switch, PlayStation, Xbox, Steam, itch, mobile," and it feels like each of those is a checkbox. Tick it, ship there, collect money in more places. Free reach.
It is not a checkbox. Every platform you ship on is a thing you now have to keep alive for as long as the game exists. Certification requirements change. An OS update breaks your controller mapping. A storefront redesigns its backend and your metadata needs redoing. A player on the platform with your smallest audience files the bug that eats your Tuesday.
So the real question is not "can I build for that platform." Your engine already answered that. The question is whether you want to be responsible for it in eighteen months, when the launch buzz is gone and you are the only person left who remembers how the build pipeline works.
Why "it already builds for that" is a lie you tell yourself
An engine export gives you a binary that runs. Shipping on a platform is everything around that binary, and the binary is the small part.
You need store assets sized to that platform's exact spec. You need an age rating that platform accepts. You need to pass their certification, which for consoles means a checklist about how your game behaves when the controller disconnects, when the user signs out mid-save, when the console suspends. You need to handle their achievement system, their cloud saves, their friends list, their particular way of doing everything you already did once.
Then you need to do it again for the next platform, because none of them agree on any of it.
And then the game is out, and the platform keeps existing. That is the cost people forget. A port is a weekend. A platform is a pet.
The permanent cost nobody budgets for
Think in terms of the tail, not the launch. After release, each platform generates a slow drip of obligations that never fully stops.
Patches have to be built, tested, and certified separately per platform, and consoles can take days to approve a build you consider trivial. A one-line fix becomes five submissions. If your game is live-service or gets regular content, multiply that by every update forever.
Support tickets arrive per platform and they are not interchangeable. "The game crashes" means something different on each one, and the person reporting it cannot tell you which layer broke. You will spend real hours reproducing a bug that exists only on the hardware you own the least of.
There is also the storefront housekeeping. Sales events you have to opt into, price parity rules, regional pricing tables, tax forms per territory. The store sends an email that says "action required" and it is always required by Friday.
One platform is a job. Four platforms is four jobs held by one person who also wanted to make games.
How to decide which platforms are actually worth it
Start with where your players already are, not where the money theoretically is. A cozy sim and a twitch shooter do not live on the same hardware, and shipping to the wrong crowd is worse than not shipping — it is effort spent earning refunds.
Run each candidate platform through three honest questions.
Does my audience play this kind of game there? Not "does the platform have players." All of them have players. Does your genre sell there. A slow strategy game on a handheld, a mouse-heavy management game on a console with no mouse — these are fights you are choosing.
Can I test on the real hardware? If you cannot reproduce a bug on the actual device, you cannot fix it, you can only guess. Owning the hardware is not optional for platforms you take seriously. If you are not willing to buy the console, you are not willing to support the console.
Does the revenue survive the tail? A platform that earns you a small launch bump and then generates support work for years is a net loss dressed as a plus. It only counts if what it brings in outweighs what it will keep costing.
When the honest answer to any of those is no, that platform is a later problem, not a launch platform.
Launch narrow, expand on purpose
The cleanest path for most solo devs and small teams is one platform at launch, done properly, and everything else as a deliberate second phase.
PC through a single store is usually that first platform. The tooling is the most forgiving, you can patch without waiting on certification, and you learn what actually breaks before you have four audiences watching it break. Getting your storefront presence right there also teaches you the parts you will reuse — screenshots, trailer, the description that has to sell in one screen.
Once the game is stable and you know its real bugs, expanding to a second platform is a project you can scope. You are porting a finished, understood thing, not shipping a moving target to five doors at once. And you get to choose the second platform based on how the first one actually went, which is far better information than a pre-launch guess.
Consoles reward this patience. Their certification is where a rushed game goes to be humbled, and you would rather meet that process with a codebase you trust.
The console question, specifically
Consoles are the platforms people most want and most underestimate. Getting on them usually means applying to a developer program, being approved, and agreeing to their requirements, which include that certification checklist and often things like a minimum standard for how the game handles their system features.
The upside is a captive storefront and an audience that buys games there and nowhere else. The cost is the slowest patch cycle you will deal with and the strictest rules. A bug that would be a hotfix on PC is a submission-and-wait on console.
If you go for consoles, go for one first. Do not sign up to launch on all of them simultaneously to hit a "day one everywhere" beat. That beat is a marketing fantasy that turns into three certification failures in the same week.
Fold platforms into pricing and engine choices early
The platforms you plan to support ripple backward into decisions you make long before launch. Your engine choice partly determines how much pain each export is — some engines have mature console pipelines, others need middleware or a co-development partner to get there at all. Decide your target platforms before you decide your engine, or at least in the same conversation.
Platforms also shape money. Each store takes its cut, and those cuts differ, which means the same sticker price nets you different amounts in different places. Work that into how you price the game rather than discovering it when the payout lands. Regional pricing multiplies this again, per platform, forever.
What to do first
List every platform you are tempted by, then cross out the ones where you cannot answer yes to all three questions — right audience, real hardware, revenue that survives the tail. Ship on what is left, one at a time, starting with the one that lets you patch fastest while you learn the game's actual failure modes.
The platform you skip costs you nothing. The platform you half-support costs you every week it stays live.
Common questions
Should I use a porting studio instead of doing it myself?
If a platform matters commercially but you do not have the expertise or the hardware to support it properly, a porting partner is often cheaper than the months you would burn learning. Just remember they hand the game back and the ongoing maintenance is still yours unless your deal says otherwise. Read that part of the contract.
Is mobile a good extra platform for a PC or console game?
Usually it is a separate game wearing your game's clothes. Controls, session length, monetisation expectations and store rules are all different enough that a straight port tends to land badly. Treat mobile as its own project with its own design, not as another export checkbox.
How many platforms can one person realistically maintain?
Fewer than you want to. The honest answer depends on how often your game updates — a finished single-player game that rarely patches carries more platforms than a live game does. If you ship content regularly, every platform multiplies that work, and one person maintaining more than two or three live platforms is usually one person who is quietly drowning.
Does releasing everywhere at once help discovery?
Simultaneous launches concentrate attention, which sounds good until each platform's problems arrive on the same day. For a small team, a staggered rollout gives you second and third launch moments to draw fresh attention, and it means each platform gets a version that already survived contact with real players.