Making a game is different from making business software. The requirements are not a list of features but an experience that has to feel right, and nobody knows whether it does until they play it. That uncertainty shapes the whole pipeline. This article walks through the stages we follow for 2D and 3D games on mobile and web, and the places where small teams usually lose time or money.
Stage 1: Concept
The concept stage answers a few plain questions. Who is the player? What do they do from moment to moment? Why would they come back tomorrow? Capture the answer in a one-page document with the core loop, the target platform, the monetisation approach and a few reference games. Keep it short enough that everyone can recite it. A concept that cannot be described in a paragraph is rarely ready for production.
Stage 2: Prototype
The prototype exists to answer one question: is the core loop fun? It should be built with placeholder art and minimal polish, in days or a couple of weeks. Playtest it with people outside the team and watch where they get bored or confused. Most game ideas that fail do so here, cheaply, which is the point. Do not move on until the loop is demonstrably engaging.
- Use primitive shapes and free assets.
- Hard-code values; do not build tools yet.
- Test the controls on real devices, not only in the editor.
Stage 3: Vertical slice
A vertical slice is a short section of the game at final quality: finished art style, audio, UI, and the real gameplay systems. It proves that the team can reach the target quality and gives you a basis for estimating the rest honestly. Investors and publishers also respond to it far better than to a deck.
Stage 4: Production
Production is the long middle where content, levels, characters and systems are built. Success depends on pipeline discipline: a consistent naming and folder convention, source control that handles large binary files, automated builds and an asset import process that does not require heroics. Break the work into milestones that each produce a playable build.
- Systems: progression, economy, save data, inventory.
- Content: levels, enemies, items, localisation.
- Tools: level editors and configuration so designers can iterate without engineers.
- Performance: frame rate, memory and load times tested on low-end devices throughout, not at the end.
Stage 5: Backend and services
Most modern games need server-side components: player accounts, cloud saves, leaderboards, in-app purchase validation, analytics and remote configuration. Design these early, keep them separate from the game client, and never trust the client for anything that has monetary or competitive value. Cheating and purchase fraud are predictable problems that are far easier to prevent than to fix.
Stage 6: Testing and quality
Games have a large test surface: devices, screen sizes, operating system versions, network conditions and the unpredictable behaviour of players. Combine automated tests for game logic and economy calculations with structured playtests and a device matrix. Add crash reporting before launch so you learn about problems from data rather than store reviews.
Stage 7: Soft launch
Release to a limited region or audience first. Watch retention on day one, day seven and day thirty, tutorial completion, session length and the points where players drop out. Fix the onboarding and balance before spending on user acquisition. A soft launch is where many commercial decisions are made, so give it the time it needs.
Stage 8: Launch
Prepare store listings, screenshots, trailers and age ratings well in advance, and allow for review times. Have monitoring and a rollback plan ready. Plan the first updates before launch, because players who like the game will expect a response to their feedback within days.
Stage 9: Live operations
For many games, launch is the beginning. Live operations covers events, content updates, balance changes, bug fixes, community support and monetisation tuning. Build with this in mind: remote configuration for tunable values, content versioning, staged rollouts and analytics events that answer real questions. The ability to change the game without a store release is a major advantage.
Where small teams lose time
- Building tools too early: before the loop is proven.
- Art before gameplay: polishing something that may be cut.
- Ignoring performance: discovering the game is too heavy for target devices at the end.
- No analytics: guessing why players leave.
- Scope growth: adding systems because they are interesting rather than necessary.
Team roles and how they interact
Even small game teams need coverage across several disciplines. Designers define the experience, rules and economy. Programmers build systems, tools and the client. Artists and animators create the visual identity and assets. Audio shapes feel. A producer, even a part-time one, keeps scope and schedule honest. On very small teams one person holds several roles, which is workable provided the work is still planned as if the disciplines were distinct.
Friction usually appears at handoffs: art that arrives in a format the engine cannot use, designs that assume systems that do not exist, or tuning values buried in code. Solve these with shared conventions, an asset pipeline with validation and data-driven configuration that designers can edit without a code change.
Technical choices that echo for years
- Engine: choose for the target platforms, team skills and licensing terms, not for novelty.
- Data-driven design: keep balance, levels and text in data files with schemas and validation.
- Save data: version the save format from the first build so updates never corrupt progress.
- Build size: mobile stores and users punish large downloads; plan asset compression and on-demand content.
- Localisation: externalise strings early, even if you ship in one language.
Analytics and monetisation design
Decide what questions analytics must answer before adding events: where players quit, how long levels take, what they buy and what they ignore. Keep the event set small, named consistently and documented. When monetising, be honest with players about what they are buying, protect minors where relevant and validate purchases on the server. A fair economy keeps players longer than an aggressive one, and good analytics lets you measure that rather than argue about it.
Working with us
Our game development service covers prototyping, production support, backend services and release pipelines for mobile and web, using engines such as Unity. If you have a concept, we can help you build a prototype that tests it quickly, and plan the stages that follow with honest estimates at each gate.