Product case study
How Shiki went from a thesis to a TestFlight release: a study in the macro and micro decisions that kept a solo build unblocked, and the AI-augmented workflow that made it move like a team.
Shiki is a complete iOS social product — small accountability crews, daily non-negotiables, photo proofs, real-time focus sessions and chat, notifications, onboarding, profiles, widgets. Built by one person — concept to TestFlight in about three weeks — across a tight series of releases. The interesting part isn't the code. It's the decisions — what to build, what to refuse, and how to never let any one thing stall everything else.
By the numbers
“Measure twice, cut once.”
The carpenter's rule, applied to software — the specs are the measuring; the ship is the single, confident cut.
Macro decisions
A solo build dies by a thousand stalls. A handful of upfront decisions made sure no single problem could ever halt the whole thing.
The product thesis set hard nos — no public feed, no leaderboard, no gamification. A clear refusal is a product decision; it kept the surface small enough to actually finish.
Every screen talks to data through a single interface with a real implementation and a fake one. That one call meant features could be built, demoed, and tested in isolation — the UI never waited on the backend, and vice versa.
Every feature ran the same pipeline: brainstorm → a written spec → a plan → execution → recorded outcome. The pre-launch UX overhaul alone locked 51 decisions into 6 specs before a line of its code. Thinking is cheap and reversible; code is expensive — so the thrash happened on paper.
The database and its access rules carried their own test suites — 110 migrations, hundreds of checks — verifiable from the command line, fully independent of the Mac-only app build. The two halves advanced in parallel; neither was ever a bottleneck for the other.
A real first release first, then focused polish phases. "Done and shippable" consistently beat "perfect and pending."
Micro decisions
A complete fake backend let entire flows get built and tested with zero network — design and logic decisions made in seconds instead of deploy cycles.
Access rules — who can see and write what — were tested directly against the database, catching permission and privacy bugs long before they could reach a device.
"Which grouping, which spacing, which order" got answered with quick mockups and side-by-side options — picking a direction in minutes instead of building three of them.
A real-time transport that proved flaky wasn't debugged forever — it was swapped for the proven pattern already working elsewhere. A clever query that failed silently became two plain ones. Bias to reliable over impressive.
Literal, fast feedback — "up three pixels," "fifteen-pixel gap" — on the actual surface beat abstract debate every time. Ship, look, nudge, repeat.
The force multiplier
The velocity came from treating an AI coding agent like a senior pair: handed the map, the constraints, and a tight directive — then trusted to execute and verify. The structure around it is what made it reliable.
The mental model came from somewhere unexpected — autonomous robots. At CACMS, my research lab at UIUC, I learned dead reckoning: how a robot holds its course by tracking position from a known origin and heading, correcting against periodic fixes, instead of leaning on a constant external signal. Agentic coding is the same problem. Give the agent a known position (the compiled “State of the App”) and a heading (a tight spec), and let it dead-reckon through the work — course-correcting at checkpoints (tests, verification) rather than being steered keystroke by keystroke. That transfer — from autonomous navigation to autonomous building — was the starter the whole workflow grew from.
Standing on two open-source stacks: Superpowers by obra — the Claude Code skill methodology behind the brainstorm → spec → execute loop, parallel sub-agents, and the visual companion — and Obsidian Second Brain by eugeniughelbur — the vault structure that holds the specs, decisions, and the compiled “State of the App.”
What it demonstrates
A sharp sense of what to build — and a sharper one of what to refuse. Scope as a feature.
One or two load-bearing decisions (the seam, the spec pipeline) that paid off across every feature that followed.
Fast, but tested and reversible — shipping without accruing the debt that sinks the next sprint.
An AI workflow run as a true force-multiplier: a structured, verifiable pipeline that turns one person into a shipping team.
"The goal was never to build software impressively — it was to make the right calls quickly, kill the blockers, and ship. Then do it again tomorrow."