THE SCHEDULE 1 GAME DEV ROADMAP EXPLAINED

Schedule 1 is a weird sentence to type. A first person game about cooking and selling drugs in a fictional town, made by one Australian guy under the name TVGS, launched into Early Access in March 2025 and then proceeded to eat Steam alive. Peak concurrent players in the six figures. Top of the global sales charts. A subreddit that grew faster than the dev could reply to posts. All made by Tyler, working solo, with a roadmap pinned to the Steam page that told you exactly what he was going to do next.

I have been thinking about that roadmap a lot. Not the specific features on it, those are interesting but they are his game. The interesting part is how a single developer used a public roadmap as a marketing tool, a community management tool, and a wishlist conversion tool all at once, and how that document probably did as much work for the game as any trailer he ever cut. If you are a solo dev or a tiny team, this is the playbook I would copy from. Not because Schedule 1 is some untouchable success story, but because the boring infrastructure around the game is the part that is actually copyable.

What the roadmap actually is

Before getting into the lessons, it helps to know what we are talking about. Tyler has maintained a visible development roadmap for Schedule 1 since before it launched into Early Access. It lives on the Steam page, it lives on the Schedule 1 website, and updates to it show up on Discord and Reddit within hours of him changing anything. The format is simple. There is a list of updates with version numbers. Each update has a set of features grouped underneath it. Features are tagged with a status, something like "in progress," "testing," or "planned." Shipped features drop off the top of the list and get written up in patch notes.

He did not invent this format. Terraria did a version of it. Rimworld does a version of it. Factorio does a version of it, and their Friday Facts posts are basically a fourteen year roadmap written in real time. What Tyler did was take the format, strip it down to something one person can maintain, and commit to it before the game had any players at all. The roadmap existed when the wishlist count was under a thousand. It existed when nobody was watching. That is the part people miss.

Why visible roadmaps convert wishlists

Wishlists are the metric solo devs obsess over because they are the metric Steam uses to decide how visible your launch is. Every post on the indie game dev subreddit eventually becomes a wishlist post. Everybody wants to know the number. Nobody wants to talk about the part where the number is mostly a function of how many people land on your Steam page and decide you are not going to vanish in six weeks.

That is the real job of a roadmap. It is not telling players what is coming. Players do not read roadmaps the way you think they do. The job of a roadmap is to answer one unspoken question that every Steam browser is asking when they hover over the wishlist button. The question is "is this thing going to become a game or is it going to become a corpse." A roadmap that is visibly maintained, dated, specific, and slightly ambitious is the cheapest and most convincing answer you can give to that question.

I dug through some of the Schedule 1 roadmap history. Tyler did not promise the moon. Early roadmap entries were things like "add a new customer type," "improve the lab UI," "first pass at the legal system." Not "MMO expansion" or "full VR support." Boring, specific, achievable. A player landing on the page saw a guy who knew what he was going to do on Tuesday, not a guy pitching a vision. The vision was the game that was already there. The roadmap was the evidence that the game was alive.

If you want to see how this approach compounds over a full dev cycle, I wrote about the general shape of this in my post on game development roadmaps. The short version is that roadmaps are the single best unpaid marketing asset a solo dev has, and most of us treat them like internal Trello boards instead.

Small updates beat big updates

The other thing Tyler did, which I think is the most underrated part of the whole operation, is ship small updates constantly. Not monthly content drops. Not seasonal patches. Actual weekly or bi-weekly updates with patch notes, even when the patch notes were small.

This matters for two reasons, and they are both about perception rather than the actual content of the patches.

The first reason is that Steam's algorithm rewards games that get updated. The little "Recently Updated" tag is free visibility. Players browsing the Early Access hub see that tag and click through. A game that updates every Friday shows up more often than a game that drops one massive patch every three months, even if the total volume of changes is identical.

The second reason is emotional. When a player sees that a game they bought two months ago is still getting patched, they feel good about the purchase. They post about it on Reddit. They tell their friends. The update itself might be "fixed a soft lock in the sewer level and rebalanced the price of meth," but the signal it sends is "this guy has not abandoned the game, my money was well spent, I should tell people." Word of mouth is the only marketing channel that actually scales for solo devs, and consistent small updates are the fuel it runs on.

Compare this to the solo dev I see on Twitter every few months who posts "massive update coming in Q3, cannot wait to show you what we have been working on." By the time Q3 arrives, half the people who were excited have forgotten the game exists. The other half are suspicious because six months of silence usually means the update is going to underdeliver. One big update is almost always worse than eight small ones that add up to the same thing.

The community loop

The other thing a visible roadmap does, which took me embarrassingly long to figure out, is create a structure for community feedback that does not eat your entire life.

Without a roadmap, every feedback thread becomes a demand. "Why have you not added crafting." "When is multiplayer coming." "The UI is bad, fix it." You, the solo dev, either spend six hours a day trying to reply to everyone or you go silent and get called ungrateful. Neither is sustainable. Both make you want to quit.

With a roadmap, feedback threads have a reference point. "Crafting is on the roadmap under version 0.4, here is the ETA range, here is why it is not version 0.3." The conversation changes from "please do this thing" to "I see you are planning to do this thing, here is what I hope it looks like when you get to it." The second conversation is infinitely more productive and takes roughly a tenth of the emotional energy.

Tyler does this well. When someone posts a feature request that is already on the roadmap, the community itself will often point that out before he does. When something is not on the roadmap, he either adds it, explains why he is not adding it, or parks it in an "under consideration" bucket that exists specifically so people feel heard without him committing to anything. That bucket is a trick I stole for my own projects and it is probably the single most useful structural thing a solo dev can add to their community management.

The things Schedule 1 did not do

It is easy to make a success story sound like a formula. It is not a formula. Tyler also made a game that people wanted to play, with a premise that was inherently viral, in a genre that streamers loved. If Schedule 1 had been a puzzle game about sorting office supplies, the roadmap would not have saved it. The roadmap amplified something that already worked. It did not conjure it out of nothing.

There is also a version of this story that does not get told, which is the version where a solo dev does everything Tyler did and the game still flops. That version happens more often than the success version. Most Early Access games with public roadmaps still fail. The roadmap is necessary but not sufficient, and I do not want to pretend otherwise. If you want the full picture of what actually goes into shipping a small game, I wrote about that in my guide on how to make an indie game and in my longer piece on solo dev lessons. Both are more honest than this post about the parts that break you.

What is fair to say is that Tyler did not leave any obvious free points on the table. He did the marketing hygiene. He did the community management. He showed up consistently for months before the game blew up. When the game did blow up, there was a structure in place to catch the attention and turn it into sustained engagement. The breakout moment found a functioning business waiting for it rather than a burnt out dev who had no idea what to do with twenty thousand concurrent players.

Stuff I am actually stealing

Here is what I personally pulled out of studying the Schedule 1 roadmap and am applying to my own projects.

The first is publishing the roadmap before anyone cares. This feels stupid when your wishlist count is three hundred and two of those wishlists are your parents. It is not stupid. The roadmap is the thing that makes the fourth hundredth wishlist possible. Publish it early, commit to maintaining it, and accept that most of the early maintenance will feel like shouting into a void. The void starts listening eventually.

The second is grouping updates by version number rather than by feature theme. A theme feels like a wishlist. "The combat update." "The social update." A version number feels like a plan. 0.3.1. 0.3.2. 0.4. This sounds like a tiny distinction. It is not. Version numbers create a rhythm. Themes create expectations you have to live up to.

The third is ruthless status honesty. When a feature is delayed, say it is delayed. When a feature is cut, say it is cut. When a feature is behind schedule because you had the flu for two weeks, say that too. Every solo dev I know instinctively wants to hide the bad news until the good news is ready to balance it out. This never works. The community always finds out. Honesty in the moment costs you nothing. Caught delays cost you trust, which you cannot buy back.

The fourth is treating the roadmap as a public commitment rather than a private wishlist. This is the hardest part psychologically. Once you put something on the roadmap, it becomes a promise. Breaking promises feels bad. The temptation is to keep the roadmap vague so you never have to break one. Resist this. A vague roadmap is useless. A specific roadmap that occasionally slips is worth ten vague ones that never slip because they never said anything.

What it looks like when it works

The final data point I will leave you with is that Schedule 1 is still getting updates as I type this, more than a year after Early Access launched. Tyler is still posting patch notes. The roadmap is still alive. Players are still wishlisting the 1.0 release that has not happened yet. The subreddit is still growing. None of that was inevitable on launch day. All of it was earned, update by update, patch note by patch note, by a guy who decided early that the infrastructure around the game mattered as much as the game itself.

That is the lesson. Not the specific cadence, not the specific format, not the specific tool he uses to host the roadmap. The lesson is that for a solo dev, the roadmap is not a nice to have. It is the single most useful document you can maintain. It is the thing that tells everyone who lands on your Steam page that you are real, that you are working, and that buying your game now will not feel like throwing money into a hole.

Write the roadmap. Publish it. Keep it updated. Do it before you think you need to. Do it when nobody is watching. Keep doing it until somebody is.