Solo developer notes

Notes from the person who builds these games: how an ARG goes from idea to release in spare time, with the pitfalls and the launch checklist.

How a solo ARG developer survives: building immersive puzzle games with a team of one

Independent development notes

As an independent ARG developer my working mode looks nothing like a commercial game team. No producer, no designer, no outsourced art — from writing the story to shipping the code, one person does all of it. This page is about working efficiently in that mode, staying creative, and getting an immersive puzzle experience out of very limited resources.

Last updated: November 2, 2026

1. The solo-team model: what it gives you and what it costs

• The biggest advantage of a team of one is decision speed. In a commercial studio a single design call can travel designer → lead designer → producer and take days or weeks. In my workflow an idea becomes a testable prototype in an afternoon. That iteration speed matters especially for ARGs — puzzle design needs a lot of trial and error to tune the difficulty curve, and testing fast beats planning perfectly.
• The real cost is the absence of cross-checking. In a team, designers challenge engineers' assumptions and engineers push back on what is feasible; that friction raises the quality of the result. Working alone, every assumption and decision is generated inside one head, which makes blind spots easy to develop. I will not dress this up: there is no test team. Everything checked before release is checked by me, and I am precisely the person who walks in already knowing every answer. The only correction that actually works arrives after launch — players email me where they stalled, I adjust the clue, and the change goes into the public changelog.
• How I spend the time — On a two-to-three-month cycle my split is roughly: concept and script (first 2 weeks, ~20%), prototyping and puzzle validation (weeks 3–6, ~40%), visual and content production (weeks 7–9, ~25%), integration testing and fixes (final 2 weeks, ~15%). The ratios move with project complexity, but prototype validation always takes the largest share.

2. A quality strategy for limited resources

• A team of one cannot push every dimension — visuals, audio, content volume — to its limit. The trick is concentrating what you have on the parts that actually create immersion.
• Text first — Writing is the main output channel of a web ARG. Good prose immerses a player better than elaborate visuals. So I finish the whole script as plain text first, iterate on pacing and dialogue, and only start visual design and engineering once the story holds up on its own. This text-first order keeps me from spending time on scenes that later get cut.
• Targeted visual investment — Not every page needs to be beautiful. Core interaction surfaces (the game shell, the key simulated websites) get 80% of the visual effort; transitional and informational pages just need to be clear. That avoids spreading visual work evenly — a player's impression of a game is decided by three or four core scenes.
• Reuse and variation — Sharing technical components and design templates across games is where the time savings come from. I maintain an internal component library covering simulated-website base layouts, a search box, an email system and similar modules, so a new project starts from those instead of from nothing.

3. Long-term sustainability for a solo developer

• The hardest problem in independent development is not technical, it is sustainable — motivation, time, and money.
• Keeping motivation alive — Across a three-month cycle enthusiasm swings from excitement to burnout and back. What has worked: in the early concept phase I engineer frequent wins — every finished puzzle prototype gets acknowledged. In the later production and testing phase I shift attention onto the anticipation of finishing. Accepting that the swing happens is more useful than fighting it.
• Time management — As a developer with a full-time job, time is the binding constraint. My rule: at least one hour every day, non-negotiable, with 4–6 hour blocks at weekends. Slow but steady — consistent small steps protect long-term output far better than occasional all-nighters.
• Low cost, low waste — On the money side, keeping operating cost low is the whole game. Static hosting removes almost all server expense. Every game is completely free; the small amount of advertising on the pages exists to cover annual running costs and will stay at a minimum. The point of independent development is the work itself, not monetising it.

4. Advice for anyone thinking of doing this

• From a few years of making independent ARGs, some advice for developers considering it:
• I go into much more specific design and technical detail on the ARG development methodologypage. Email me if any of it interests you.

Start absurdly small. Do not open with a grand ARG of 20 simulated websites. My first game, "The University Hiking Disappearance", had 3 websites and 5 puzzles. Finishing one small, complete thing matters far more than starting a large one you will never ship.

Test the puzzles properly. As the designer you always know the answer, so you cannot judge real difficulty. I have never had the conditions for outside testing, and that is a genuine weakness of the games here — so if you have them, find people who have not read the story, and write down where they stall and for how long. The standard has to come from whoever meets the puzzle for the first time, not from whoever wrote it.

Build a small player community. ARGs suit collaborative solving naturally. Offer one simple channel — an email address or a discussion group — so players can share findings and report problems. Even ten active people giving feedback lifts the quality of a game noticeably.

Accept imperfect. A solo project will never reach a commercial team's polish. That is fine. What players care about is not whether the visuals are gorgeous but whether the experience is sincere. A finished thing with small flaws beats a project that is forever being polished.