DevLog 001 — Why I started TriTail Studio
For the past few months I’ve been building Fog Sudoku — a classic Sudoku engine wrapped in a fog-of-war logic mystery and a small collection game. It’s nearly ready for Google Play. But this week I did something that, on paper, has nothing to do with the game: I bought a domain and started a studio.
The reasoning is simple. If I treat every project as “a website for this one app,” then every launch starts from zero — new landing page, new analytics, new place to write about it, new everything. Two years from now I’d have a handful of apps and nothing connecting them.
So instead of building a website for Fog Sudoku, I’m building the platform that Fog Sudoku happens to be the first product on. Same site, same blog, same release process for whatever comes next — a puzzle game, a small utility, a Steam port.
Today’s work was deliberately unglamorous: an Astro static site, a Markdown blog and DevLog, automatic deploys, sitemap and analytics — the boring infrastructure that lets me never think about “the website” again and just write.
What I want to avoid is the trap of spending a month making the site beautiful before the first product even ships. So the homepage is one screen: the studio name, the current project, a demo link, and a short About. That’s it. No login, no news feed, no team page.
The real goal isn’t the site at all — it’s a repeatable release routine. Idea → MVP → beta → feedback → launch → product page → one blog post → share. If the second and third products can reuse that, the studio compounds instead of resetting each time.
Next up: finish the Fog Sudoku launch, then write the first real article — probably Generating Sudoku puzzles with a unique solution, which turned out to be far more interesting than I expected.