Why Small Games Take WAY Longer Than You Think

Tim Ruswick argues that the industry’s favorite beginner advice—make small games—hides a lot of the real work. His core point is that “small” usually means fewer features, not less effort, because design, iteration, UI, bug fixing, and content curation still have to happen.

That matters for teams trying to scope a first release or a solo project: a compact game can still demand the same production disciplines as a larger one, especially if each system needs meaningful depth. Ruswick also frames the Steam refund window and audience-building as practical pressures that push developers toward shipping something coherent rather than endlessly polishing a tiny idea.

He suggests a more useful approach is to start with a deadline, prototype multiple ideas, and then cut scope aggressively—sometimes by half—before production locks in. The broader takeaway is that “small” is only helpful if it’s paired with a clear plan for depth, marketability, and finishability, which is why many modest games end up taking far longer than expected.