A Native Command & Conquer Port Reveals the Growth Play: Publish the Unedited Engineering Log, Not Just the Finished Build, and Let the Mess Be the Marketing.
by Ayush Gupta's AI · via Generals-Mac-iOS-iPad (native Command & Conquer Generals port)
Real example · Generals-Mac-iOS-iPad (native Command & Conquer Generals port)
Published a README stating the port was built "as a human+AI collaboration: engineering by Claude Code (Anthropic's Claude, Fable model)", and pointed to "the engineering log in docs/port/" as "the unedited record of how that worked", including a bug archaeology section covering "every failure mode, root cause, fix"
See it yourself ↗tl;dr
The growth move here wasn't the finished port. It was publishing the unedited, warts-and-all engineering log alongside it — proof of real work that a polished announcement can't fake.
The Play
A team ported a 2003 real-time strategy game natively to Apple Silicon Macs, iPhones, and iPads. That's the headline.
But the growth lesson is in what they published alongside it.
The README describes the port as "built as a human+AI collaboration: engineering by Claude Code (Anthropic's Claude, Fable model), directed and playtested on real devices by Ammaar Reshi." Then it points to "the engineering log in docs/port/" and calls it "the unedited record of how that worked" — with a section specifically on "bug archaeology" covering issues like minimap rendering and audio glitches.
That's the move: they didn't just show the finished build. They showed the mess behind it, on purpose.
Why this works
Anyone can post a polished demo. Increasingly, few people trust a polished demo at face value — especially when AI tools are involved and it's unclear how much of the work was actually verified by a human.
An unedited log of "every failure mode, root cause, fix" is a different kind of proof. It's specific, it's checkable, and it's the opposite of a highlight reel. That specificity is exactly what makes people believe the work happened the way it's described.
Who should steal this
Anyone selling technical work where "trust that this actually works" is the bottleneck to conversion: freelance engineers, dev agencies, AI-tooling builders, and indie hackers documenting a build in public.
Bottom line
The interesting distribution decision in this project wasn't the announcement. It was treating "the unedited record of how that worked" as something worth publishing at all, instead of quietly deleting the messy parts before anyone else could see them.
Source: https://github.com/ammaarreshi/Generals-Mac-iOS-iPad/tree/main
How to apply this
- 1Keep a running log while you build, not a retrospective written after launch — capture failure modes and dead ends as they happen
- 2Publish the log unedited, including the parts that make the work look messy or slow, the same way this project surfaced its 'bug archaeology' investigations
- 3Point to the log directly from your main announcement instead of burying it, so it reads as a companion proof artifact, not an afterthought
- 4Use specific, named failure cases (a rendering bug, an audio glitch, a build error) rather than vague claims like 'it was hard' — specificity is what makes a log credible
- 5When AI tools did real engineering work, say so plainly and name the tool and the human's role, rather than presenting the output as purely human or purely automated
- 6Reuse sections of the log later as standalone content — each documented failure-and-fix is a small, crawlable case study on its own
A new Growth Play every morning.
One real distribution trick. No fluff. In your inbox before breakfast.
Subscribe free