--- title: Method description: How I build products, as a loop from listening to running and back, with AI agents at four of its seven stations. url: https://secretocho.design/method/ type: WebPage --- # Method > How I build products, as a loop from listening to running and back, with AI agents at four of its seven stations. I build products in a loop. Listen, decide, explore, build, prove, run, and listen again. AI writes most of the code; the calls are mine. [cd ~](https://secretocho.design/) signals in X · Reddit · Product Hunt · Mobbin · users · the team 1. [**listen**](#listen) · agents: research scouts 2. [**decide**](#decide) · me 3. [**explore**](#explore) · agents: Claude Design 4. [**build**](#build) · agents: builders 5. [**prove**](#prove) · agents: reviewers, audits 6. [**run**](#run) · me 7. [**listen again**](#again) · me The diagram, step by step: 1. Listen: signals come in from communities, launch platforms, pattern libraries, users and the team. Agents scout the research. 2. Decide: what to build, and in what order. That stays with me, in my own notes and sheets. 3. Explore: many directions in Claude Design, then one. 4. Build: agents write the code, one fresh session per task, many at once. 5. Prove: reviewer agents, audits, tests and gates, then my eye test. 6. Run: my machines, CI, hosting, and the maintenance after a release. 7. Listen again: what users and the team report goes back into the loop. *agents work at four stations; the call is mine at all seven.* My own products are built in the evenings and at weekends. There are no office hours for something I would do as a hobby anyway, so the loop rarely stops; it changes station. Most of the craft isn’t in any tool. It is eight years of product design: knowing which signal matters, which variant holds up, which state nobody has drawn yet. The agents work inside that judgement, never instead of it. ## Listen · agents: research scouts - **in**: Communities, launch platforms, pattern libraries, reviews, public data - **practice**: Read widely and regularly; keep what keeps coming back - **out**: Research files, one per question - **tools**: X and its communities, Reddit, Product Hunt, Mobbin, UI libraries, App Store reviews Before a product has a plan, it has a lot of reading. I follow X and its communities, Reddit communities and Product Hunt regularly, and open Mobbin and other UI libraries whenever a screen is in question. App Store reviews of the competition say what their users miss, often in so many words. For Novi Kvadrat that became 73 research files on 24 topics, from Zillow, Rightmove and Idealista to the Serbian portals, and 25 homepages captured at desktop and phone width before the new one was drawn. Agent scouts then surveyed Serbia’s public data: 403 candidate sources, 317 of them verified live. For ProbaBaby, a study of postpartum apps read their App Store reviews and what parents wrote on Reddit and Mumsnet: 16 files on about 20 apps. **73** · research files on 24 topics, for Novi Kvadrat · and 25 homepages captured at desktop and phone width | source | what I take from it | where it showed | | --- | --- | --- | | X and its communities | what people build, ship and complain about this week | — | | Reddit communities | what users say when no company is listening | ProbaBaby: parents on r/beyondthebump | | Product Hunt and other launch platforms | how a new product explains itself in one line | ProbaBaby’s own launch kit | | Mobbin and UI libraries | how the best apps solve the same screen | — | | App Store reviews | what a competitor’s users miss, in their words | ProbaBaby: about 20 postpartum apps | | Industry leaders | how the best in the field approach the problem | Novi Kvadrat: Zillow, Rightmove, Idealista, the Serbian portals | | Public data | what can be built on, and how fresh it is | Novi Kvadrat: 317 live Serbian sources | | Users and the team | what breaks, and what is missing | Listen again, below | ## Decide · me - **in**: Research, feedback, ideas - **practice**: Rank, cut, sequence; decide once and write it down - **out**: A feature list with priorities, then a master plan - **tools**: Spreadsheets, Obsidian, my own notes Deciding stays with me. Feature lists, priorities and ideas live in spreadsheets, in Obsidian and in my own notes, outside the agents and outside any one project. Several things are always in flight; the lists are how I know which one matters this week. A decision is made once and written down, so nobody, human or agent, reopens it by accident. On Sultana Express, a discovery pass took five legacy sources apart, 228 features in all, and each one got a verdict: keep or drop. The 3D work on Novi Kvadrat started with 45 decisions waiting for me, and I ruled on all of them in one pass. Sometimes the decision is to stop adding: in September, ProbaBaby switched from new features to polishing the ones it has. Inside one project, many tasks run at once. A plan that knows which phases depend on which lets the independent ones run side by side, each in its own worktree and agent session. This is one Saturday on Sultana Express. **14** · sub-phases built on one Saturday, in four parallel phases · Sultana Express, 8 August 2026 1. **P95 · product detail** 03:31–05:12 2. **P62 · trade documents** 02:56–23:30 · backend 3. **P119 · operator console** 09:48–23:31 4. **P96 · inquiry cart** 09:55–23:58 5. **plan board** 12 entries closed The diagram, step by step: 1. Before dawn, the product-detail phase closes: its last gate merges at 05:12. 2. The backend builds trade documents in five sub-phases, from 02:56 to 23:30. One review pass finds a critical issue; it is fixed before the merge. 3. From 09:48 the operator console builds in a second web worktree: four sub-phases, each its own pull request. 4. Beside it, the inquiry cart builds in a third: four more sub-phases. 5. The plan board closes each one as it lands: twelve entries that day. *four phases side by side, from before dawn to midnight.* ## Explore · agents: Claude Design - **in**: A decided problem - **practice**: Many directions side by side; then one, made to hold in every state - **out**: A chosen direction, then a design-system card - **tools**: Claude Design, Figma, Icon Composer, SF Symbols I don’t design one screen; I design four, or six, and put them next to each other. Claude Design is where that happens now: ProbaBaby alone has 364 artboards across 19 canvases, from widgets and Live Activities to the App Store pages, and Novi Kvadrat’s design-system canvas holds about 150 boards. Most of the choosing happens in my head while I look. Which direction holds up with real data, in dark mode, on a small phone, in the longest of five languages? The ones that don’t, go. Engineering gets the same treatment: before the 3D buildings, a throwaway spike measured five rendering approaches over 81 runs, and the numbers chose. **364** · artboards in 19 Claude Design canvases, for ProbaBaby · Novi Kvadrat’s system canvas: about 150 boards 1. **Novi Kvadrat · homepage** · 4 → 1 - A (chosen) - B - C - D 2. **Novi Kvadrat · admin** · 4 → 1 - A · Command deck (chosen) - B - C - D 3. **Novi Kvadrat · listing hero** · 4 → 1 - A - B - C · Immersive (chosen) - D 4. **Sultana Express · consoles** · 4 → 1, after 8 rounds - Ledger - Gallery - Atelier - Console (chosen) 5. **ProbaBaby · website** · 6 → 1 - A - B - C · Precision (chosen) - D - E - F The diagram, step by step: 1. Novi Kvadrat’s homepage: four directions, one kept. 2. Its admin console: four directions; “Command deck” won. 3. The listing hero: four again; “Immersive” won. 4. Sultana Express’s consoles: Ledger, Gallery, Atelier and Console. Console was locked after eight rounds. 5. ProbaBaby’s website: six boards, and “Precision” won. *many directions, side by side, then one.* ## Build · agents: builders - **in**: A chosen direction and a plan - **practice**: Ten stages, from prompt to test; one fresh agent session per task - **out**: Code, its tests, and a progress log - **tools**: Claude Code: Opus builds, Fable plans and reviews Building is where AI does most of the typing. Every project runs the same ten stages, and the first six are reading and thinking, not code. A plan is the handoff, not the chat. A session forgets; a plan file with an append-only progress log doesn’t, and neither do the memory notes that keep each lesson with the reason behind it. ProbaBaby has 124 plans and 176 memory notes. On Sultana Express a script starts one fresh, headless Claude Code session per sub-phase, 650 of them in the master plan, and I do every merge. Novi Kvadrat builds in waves of up to ten agents; one run had 17 builders and 17 reviewers. **650** · sub-phases in Sultana’s master plan, one fresh agent session each · 145 phases in 18 stages 1. **prompt** · goal, constraints, taste 2. **research** · many research files · **leaders** · industry-leading products · **analysis** · how they approach it 3. **compare** · against this project · **evaluate** · keep, adapt, drop 4. **master plan** · one plan, whole product · **phase plan** · multi-phase, with kick-off prompts 5. **build** · agents write the code 6. **test** · code tests and an eye test The diagram, step by step: 1. A prompt: the goal, the constraints, and the taste it has to meet. 2. Research: many files, the industry’s leaders, and how they approach it. 3. Compare it with this project, then keep, adapt or drop each idea. 4. A master plan for the whole product, then phase plans with their kick-off prompts. 5. Agents write the code: Opus builds, Fable plans and reviews. 6. Code tests, then my eye test. *research before code, plans before agents, an eye test before anything ships.* | who | does | | --- | --- | | Me | Design taste, UX and product-building experience lead every step. | | Claude Code | The toolchain, on several Max plans in parallel. | | Opus | Builds: writes the code. | | Fable | Plans and reviews. | ## Prove · agents: reviewers, audits - **in**: Code that claims to be done - **practice**: Read the logs, reproduce first, audit, test, then look - **out**: Green gates, and a fix for every finding - **tools**: Vitest, XCTest, Playwright, axe, pgTAP, a local Postgres in OrbStack “Done” is a claim, not a check, whoever writes it. Every layer below exists to catch what the one before it missed. Debugging starts from evidence: never assume, read the logs, and reproduce the bug on the unfixed code before fixing it. Audits are run by agents and read by me: ProbaBaby’s Planning audit put 42 agents on one module and merged 699 raw findings into 90. Tests are the floor: 57,423 pass on Novi Kvadrat, and Sultana’s web apps hold 4,430 screenshot baselines at zero-pixel tolerance. A new gate only counts once a planted defect has turned it red. Then I look. Eyeballed baselines are a gate of their own on Novi Kvadrat, and an eyeball pass has caught a defect no check measured. What gets past all of it reaches the users, and they tell me. **57,423** · tests passing on Novi Kvadrat · as of 11 October 2026 1. **edit hook** · secrets and lint, on every edit 2. **reviewer agents** · 94 issues, then 44 more from fresh eyes 3. **pre-commit** · 15 checks, from translations to migrations 4. **CI wall** · 45 checks; screenshots at zero-pixel tolerance · proven by a planted defect 5. **eye test** · a defect no check measured 6. **users** · shake to report what gets past everything goes back to listen The diagram, step by step: 1. An edit hook stops secrets and lint errors before they reach a commit. 2. Reviewer agents read the change: on one Novi Kvadrat studio, ten found 94 issues and eight fresh ones found 44 more. 3. A pre-commit hook runs 15 checks on ProbaBaby, from translations to migrations. 4. The CI wall runs 45 checks on Sultana’s backend; a gate counts only once a planted defect has turned it red. 5. My eye test: on Novi Kvadrat, an eyeball pass caught a defect no check measured. 6. What gets past everything reaches users, who report it, and the loop starts again. *each layer catches what the one before it missed.* ## Run · me - **in**: Code that passed - **practice**: Run it cheaply, release it slowly, watch it closely - **out**: A release, a runbook, a root cause for every incident - **tools**: Docker, OrbStack, GitHub Actions, Hetzner, Vercel, Cloudflare, Supabase, Google Cloud Everything starts on my Mac. OrbStack runs Docker and a local Kubernetes for Sultana, with its whole data plane, and database migrations for Novi Kvadrat and ProbaBaby are proven twice on a local Postgres 17 before they touch production. CI is where the bill shows. Sultana’s CI used 41,350 hosted GitHub Actions minutes in July, about $230. I moved the runners onto an OrbStack VM on my Mac, which ran out of memory and went from 12 job slots down to 4, then bought a refurbished 16-core Threadripper with 128 GB of ECC memory from Hetzner’s server auction: €115.70 a month, six runner slots, and the same architecture as production. Splitting the screenshot wall into shards cut it from 68 minutes to under 17. Production depends on the product. Novi Kvadrat runs on Vercel behind Cloudflare, with Supabase and its own map tiles on Cloudflare R2. ProbaBaby runs on Supabase and Firebase, with Google Cloud’s APIs for Sign in with Google and its AI models. Elsewhere Google Cloud means API services: the Analytics API, which I query through an MCP server, and Sign in with Google, which is coming. Sultana is headed for one k3s cluster at Hetzner, deployed by Argo CD. Shipping is where maintenance starts. ProbaBaby releases in phases, with a 48-hour watch and a rollback ladder: switch off the update prompt, then a kill switch, then a forced update with a hotfix, then maintenance mode. Novi Kvadrat runs 11 scheduled jobs on Vercel and about 15 in its database, and every incident gets a written root cause. **€115.70** · a month for a 16-core, 128 GB CI server · against about $230 of hosted minutes in July 1. **my Mac** · OrbStack: Docker, k3d and the data plane 2. *push* · **GitHub Actions** · pull requests run the quick checks; main runs the full wall 3. *jobs* · **self-hosted runners** · a 16-core Threadripper, 128 GB, six slots 4. *images* · **registry** · images tagged by commit 5. *deploy* · **k3s at Hetzner** · deployed by Argo CD: planned The diagram, step by step: 1. On my Mac, OrbStack runs Docker, a local k3s and the data plane. 2. A push starts GitHub Actions: pull requests run the quick checks, main runs the full wall. 3. The jobs run on my own runners: a refurbished 16-core server with 128 GB, six slots. 4. Images go to the registry, tagged by commit. 5. Production will be one k3s cluster at Hetzner, deployed by Argo CD. Not live yet. *the runners moved; the jobs didn’t.* - **hosted minutes, July**: 41,350 · ~$230 - **VM job slots**: 12 → 4 - **the auction server**: €115.70 a month - **screenshot wall**: 68m46s → 16m45s ## Listen again · me - **in**: Reports, requests, votes, crashes, reviews - **practice**: Triage by severity; a pattern becomes an audit - **out**: A fix, a plan, a What’s New - **tools**: The in-app Feedback Board, Slack, Google Chat, Crashlytics The loop closes where it started, with listening; only now the voices are the product’s own users and the team. ProbaBaby has a Feedback Board inside the app: Known Issues, each with its status from investigating to released; Feature Requests that users vote on; and What’s New. Shaking the phone opens a bug report. I triage it all in a separate admin app, and when several reports point at one module, they become an audit: the Planning audit started that way. Novi Kvadrat’s feedback comes through Slack and Google Chat, with channels for ideas, improvements, bugs and feature requests, from the team, agencies and clients. Each report arrives with a severity; a Very High one was fixed the same day. Every report becomes a written fault and its test flow, so the fix can be proven and the lesson stays. **same day** · from a Very High report to its fix, on Novi Kvadrat 1. **shake or form** · a bug, an idea, a request 2. *lands on* · **the board** · a known issue or a feature request, with votes 3. *read* · **triage** · in the admin app: approve, merge or reject 4. **a fix** · by severity · **an audit** · when reports share a module 5. **release** · phased; What’s New in 32 languages the issue reads “released”, and the reporter sees it The diagram, step by step: 1. A user shakes the phone, or fills in the form: a bug, an idea, a request. 2. It lands on the board as a known issue or a feature request; other users vote. 3. I triage it in the admin app: approve, merge or reject. 4. A fix goes in by severity; when reports share a module, they start an audit. 5. The release goes out in phases, with What’s New in 32 languages, and the issue reads “released”. *a report becomes a fix, and the reporter sees it land.* ## What stays in my head None of this is a tool you can buy. The loop is the method; the judgement inside it is years of product design: which signal is real, which variant holds up, which state nobody has drawn yet, and when to stop. ## Hiring a design engineer? I’m open to senior design engineer roles: remote from Belgrade, or relocation with visa sponsorship. Write to me, or read the CV first. Client work stays selective, one project at a time. [sc@secretocho.design](mailto:sc@secretocho.design) [read the CV](https://secretocho.design/cv/) · [LinkedIn](https://www.linkedin.com/in/secretocho/)