# Timurtek · Full content corpus

> Fractional AI systems lead. This file contains every essay and newsletter issue as plain markdown, intended for LLM ingestion. See https://timurtek.com/llms.txt for the index.

Author: Timurtek Bizel
Site: https://timurtek.com
Last updated: 2026-09-12T02:21:00.452Z

---


# Writing (essays)


## Your agent chain is a multiplication problem

- URL: https://timurtek.com/blog/agent-chains-are-a-multiplication-problem
- Published: 2026-08-11
- Author: Timurtek
- Category: Founder Lessons
- Tags: Operator lessons, Hot takes

Five agent steps at ninety percent each is a coin flip. Nobody writes that number down, because the demo only ran once and it worked. Every failure in my own system so far has been a seam between two steps, not the model doing the work.

## The number nobody computes

Do the arithmetic before you read anything else.

Five steps, ninety percent success each. Multiply it out. Zero point nine to the fifth power is fifty nine percent. That is not "mostly works." That is a little better than a coin flip.

Tighten every step to ninety five percent and add one more, so six steps at ninety five. That lands at seventy three percent. Still a bet. Nobody would ship a payment flow that fails a quarter of the time, and yet six step agent chains ship at that rate every week and get called automations.

An observability vendor published numbers in the spring that keep resurfacing in the August agent coverage. It says agents fail somewhere between seventy and ninety five percent of the time in production depending on task complexity and how success gets measured, and that an estimated eighty eight percent of enterprise agents that work in a controlled demo fail once they hit real workflows. It cites research where a sixty percent single run success rate drops to twenty five percent when measured across eight consecutive runs. Its own worked example is a three step chain at seventy percent per step, which multiplies out to about thirty four percent end to end. That vendor sells observability tooling, so read the framing accordingly. The multiplication does not care who published it.

Here is why the number stays invisible. A chain gets demoed once. It works once. That single run becomes the reliability claim, and then it gets repeated in a standup, then in a deck, then on a landing page. Nobody reruns the demo fifty times, because rerunning it is boring and the first run already felt like proof.

## My chain broke, and it was never the model

I hit this in my own content system, which is the only reason I trust the framing.

My posts move through a pipeline. A drafter writes, a critic annotates, I approve, a publisher ships, a watcher marks what actually went out. Five steps. Ordinary stuff.

The watcher matched exactly one status value and skipped every other one. Posts that shipped down the second path never got marked as shipped. So my own system reported a pile of work stuck at the gate while eleven of those posts were already live and had been for a while. After the fix, the posted count went from seven to eighteen in a single pass.

Nothing was wrong with the model. Nothing was wrong with the drafter, the critic, or the publisher. Every step did the job it was given. The failure lived in the handoff between two of them, inside an assumption about what one step would hand the next.

That is the pattern I keep hitting. The seams break, not the intelligence. And a seam is not a model problem. It is a design problem, which means it was already decided before anybody wrote code.

## A checkpoint that can lie to you is not a checkpoint

Look at where the tool vendors are spending their fixes.

Claude Code shipped two releases in three days in early August. Read the two changelogs together and almost nothing in them is about making the agent smarter. Anthropic says it fixed isolated sessions and their subagents being able to run destructive commands against the main checkout. It says it fixed auto allow hooks that bypassed tool restrictions inside background tasks. It says it fixed a permission bypass where a crafted command could hide part of itself from the permission check, and a case where a command padded with tabs or invisible Unicode could hide part of itself from the approval dialog. Those are Anthropic's own changelog claims. I have not tested them.

Sit with that last one for a second.

The human was in the loop. The human was looking at the approval dialog. The dialog was showing a different command than the one about to run.

So the checkpoint existed, the person did their job, and it still failed. Which means "we have human approval" is not the answer people think it is. A gate whose display you cannot trust is decoration.

I made the full case a few weeks ago for the one gate in my own pipeline that I will not automate. This is the condition that gate depends on. Keeping a human at the door only buys you something when what the human sees is what is about to happen. Otherwise you bought a signature, not a check.

## Silent success is the expensive failure mode

The dangerous state is not the loud error.

A loud error is a gift. It stops the chain, it names itself, and somebody goes and looks. Cheap.

The expensive state is the step that reports green while dropping work. My watcher looked healthy the entire time it was stranding posts. Statuses moved, counts added up, nothing threw. A watcher that matches the wrong status is worse than no watcher at all, because with no watcher you know you are blind and you go check by hand.

So here is the rule I now apply to every step in a chain. Every step needs a state it is allowed to fail loudly in. A step with no way to report failure has no way to report success either. It only has a way to report that it ran.

Without that, you are measuring the dashboard instead of the system.

## Fewer steps between checks, not a better model

The instinct when a chain is unreliable is to go shopping. Better model, bigger context window, a framework with more orchestration in it.

I don't want a smarter agent sitting in the middle of a five step chain. I want fewer steps between the places where I can tell whether the work is still correct.

That is a design decision, and it gets made before implementation. Two questions do most of the work. Where can this chain be wrong without me knowing? And how expensive is being wrong at each point it could surface? Put the checks where a failure is still cheap to absorb, then shorten the distance between them until the compound number stops scaring you.

The infrastructure is arriving to support exactly that reading. Cloudflare closed its first Agents Week by grouping everything it shipped into compute, security, toolbox, and prototype to production. A persistent sandbox per agent. Versioned storage for what agents write. Scoped private networking into databases and APIs. An identity per agent instead of a shared service account. A browser with a live view and a human in the loop control. Those are Cloudflare's own claims about its own products.

Read the shape, not the product list. A vendor spending a whole week on filesystems, identity, and an interruptible browser is telling you that capability stopped being the constraint. From my perspective that is the clearest signal of the last month. The frontier moved from what the agent can do to whether you can see what it did and stop it in time.

## What I would want to know before adding another agent

Here is the part I do not have.

I don't know where the per step success rate actually sits in most real systems, and neither does almost anybody running one, because almost nobody measures it. The numbers above are somebody else's benchmarks on somebody else's tasks. Your chain is not their chain.

So I would say the recommendation comes with a prerequisite attached. Before you add the next agent, run the chain you already have enough times to get a real per step number. Twenty runs on live inputs beats any published benchmark for your purposes. Then multiply your own numbers, look at what comes out, and decide whether the next step earns its slot, or whether the honest move is to collapse two steps into one and put a check between what is left.

I write these builds up as they happen, including the ones where my own system lied to me, in The Production Layer at timurtek.com.

Ninety percent is a good number for a step and a bad number for a chain. Multiply before you add.

---

## My content OS, mapped end to end

- URL: https://timurtek.com/blog/my-content-os-mapped-end-to-end
- Published: 2026-08-07
- Author: Timurtek
- Category: Founder Lessons
- Tags: Building with AI

Every week my content system outlines the blog, drafts the posts, critiques them, and queues the publish, and I touch it once, on Saturday morning. Here is the whole machine mapped stage by stage, including the parts that broke.

## One vault, two runtimes

The shape first, then the parts.

Everything runs on one Obsidian vault. Plain markdown files, no database, no queue service. Every post is a file, and every file carries a status field in its frontmatter: outline, drafted, scheduled, posted. That status field is the API. Each stage of the machine reads files at one status and writes them back at the next. No stage calls another stage. They only ever talk through the files.

Two runtimes work the vault. Claude Code handles the jobs that need code and network: publish scripts, image rendering, watchers. Cowork, the desktop agent, handles the jobs that are pure reading and judgment: outlining, drafting, critique. Both read and write the same files. Neither one is the source of truth. The vault is.

That is the whole architecture. Everything below is stations along the line.

## Sources in: what feeds the machine

Three inputs feed the vault.

The weekly note. Every week I write down what shipped, what broke, stories worth telling, observations, and hot takes brewing, plus an anti-topics list of stuff that must not get drafted. Written by hand, on purpose.

The saved-posts analyst. Whenever I clip a LinkedIn post I like with the Obsidian Web Clipper, a daily routine reads the clip, writes a structured swipe note on the craft, and downloads the post image the same day. That last part matters: a clipped post hotlinks its image to a URL that expires in months. Download the asset the day you capture it or lose it.

The trend feed. A routine that collects what the industry is currently saying, so counter-takes push against the real orthodoxy instead of a remembered one.

The honest ranking: the hand-written weekly note is the highest-value input in the system, and nothing automates it. The machine turns raw material into drafts. It cannot make the raw material.

## The production line

The factory pass runs Thursday to Friday, station by station.

Thursday, the outliner. It reads the weekly note and the idea backlog and fans them into blog outlines: title, hook, a value proposition naming who the post is for and what shifts for them, and the section beats. An outline with no clear value gets flagged for me instead of padded into a draft.

Friday early, the drafters. The blog drafter expands each outline into a full draft, beat for beat. Thirty minutes later the LinkedIn drafter derives the week's short posts from the deepest one, so the week is one idea atomized, not six unrelated takes.

Friday mid-morning, the critic. It rereads every draft against the voice rules and writes editor notes into the file: weak lines, banned words, claims missing a source.

Friday late morning, the image step renders and attaches the visuals.

Each station is a scheduled routine. Each reads files at one status and leaves them at the next. Pretty much a factory: you work on the machines, and the products come out.

## The one human gate

Then everything stops and waits for Saturday morning.

By the time I sit down, every draft is written, critiqued, and illustrated. My pass is voice and judgment only. Read every line, fix what does not sound like me, flip the status. No outlining, no formatting, no chasing. One sitting.

The gate is manual on purpose, and it stays manual even though automating it is one flag away. I made the full case for that in its own post. The short version: automate the work, keep the door.

## Publish and watch

Statuses drive the exits.

A blog post flipped to scheduled gets picked up by a routine that opens a pull request on the site repo on GitHub. LinkedIn drafts land in Postiz, queued per channel. The newsletter goes out on Resend. Watchers close the loop: when the world confirms a thing went live, the watcher flips the file to posted.

Here is the receipt from when that broke. One watcher matched posts at a single status and quietly skipped the rest. Eleven posts were live on LinkedIn while the vault called them stuck, and the posted count read 7 when the true number was 18. That bug is now a rule in this system: test a watcher against the live system it watches, not against the vault. The vault only knows what got written into it.

## Steal the minimum version

You do not need my whole line to start. You need four things.

One folder of markdown files. One status field in the frontmatter. One scheduled routine that reads files at one status and writes them at the next. One weekly review block where you read what it made and flip the statuses yourself.

Start with the single routine that removes the step you hate most, and prove it end to end before you build the next station. And whenever a migration plan hands you an infrastructure prerequisite, test the smallest version before you accept it. Mine insisted nothing could move without putting the whole vault in git. That was only true for cloud runs. A local pilot proved it wrong in minutes.

I keep the stage checklist for this system, statuses and all, as a one-pager that goes out with The Production Layer, my newsletter at timurtek.com. Subscribe and steal it.

The machine is not the model. It is a folder, a status field, and a review block that respects your Saturday. Build the folder first.

---

## MCP servers worth connecting, and the ones that eat context

- URL: https://timurtek.com/blog/mcp-servers-worth-the-context
- Published: 2026-07-31
- Author: Timurtek
- Category: Tools & Stack
- Tags: Building with Claude

Every MCP server you connect starts spending context before you type a word. A few earn it back with real reach into your tools. The rest sit in the window eating tokens. Here is how I decide which servers get a slot.

## Connecting everything is not free

The bill arrives at session start. When your agent boots, every connected server hands over its tool list: names, descriptions, parameter schemas. All of it lands in the context window before you have asked for anything. You pay whether you call a single tool or none.

The failure mode is connecting everything. Ten servers, just in case, each one resident in every session, while the actual work touches one tool from one of them. The agent gets slower at picking tools, the window gets smaller for the work, and nothing on the dashboard tells you why.

So the question is not which servers are good. Most of them are fine at what they do. The question is which servers earn a permanent slot in your window, and that is a cost question before it is a quality question.

## How to read a server's real cost

Three checks, before any list. Run them on anything you are about to connect.

Count the tools at load. Open the server's tool list and count what it registers the moment it connects. Five focused tools is a different bill than forty. A big catalog is not automatically bad, but you should know the number before it is sitting in every session.

Check whether tools defer or sit resident. The better clients now load tool schemas on demand: the server announces names, and the full schema arrives only when the agent reaches for it. If your client supports that, a wide server gets much cheaper. If everything loads resident, the whole catalog rides along all day.

Read one tool response. Call the server's most common tool once and look at what comes back. Some servers return the field you asked for. Some return the entire object graph with metadata, timestamps, and half the API surface. Chatty responses are a per-call tax on top of the per-session one, and they compound in long agent runs.

Pretty much every server sells itself on capability. None of them advertise the size of the bill. These three checks are how you read it anyway.

## The servers that earn the slot

Five that hold a slot in my own stack, grouped by the job each one does. Every URL and figure below was checked on July 24, 2026, the day I drafted this. Star counts are stated as the repo pages display them. The two official hosted servers have no star count to cite, so none is invented for them.

Design handoff: Figma MCP. The official server pulls variables, components, and layout data straight into the coding agent, and the newer write tools push content back to the canvas. This is the server behind my design-to-code loop: I make the design calls in Figma, then hand the agent the connection to detail every spec and state from the file.
https://developers.figma.com/docs/figma-mcp-server/

Planning layer: Notion MCP. The official hosted server, OAuth setup, reads and writes pages and databases. If your plans, briefs, and trackers live in Notion, this is the difference between an agent that works from your actual system of record and one that works from your memory of it.
https://developers.notion.com/docs/mcp

Browser hands: Playwright MCP. Structured, deterministic browser control from Microsoft, 31.5k stars. The agent drives a real browser through the accessibility tree instead of screenshots, which keeps the responses lean for what browser work costs.
https://github.com/microsoft/playwright-mcp

Automation routing: n8n MCP. The community server by czlonkowski, 22.3k stars. It lets the agent build and trigger n8n workflows, which makes it the bridge between agent judgment and the automations you already run. Wide tool catalog, so it benefits most from a client that defers schema loading.
https://github.com/czlonkowski/n8n-mcp

Web ingestion: Firecrawl MCP. The official Firecrawl server, 7.0k stars. Scraping and search that comes back as clean markdown the agent can use directly, instead of raw HTML it has to burn tokens cleaning.
https://github.com/firecrawl/firecrawl-mcp-server

Five servers, five different jobs, no overlap. That is the shape of a stack that earns its context. I have not benchmarked the exact token load of each one on every client, and anyone quoting universal numbers is guessing past their data. Run the three checks on your own client and trust that reading.

## The ones that just eat the window

The skip patterns matter more than any skip list, because they apply to servers this post never names.

Servers that duplicate what the agent already does. File operations, shell commands, fetching a public web page. Your agent ships with those. A server that re-wraps them adds schema weight and a second way to do the same thing, and the agent now has to choose between them on every call.

Heavy schemas wrapped around thin APIs. If the underlying service does one thing, the server should register a few tools, not thirty variations with overlapping parameters. Catalog width should track service depth. When it does not, you are paying resident context for optionality nobody uses.

Single-tool servers that should have been a script. If the job is deterministic, the same input producing the same output with no mid-task judgment, write the script and let the agent run it. A server earns the protocol when the agent needs to decide things against it mid-task, not just execute.

## The decision rule

One line, and it travels: a server earns a slot when the jobs it covers per session outweigh the context it costs per session, and it gets disconnected the week that stops being true.

Connect on demand, not by default. The slot is rented, never owned, and the rent is due at every session start.

## The checklist

I keep the three checks and the skip patterns as a one-page server evaluation checklist, updated as clients change how they load schemas. It goes out with The Production Layer, my newsletter at timurtek.com, alongside [the repo list that pairs with this post](/blog/claude-code-agent-stack-repos).

Your context window is the one resource every server bills against. Read the bill before you sign.

---

## The repos that turn Claude Code into an agent stack

- URL: https://timurtek.com/blog/claude-code-agent-stack-repos
- Published: 2026-07-24
- Author: Timurtek
- Category: Tools & Stack
- Tags: Building with Claude

Claude Code out of the box is a chat with file access. A short list of repos turns it into an agent stack: orchestration, browser hands, planning discipline, and context plumbing.

## Why a list, and why this one

If you run Claude Code daily, you probably suspect you are using a fraction of it. So you save the roundups. And every roundup you saved repeats the same star counts nobody checked, copied from someone else's screenshot of a list that was already three months old.

This list is different in one boring, load-bearing way: every star count and every URL below was checked against the live repo on July 17, 2026, the day I drafted this. Anything I could not verify got cut, and the cuts are listed near the bottom. Curation without a cut list is a link dump.

The grouping is by job, not by hype. Three tiers. Start with the first, add the second when the agent needs hands, add the third when you are running real work through it.

## Start here: the foundation tier

The smallest set that changes daily work. These give Claude Code reusable judgment: skills and specialist agents it loads when relevant, instead of you re-typing your standards into every session.

obra/superpowers. A skills framework and a development methodology in one plugin. The heavyweight of this list at 218,563 stars. If you install one thing this week, install this and read how it structures its skills before you write your own.
https://github.com/obra/superpowers

wshobson/agents. Subagent and orchestration packs, 35,739 stars. Superpowers gives your agent a method. This gives it a bench of specialists to delegate to.
https://github.com/wshobson/agents

davila7/claude-code-templates. A CLI for configuring and monitoring Claude Code, 27,737 stars. The right first stop if you want setup handled instead of hand-rolled.
https://github.com/davila7/claude-code-templates

Pick one and live with it for a week. Installing all three on day one just gives you three half-learned tools. And whenever you start a new project, carry the configuration forward the same way I carry a starter kit forward, the duplicate and strip pattern from [your starter kit is your last project](/blog/your-starter-is-your-last-project).

## Give it hands: the browser and web tier

The second tier lets the agent act outside the repo: click, browse, and pull the web in.

browser-use/browser-use. The default open-source answer for letting an agent drive a browser, 95,984 stars. Point it at the task, it operates the site.
https://github.com/browser-use/browser-use

microsoft/playwright-mcp. Playwright as an MCP server, 35,197 stars. Structured, deterministic browser control. My pick when the job is testing or scraping a site you own.
https://github.com/microsoft/playwright-mcp

firecrawl/firecrawl-mcp-server. Web scraping and search as MCP tools, 6,980 stars. Turns messy pages into clean markdown the agent can actually use.
https://github.com/firecrawl/firecrawl-mcp-server

The honest cost: every MCP server you leave connected pays a context tax on every session, whether you use it or not. Browser tools are the hungriest of the bunch. Connect them for the task, disconnect after. A tool that is always plugged in is pretty much a subscription you pay in tokens.

## Make it plan: the discipline tier

This is the tier that separates an agent stack from a fast chatbot. Not more capability. More discipline.

OthmanAdi/planning-with-files. Persistent, file-based plans for long-running agent work, 25,448 stars. The plan lives in markdown on disk, so it survives a crashed session, a cleared context, and tomorrow.
https://github.com/OthmanAdi/planning-with-files

czlonkowski/n8n-mcp. An MCP server that lets the agent build and route into n8n workflows, 22,311 stars. The bridge between your agent and the automations you already run.
https://github.com/czlonkowski/n8n-mcp

Plans that live in files survive sessions. That is the same pattern my whole content system runs on, one vault, many agents reading it, and the same reason a [swipe file should live in files you own](/blog/swipe-file-that-does-not-rot).

## The skip list

What got cut, and why. This part is the trust move.

Everything Claude Code. A well-known configuration collection I wanted to include as the reference index. I could not verify the canonical repo at draft time: search surfaces translations and copies of it ranking above the original. When the copies outrank the source, I skip rather than link the wrong one.

obra/superpowers-skills. The older community skills repo for Superpowers. Verified archived. The plugin above replaced it. Star counts on archived repos are history, not signal.

Most MCP servers in the directory. If the job is deterministic, a script does it cheaper than a server that sits in your context all day. An MCP earns its slot when the agent needs to decide things mid-task, not just execute.

Anything whose figures I could only find in someone else's roundup. No exceptions. That rule cost me an entry I wanted to include, and it is the whole reason to trust the eight that stayed.

## The decision rule

Do not install this list. Install one repo: the one that removes the manual step you repeated most this week. Ignore the rest until one of them earns a slot the same way.

I keep the maintained version of this list as a checklist, updated as counts and maintenance status change. It goes out with The Production Layer, my newsletter, so the copy you get is never the three-month-old screenshot.

Eight repos, one install, verified on the day you read the date above. That is the whole system.

---

## The one gate I will not automate

- URL: https://timurtek.com/blog/the-gate-i-will-not-automate
- Published: 2026-07-20
- Author: Timurtek
- Category: Tools & Stack
- Tags: Building with Claude, Operator lessons

My publishing pipeline has one manual step left, and I could automate it this afternoon. I will not. That gate is not a bottleneck I failed to remove. It is where the judgment lives.

## The step I refuse to remove

Everything upstream of that step is agents. An outliner seeds the week's posts. A drafter expands them. A critic flags the weak lines before I ever see them. An image routine attaches the visuals. By Saturday morning the week's content is drafted, annotated, and illustrated, and I touched none of it.

Then it stops. The publisher runs in draft-for-review mode on purpose. Nothing goes public until I have read every line at one door.

The question I kept turning over this month: when is a bottleneck actually a feature? Because I could remove this one in an afternoon. The wiring exists. The status field exists. One flag flipped and the system ships without me.

I don't want a system that ships without me. I want a system where everything waits for me at one door. Those are different architectures, and the second one is a choice, not a leftover.

## The orthodoxy: automation as a finish line

The industry is selling the first architecture hard right now.

Google says its new enterprise agent platform manages fleets of agents from one control point, with an inbox that sorts agent activity into "Needs your input," "Errors," and "Completed." OpenAI says its work agent stays on a project for hours and runs scheduled tasks unattended. The pitch is the same everywhere: fewer human touches.

Fewer touches is a fine goal. What the pitch never includes is an audit of which touch was load-bearing. Every removed touch gets counted as saved time. None gets examined as removed judgment. The finish line is assumed to be zero.

From my perspective, that assumption is the mistake. Zero is not a finish line. Zero is a pipeline with nobody home.

## Execution compressed. Judgment did not.

Here is the zoom-out.

I started as a UX designer, moved into front end, then full product development. With AI in the loop, the build is close to trivial once you know what to build. Design and development compressed. The part before them, deciding what problem, for whom, and what to leave out, did not compress at all. The scarce thing moved upstream.

The same shift happens downstream, at the moment of shipping. A pipeline with zero human gates does not ship better judgment faster. It ships its mistakes at machine speed. Whatever the drafter got wrong at 6 AM is public by 8.

So removing the last gate is not efficiency. It is deleting the judgment layer and calling it throughput.

## A broken bottleneck versus a designed one

The obvious objection: bottlenecks are bad. Operators spend whole careers removing them. I would say that is true for one kind of bottleneck and wrong for the other, and the difference is worth being precise about.

A broken bottleneck is one you never chose. Nobody can say what it catches. It grew there on its own, everyone routes around it, and its cost stays invisible until something jams.

A designed gate has three properties. You placed it deliberately. You know what it catches. And you can say why a human sits there instead of an agent.

Mine passes all three. I placed it at the last door before public. It catches voice drift, wrong claims, and the occasional confident nonsense that reads fine to every agent upstream. And a human sits there because the byline is mine. The doing is distributed across the agents. The judging stays central, and the gate is the address where it lives.

## The vendors just agreed, quietly

The interesting part is that the same labs selling unattended fleets are shipping the opposite signal at the same time.

Anthropic says its new science workbench runs a separate reviewer agent that checks citations and calculations while the pipeline works. MindStudio says Anthropic's internal benchmarks showed a grading agent, one that scores output against a rubric before it counts, lifted document quality by 8.4 percent for Word files and 10.1 percent for slides with no model change at all. The biggest quality lift in the room came from adding a checker, not a bigger brain.

The reviewer wave is real, and it does not remove the question. It moves it. An agent can hold the rubric. Someone still decides what the rubric is, and which door nothing ships past without a human reading it. That decision is the one you cannot delegate, because handing it off is itself the decision.

## Where your one gate belongs

The placement rule, stated plainly: put the human gate where the output is public, hard to reverse, or carries your name. Everything upstream of that point can run unattended, and pretty much all of it should.

One gate, not five. Five gates means you trust nothing you built, and you have rebuilt manual work with extra steps. One gate means everything the system produces converges on a single door, fully loaded, waiting for the only call that matters.

My version is a Saturday morning. Every draft, every critique note, every image, already attached and waiting. The agents did the week's work. I do the one thing they cannot: decide it ships. The longer wiring notes on these builds go out in The Production Layer, my newsletter at timurtek.com, and the same architecture is what an AI OS install stands up inside a business.

I don't know yet what the fully autonomous version costs, because I refuse to run that experiment under my own name.

Automate the work. Keep the door.

---

## Build a swipe file that does not rot

- URL: https://timurtek.com/blog/swipe-file-that-does-not-rot
- Published: 2026-07-17
- Author: Timurtek
- Category: Founder Lessons
- Tags: Operator lessons, Building with Claude

Most swipe files are a folder of dead links. You clip the post, the text survives, the image quietly expires a few months later, and the thing you actually wanted to study is gone.

## The swipe file that rots

The save button feels like progress. It is not.

Six months in, you open the folder and it is a list of titles. You remember one of them had a chart whose shape you wanted to steal. You cannot find it. When you finally do, the image is a gray box with a broken-link icon.

Here is the reframe that fixed this for me. A swipe file is not a collection. It is a retrieval system. Most people build the collecting half and stop, because collecting is the part that feels good.

## What a clip actually saves, and what it quietly drops

I use the Obsidian Web Clipper. It is good at its job. It keeps the body text, the author, the date, and the source URL, and it drops all of it into my vault as a markdown file I own.

Here is what it does not keep. The image.

The clipper hotlinks the picture back to the platform's CDN. On LinkedIn those URLs carry an expiry parameter baked right into the query string. Nothing looks broken on the day you save it. That is the trap. A few months later the link is dead, and the post you saved specifically because of its chart is now a post with no chart.

That is the piece you most wanted. On a carousel, the image is the entire artifact and the text is just a caption. Losing it means you saved the wrapper and threw away the thing.

## Capture into the place your agents already read

Whenever I save something now, it lands as a file in the vault, not a bookmark in an app I do not control.

One file per post, in a Sources folder. The URL and the author in the frontmatter. A separate to-clip list for the ones I catch on my phone and cannot process properly yet.

The rule underneath is small and it matters more than it looks: capture into the same place your agents already read. A bookmark in a browser is invisible to everything else you have built. A markdown file in the vault is readable by every routine you run, today and the ones you have not written yet.

That single decision is what turns a pile of saves into something a machine can work on.

## Download the asset on the day you capture it

This is the move that actually stops the rot, and it is almost embarrassingly simple.

Pull the image down to a local media folder on the day you clip it. Not later. Later does not exist. Later is where good intentions go to expire alongside the CDN link.

The tradeoff is honest and small. You spend a little disk, and in exchange your swipe file still works when the source is gone. I would make that trade every single time.

If you only take one thing from this post, take this one. Everything else is refinement.

## Write a craft note, not a summary

Capture without analysis is just hoarding with extra steps.

I run a routine every morning that reads the new clips and writes a structured note on the craft. Not what the post said. What the post did.

That distinction is the whole game. A summary tells you the topic, which you already knew, which is why you saved it. A craft note tells you the mechanism: how the open earns the scroll, what shape the structure is, how the closer lands, what pattern the whole thing belongs to, and whether that pattern is reusable in your lane or only works because of who wrote it.

A summary is a receipt. A craft note is a blueprint.

## What to write down so it is still useful in a year

Keep the fields tight. Long templates never get filled in. These are the ones that carry weight.

The hook shape. Not the hook itself, the shape of it. Does it dare the reader, name a number, invert something they already believe. Shapes travel between topics. Hooks do not.

The structure. Tiered list, audience-split open, receipts-then-fix, whatever it is. Name it, so you can reach for it later without rereading the whole post.

The closer, and the one line you would actually steal.

And this one almost nobody bothers with: where the top comments landed. That is free audience research, run on someone else's post, at their expense. The comments tell you what the audience actually cared about, which is frequently not what the author thought they were writing about. I have gotten more usable signal from comment sections than from the posts above them.

Keep the source anonymized. The note is about the craft, not the person.

I keep a template with exactly these fields and nothing else. If you want it, it goes out with the newsletter.

## Capture is cheap. Retrieval is the product.

Every post you save is a bet that some future version of you comes looking for it.

The bet only pays if the thing you find is readable, structured, and still has its pictures.

Build the retrieval half, or stop saving.

---

## The model is a guest. Your system of record is the house.

- URL: https://timurtek.com/blog/the-model-is-a-guest
- Published: 2026-07-07
- Author: Timurtek
- Category: Founder Lessons
- Tags: The Install Method

Almost every AI project I get called into is one giant chat. Months of context trapped in a thread that gets slower and dumber as it grows, and gone the day someone opens a new one.

## The thing most AI setups get backwards

Most teams treat the model as the system. They pour everything into the chat. The context, the decisions, the history, the actual work. It feels productive while it is happening. It is also the reason none of it compounds.

The model is the part you should be able to throw away. The system is supposed to be the part that stays. When you build it the other way around, you are renting your own memory, and the lease runs exactly as long as a chat window.

So the first thing I install is a line.

On one side, the intelligence layer. The model, the agents, the session, the thing doing the thinking right now. On the other side, the system of record. The place the context and the decisions and the progress actually live. The model is a guest. The system of record is the house.

Once that line exists, the model stops being something you are stuck with and becomes something you can swap. Everything a guest ever did stays in the house after the guest leaves.

## What it looks like, twice

My own content runs this way. There is a vault that holds everything. The voice rules, the proof, every draft, the calendar, the standards. The model is whatever I open that day. I can switch from one to another in the middle of the week and the system does not flinch, because the model was never holding the state. The vault was. The model just reads where the work is and picks up.

I run my health the same way, which sounds like a stretch until you see the shape. I log meals, sleep, and workouts, and the data lives in Notion, not in the chat. Any model I open reads the same record and coaches from it. I switched models mid-week once and my progress did not reset, because the trainer was never the model. The trainer was the record, plus whatever model happened to be reading it. Two months of that and the trend is real: better sleep, better composition. The point is not the numbers. The point is that the numbers had somewhere permanent to live and something that could read them.

Different domains, same architecture. Keep the record permanent. Keep the intelligence swappable.

## Why the one-giant-chat version always breaks

When the model is the system, three things happen, and the third one is the expensive one.

The chat gets slower as it fills. The context gets capped and starts falling out the back, quietly, so you do not notice which parts left. And the day the session ends, or the tool changes, or the model gets deprecated, the whole memory goes with it.

I have watched teams rebuild the same context three times because it lived in three dead threads. That is not a model problem. No bigger model fixes it. A smarter model with no memory is still starting from zero every morning. It is an architecture problem, and the fix is boring on purpose: put the context somewhere the model does not own.

Boring is the point. The exciting part of AI moves every few months. The boring part, a clean record the models read from, is the part that is still standing when the exciting part gets replaced.

## The second line, one level down

There is a second line worth drawing once the first one holds. Inside the intelligence layer, separate the doing from the judging.

The doing is the session that runs the task. Fast, scoped, throwaway. The judging is the smaller, central set of agents that check the work, hold the standards, and decide what is good enough to keep. Keep the judgment central and reuse it across every doing-session, instead of re-explaining your standards in every new chat.

This is the same instinct as a design system. When you find a problem, you fix it at the source of truth, not in every screen that happens to show it, so the fix cascades for free. Same with AI. Fix the standard at the central judging layer, not in every session that consumes it.

That part is a refinement though. The load-bearing line is still the first one. Intelligence on one side, record on the other.

## What I actually install

When a company brings me in for AI, this is most of the job. Not a cleverer prompt. A system of record their models can read, a clean line between the part that thinks and the part that remembers, and a few judging agents that keep quality from drifting as the volume goes up.

Once that exists, the model becomes an upgrade you choose, not a dependency you are trapped under. The work compounds because the context survives the session that made it. New hire, new tool, next year's model, the house still stands and everything in it is still there.

If you want the longer version of how these get built, the friction included, that is what I write up at timurtek.com, and the newsletter is where I go a layer deeper on the actual wiring. No pitch. Just the builds, and what broke in them.

## So

The model you are using today will be old in a year. Build so that does not matter. Make the model a guest and the record the house, and you get to keep everything every guest ever did.

---

## Your starter kit is your last project: the duplicate and strip scaffold

- URL: https://timurtek.com/blog/your-starter-is-your-last-project
- Published: 2026-07-04
- Author: Timurtek
- Category: Tools & Stack
- Tags: Building with Claude, Operator lessons

Whenever I start a new project, I do not run create-next-app. I fork my last shipped project and have Claude Code strip it down to the bones. Your highest-fidelity starter kit is not a boilerplate repo. It is the last real thing you shipped, with the app logic removed and the design system left standing.

## The orthodox scaffold and why it starts you behind

The default move when you start something new is to reach for a blank scaffold. create-next-app. A starter template off GitHub. A boilerplate someone posted that has a nice folder structure.

And then day one goes to rebuilding the stuff you already built once. The blank scaffold has none of your design system. None of your shared components. None of your auth pattern, none of your CI config, none of the table primitives you got right last time. It is clean in the sense that an empty room is clean. It is also empty in the sense that you own nothing in it yet.

That is the part the blank-repo feeling hides. Clean here does not mean ready. Clean means you just threw away your own leverage and signed up to rebuild it from scratch before you write a single line of the actual new thing.

## The better primitive: your last shipped project

Here is the move. Your last shipped project is a better starting line than any template, because it is the only scaffold that already has your real work in it.

It has the real design system, the one you battle-tested in production, not a generic one off a starter. It has the shared components you already debugged. It has the patterns you figured out the hard way the first time: how auth wires up, how the data layer is structured, how the build deploys. That stuff is the most expensive part of any scaffold, and you already paid for it.

The orthodox move reaches for a generic template and builds up. The better move forks the thing that already works and subtracts down. Subtracting from something real is faster and safer than adding to something blank.

## The duplicate-and-strip move, step by step

Here is the actual workflow. It takes about ten minutes.

Fork the last project folder. Copy and paste the whole thing, give it the new project's name.

Open it in a fresh Claude Code session. Point Claude at the root.

Tell it to strip the app logic. Say it plainly: keep the branding, keep the design system, keep the shared components, keep the table primitives, keep the auth scaffolding and the CI config. Strip everything that belonged to the old product.

Let it work, then read the diff. Claude shows you what it cut. You skim it, catch anything it stripped too aggressively or kept that it should not have, and correct it in the same session.

Reset the obvious project-level stuff. Name, metadata, environment variables, the readme. Now you have a clean repo with all your accumulated scaffolding standing and none of the old product's guts. New project, scaffolded in minutes, on your own standards from line one.

## Why Claude Code makes strip work and a template cannot

You could not do this with find and replace, and that is the whole reason a coding agent is the right tool here.

Stripping is judgment work, not mechanical deletion. The agent has to trace the codebase and decide, file by file, which code is domain logic that belonged to the old product and has to go, and which code is reusable scaffold that should stay. A button component stays. The route that fetched the old product's orders goes. The design tokens stay. The data model for the old product's entities goes. A shared table primitive stays. The page that composed that table into the old product's specific dashboard goes.

That tracing is exactly the kind of thing a coding agent is good at and a static boilerplate can never do, because a boilerplate is frozen. It does not know your code. It cannot tell your scaffold from your product. Claude can, if you hand it the project and the keep-list up front. Give it the keep-list first, then the output is crisp.

## The line: what you keep, what you cut

The whole move comes down to one clean line.

Keep the scaffold. The design system, the tokens, the shared UI primitives, the table components, the auth scaffolding, the CI config, the folder structure. That is your accumulated leverage. It is the work you do not want to do twice.

Cut the product. The domain models, the business logic, the routes, the data layer that belonged to the old app. That is everything that made the last fork the old product instead of the next one.

If you can name which side of that line a piece of code is on, Claude can strip it. Most code tells you which side it is on the second you ask the question.

## The part that compounds

Ten minutes instead of a day is the small win. The real win is what happens over time.

Every project you ship leaves a better starter behind. You improve the design system in project four, and project five forks that richer baseline for free. You harden the auth pattern on one build, and every build after it inherits the hardened version. The scaffold gets better every single time you ship, because the scaffold is just your last real project with the product stripped out.

A boilerplate from two years ago stays frozen at two-years-ago. Your last project keeps moving. That is the difference between a scaffold that compounds and a scaffold that calcifies. Pick the one that compounds.

## The closer

Fork your last repo tonight. Point Claude Code at it. Tell it to strip the logic and keep the bones.

Pretty much that.

---

## What to build is the job now: AI did not lower the risk of building the wrong thing

- URL: https://timurtek.com/blog/what-to-build-is-the-job
- Published: 2026-07-02
- Author: Timurtek
- Category: AI Workflows
- Tags: Hot takes, Building with AI, Operator lessons

A survey of 900 plus engineers just said the quiet part out loud. The job is moving from how to build to what to build. Here is the part the survey buried. AI does not lower the risk of building the wrong thing. It raises it. Execution got cheap, so building the wrong thing faster is the new default failure mode.

## The orthodoxy, named with the leaderboard

The discourse has one answer to almost everything right now: the bigger model is the edge. More throughput, faster shipping, the next flagship changes everything. Wait for the release. The release is the strategy.

Two headlines in one stretch carried that message. Fortune reported that Anthropic confidentially filed for an IPO at a 965 billion dollar valuation, with Claude Code cited as a main revenue driver. In the same window, Google said at I/O that Gemini 3.5 Pro was on the way, and by mid-June it was still sitting in limited preview, telling people to wait until next month.

A record valuation on one side. A delayed flagship on the other. The leaderboard and the cap table are the story everyone is watching. The assumption underneath both is that the model is the variable that decides who wins.

## The data that breaks it

Then the orthodoxy's own audience reported back, and the report does not match the story.

The Pragmatic Engineer survey says it polled 900 plus engineers and sorted AI's effect into three types: builders, shippers, and coasters. The finding is that AI amplifies whatever tendency was already there. It does not level the field. It widens the gap that was already on it.

The shippers are the tell. The survey says they get to production faster, and in the same breath they add tech debt faster and build the wrong things faster. Speed went up. Direction did not. And the line the survey lands on is the one I keep coming back to: the craft is moving from how to build to what to build.

That is the orthodoxy's own readership reporting that the orthodoxy is tuning the wrong variable. The model is not the thing separating the builders from the shippers. The judgment about what to build is.

## The thing I have been running for a year

I have been running this inversion in my own work since before the survey caught up to it.

The production line flipped. Execution compressed almost to nothing. The part before execution did not compress at all. So I spend almost no time on the build and almost all of it upstream.

What problem, stated precisely. Who it is for, with real personas built on real data, not a stock "our user." User stories from those personas, where feature X solves problem Y and there is a clear account of how it gets delivered.

Get the feature list, the user stories, and the designs done right, and the development runs about 95 percent smooth. Claude does the build, and the build is close to trivial once the upstream work is real. Get the upstream work wrong, and AI just builds the wrong thing faster and with more confidence. The documentation before the first design file is where the whole thing is won or lost.

## Why AI punishes the skip instead of saving you from it

Here is where I want to push back on the dream the tooling sells.

I do not want a faster way to ship the wrong thing. I want to be more sure it is the right thing before a single line of code exists. Those are not the same goal, and AI is very good at the first one while pretending it solved the second.

Think about what slowness used to do for you. When building the wrong thing cost three weeks, the wrongness got caught in the three weeks. You felt the drag. Someone asked the question. The cost of being wrong was paid slowly enough that you could stop before you paid all of it.

Now the wrong thing ships in a day. The slowness that used to catch it is gone. The cost of skipping the upstream work did not disappear with it. It moved downstream, where it is more expensive to fix and harder to see, and it got bigger on the way.

Cheap execution did not remove the tax on building the wrong thing. It just deferred the bill and added interest.

## Where the market is putting its money

If this were only my opinion, you could discount it. The market just made the same bet with real money.

SiliconANGLE says a new AI-native services firm, backed by Anthropic and two private-equity backers with a combined sum reported in the billions, acquired an embedded-engineers shop to be its delivery team. The pitch, in their framing: decks and roadmaps do not move a business. Engineers who go into the operation and rebuild the system around what frontier models can now do are what move it.

Read that again. A billion-dollar bet just priced judgment-in-the-room above execution speed. Not the model. Not the deck. The operator who decides what to rebuild and then rebuilds it.

That is the wedge I sit in, at a different scale. The difference is that they need a balance sheet and an acquisition to do across many clients what one operator can do for one client at a time. Same shape of value. They are buying the seat. I am the seat.

## The honest limit

I will say the thing the confident version of this post would leave out.

I do not know what is coming with AI in future. The specific upstream method I run today, the personas, the user stories, the documentation pass before the design file, that might change shape entirely as the tools change. I am not going to pretend the method is permanent.

But the bet under the method is one I would make for the next few years without hesitating. The bottleneck moved from execution to judgment, and I do not see it moving back. I would rather be early to that than fast at the wrong thing.

## The closer

The model got faster at building. It did not get faster at knowing what to build.

That gap is the whole job now.

---

## AI as the detailer, not the designer: where the on-canvas agent moves your value

- URL: https://timurtek.com/blog/ai-detailer-not-designer
- Published: 2026-06-29
- Author: Timurtek
- Category: Founder Lessons
- Tags: Design to AI bridge, Building with Claude

Figma just shipped a design agent that details on the canvas. The design crowd is reading it as a replacement. From my perspective it is the opposite. The tool now does the detailing, so the only thing that got more valuable is the judgment about what should be on the screen in the first place. AI as the detailer, not the designer. The human still draws the line.

## The orthodox read of the canvas agent

Here is the read almost everyone landed on. Figma's agent works directly on the canvas. It does bulk edits, explores variations, documents the design system, fills in the states you never got around to. Config 2026 put agentic design workflows at the center of the week. And the design crowd looked at all of it and saw the same thing: the craft is getting automated.

I get why that read feels right. Detailing was the craft for a long time. The hours went into every spacing token, every hover state, every empty-state illustration nobody asked for. If a tool does all of that now, it looks like the floor just dropped out from under the job.

But Figma said the quiet part out loud in the same announcement. As designs get easy to generate, the risk is shipping something average. That is not a footnote. That is the whole point. When generation is free, average becomes the default, and the only defense against average is judgment about what should exist in the first place.

## The line I actually draw

So here is the line I draw, and I draw it the same way every time.

AI as the detailer. Not the designer.

The loop I run looks like this. I translate the problem into Figma myself. I make the judgment calls in Figma: what should be on the screen, what the hierarchy is, what the flow does, what gets cut. Then I give the agent the connection and let it detail every spec, every state, every variant that follows from those calls.

The human decides what exists. The model produces the volume that follows the decision. That is the whole division of labor, and the order matters. The agent is not picking the screen. It is executing the screen I already picked.

I would say most of the disappointment people have with design agents comes from running this backwards. They ask the model to decide and detail in one move, then wonder why the output is generic. Of course it is generic. They handed the judgment to the part of the stack that does not have any.

## Why the design system is what makes this work

Here is the part that actually makes the agent trustworthy, and it is not the model.

It is the design system.

The agent produces output you can trust only when it has the design-system context. Figma's 2025 AI report says 68 percent of developers use AI to write code, but only 32 percent of developers and designers trust the output. The space between those two numbers is not a model gap. It is a context gap. Figma's own framing is that asking an agent to generate output with no design-system context is like asking a new hire to ship before onboarding.

That lands for me, because it is the same source-of-truth discipline I run everywhere else. The design system is the shared language between your judgment and the model's detailing. You encode the spacing, the tokens, the component behavior, the rules once, in one place. Then the agent reads from that place instead of guessing.

The alternative is re-explaining spacing and tokens in every prompt, forever. That is not a workflow. That is a tax. Feed the agent the central system once and the detailing inherits your standards by default.

## The role compression underneath

Step back from the tool and look at what actually compressed.

A year ago this work was a handoff. Design produced artboards. Engineering rebuilt them. The marketing of the decision happened after the fact, if it happened at all. Intent leaked at every seam, and the rebuild was where most of it got lost.

Now one operator draws the line and runs the detailing across design and code in one workflow. I can work the marketing framing in one cloud session while the component work builds in another. The disciplines did not disappear. Design is still design. Code is still code. Marketing the decision is still its own skill. What changed is that the seat doing all three is now a real seat, and the agent is what makes that seat hold.

AI did not change what the work is. It changed the speed and the range. The handoff tax is the thing it removed, and the design-to-code detailing pipeline is where you feel that most.

## What gets more valuable when the detailing is free

Once detailing is cheap, the scarcity moves. This is the part worth sitting with.

Generating 32 states nobody asked for is free now. The agent will produce all of them before you finish your coffee. Deciding which 3 of those states deserve to exist is the work. That decision did not get cheaper. If anything it got more valuable, because now it is the only expensive thing left in the room.

I think about this as a doing layer and an intelligence layer. The agent is the doing layer: high volume, fast, scoped, tireless. The judgment is the intelligence layer: what problem, for whom, what belongs on the screen, what gets cut. The AI does the catalog. The human does the judgment. Drawing that line clearly is most of what using AI well actually means in practice.

Get the line right and the agent is leverage. Get it wrong and the agent is just a faster way to ship 32 average states.

## The honest limit at the strategic level

I will be straight about the part I do not know.

I do not know which detailing tasks stay human in two years. The line between catalog and judgment is not fixed. It has moved before and it will move again, and some of what I call judgment today will be cheap detailing in future. I would be lying if I drew that line as permanent.

But the bet I am making with my hours is the judgment layer, not the execution speed. I can already rent the execution from the model. The thing I cannot rent, and the thing that gets more valuable every time detailing gets cheaper, is knowing what belongs on the screen in the first place. That is where I would put my time today, even knowing the line will move.

## The closer

The agent will detail the crap out of the screen. It still cannot tell you which screen deserves to exist.

That gap is where the operator lives.

---

## Fix the source, not the symptom: design systems are AI prompt libraries

- URL: https://timurtek.com/blog/fix-the-source-not-the-symptom
- Published: 2026-06-01
- Author: Timurtek
- Category: Founder Lessons
- Tags: Design to AI bridge, Operator lessons

Most teams treat a UI bug as a bug in the app they noticed it in. Wrong layer. The bug lives where the source of truth lives, and most of the time that is the design system, not the consuming app. The same discipline applies to AI: fix the prompt at the central skill layer, not at every consuming agent.

## The default move that wastes a week

When a teammate flags a UI bug on an app, the orthodox path is to log it against that app. Description, repro steps, screenshot, ticket. Assigned to the team that owns the app. Resolved by patching the rendering in that app's codebase.

That path feels precise because it is local. Local feels diligent. Local feels accountable. You touched one file. You fixed one symptom. The ticket closes.

It is also wrong, most of the time. Most UI bugs I find on the consuming app are really design-system bugs in disguise. Patching them at the app layer is a tax you pay per app per occurrence, and the same bug will reappear in three other places next quarter because the actual cause lives somewhere you did not look.

## The layer trace as a sourcing discipline

Before logging anything, ask one question. Does this bug live at the consuming app layer, or does it live at the design system layer that the app pulls from.

That question is the layer trace. It takes thirty seconds. It changes where the work happens.

A bug logged at the app layer is patched once. A bug logged at the design system layer is fixed for every app that consumes it. Same fix. Different surface. Different blast radius.

I just ran a second full structured audit of an app's 2.0 surface, page by page. Same correction pattern over and over. I would catch myself flagging a UI bug at the app layer, then interrupt myself and say, wait, this should be fixed at the design system, not here. Same self-correction, three or four times in the same hour. After the third one, the layer trace stopped being an interruption and started being the first thing I did.

That is the whole discipline. One question, asked before the ticket exists.

## The shape of the bug determines the layer

Most layer-trace calls are not ambiguous once you have the question on the table. The shape of the bug tells you the answer.

Camel-cased labels in a sort dropdown. That is a token formatting concern. Lives in the design system.

Missing disabled cursor on a button. That is a base interaction state. Lives in the design system.

A chip styled like a button so users keep trying to click it. That is a visual ambiguity between two base components. Lives in the design system.

A dropdown menu with no minimum height that collapses to a single-pixel sliver when there is one option. Same shape. Design system.

Then the other side of the line.

Missing per-variant test cases on a dynamic table grouped by brand. That is the consuming app, because the variant is the composition the app builds out of the base table. The table itself is fine. The app's choice to use it grouped, pinned, with this specific filter shape, is what is missing tests.

A specific report page failing to wire its currency dropdown into a real currency context. That is the consuming app. The dropdown component is doing its job. The wiring is the app's responsibility.

The discipline is showing both kinds in the same audit and naming the layer for each. The audit itself stops being a bug list and starts being a sourcing map. Same artifact. Different output.

## The same discipline maps to AI systems

This is where the post stops being about UI bugs.

Most AI workflows ship with prompts living inside every consuming agent. The agent that drafts a report has its own prompt. The agent that summarizes a meeting has its own prompt. The agent that critiques the draft has its own prompt. Twelve agents, twelve prompts, twelve forks of the same baseline voice rules.

When the voice rules need to change, the orthodox path is to update each agent. Twelve diffs across twelve repos. A week of work. Drift between them by the end of the month because somebody missed agent number seven.

Stop patching prompts in every agent that calls them. Prompts are the design tokens of an AI system. The voice rules. The output shape. The guardrails about what the model will and will not do. Those belong at a central skill layer the consuming agents inherit from.

Centralize the skill. When the voice rule changes, every consuming agent inherits the fix. When the skill lives in twelve forks, you patched the symptom in twelve places and the root cause is still there, waiting to bite the next time you need to change anything about how the system speaks.

Same layer trace. Different surface. The question is the same: does this prompt issue live at the consuming agent, or at the skill layer that the agent pulls from.

## The economics

A design system fix cascades to every app for free. The fix has a one-time cost. The cascade is the payoff.

An app-layer fix is a tax. You pay it once per app per occurrence. Three apps, three taxes. Twelve apps, twelve. The cost scales linearly with how many surfaces consume the broken thing.

The same math holds for prompts. A skill-layer fix cascades to every agent that inherits. An agent-by-agent fix is a tax that scales with how many agents you have. The bigger the agent fleet, the more painful the tax becomes, and the more invisible it gets because nobody is tracking the per-agent patching as a line item.

The first time you do the layer trace, it feels slower because you are not just fixing the thing in front of you. You stop, ask the question, decide the layer, often have to write a more careful fix because the design system version has to handle every consuming case, not just the one you noticed.

By the third audit, it is the only thing that compounds. The local fixes pile up linearly. The source-of-truth fixes pile up exponentially. After six months, the team that did layer traces has a system that is getting cleaner. The team that patched at the app layer has a system that is getting more entangled with itself.

That is not a discipline difference. That is a where-the-fix-lives difference.

## When the layer trace tells you no

The discipline cuts both ways. Sometimes the layer trace says the bug really does live in the consuming app, and the right call is to fix it there.

A specific report page where the data wiring is wrong. The chart legend cluttering at a screen size that only matters on that page. A button placement that only makes sense in the context of one specific user flow. Those are app-layer bugs. Logging them against the design system would be wrong in the other direction.

The point is not to default everything to the design system. The point is to ask the question. Defaulting everything to the app is lazy. Defaulting everything to the design system is lazy in the other direction. The discipline is the trace, not the destination.

## The closer

When a bug shows up, ask the layer question first. Where does this actually live. The right answer is almost never the layer where you noticed it.

The same question works for prompts. The same question works for the next layered system that has not been invented yet. Source-of-truth discipline is not a UI rule. It is a sourcing rule that happens to show up first in UI work because design systems make the layers visible.

Fix the source. The symptom takes care of itself.

---

## What the analytics caught the first week: a weekly operating routine for a solo marketing site

- URL: https://timurtek.com/blog/weekly-analytics-routine
- Published: 2026-05-28
- Author: Timurtek
- Category: Founder Lessons
- Tags: Operator lessons, Building with Claude

I built a weekly analytics routine for [timurtek.com](http://timurtek.com) in an afternoon. The first run caught a newsletter form leaking 80 percent of intent, a LinkedIn preview bug that had been killing referrals for three weeks, and five 404 URLs with real inbound traffic nobody had noticed. Here is the routine, the actual numbers, and why most solo marketing sites are flying blind in exactly these places.

## GA4 was wired. Nobody was reading it.

The site went live with Google Analytics 4 wired in correctly. Pageviews, events, conversion goals, the whole panel. The number was technically being captured. It was not being read.

This is the default state for most solo marketing sites. The dashboard exists. The numbers update. The owner opens it once a week, scrolls for thirty seconds, sees a flat line or a spiky line, closes the tab. No decision gets made. No experiment gets queued. The dashboard is a wallpaper.

The fix is not a prettier dashboard. The fix is a routine that turns raw numbers into a question the operator has to answer that Monday morning. Raw numbers in an inbox are not a routine. They are noise.

## The architecture: snapshot, analyze, email, schedule.

Four moving parts. Each one boring on its own. Together they are the operating loop.

First, a snapshot script pulls the prior week from GA4 and writes a JSON blob to the repo. Same shape every week. Versioned. Diffable.

Second, an analyzer reads two snapshots, takes the deltas, and runs a small set of heuristics against the result. The heuristics are the judgment layer. They live in Python because interpretation is judgment work, and judgment work belongs in versioned code I can edit and review, not in an n8n Code node I open once a quarter and squint at.

Third, the analyzer writes a markdown report and an n8n webhook pushes that report into my inbox.

Fourth, a GitHub Actions cron triggers the whole thing every Monday at 8 a.m. ET. The email is waiting when I sit down. Thirty minutes of work and one decision later, the week has a queued experiment.

The whole thing took an afternoon. The hard part was not the code. The hard part was deciding what the heuristics should say.

## The heuristics. What counts as a leak.

A leak is a place where intent shows up and conversion does not. Concretely, the heuristic the script uses is: form start to conversion under 20 percent. If a hundred people start the form and fewer than twenty finish it, the form is leaking. Something between the first field and the submit button is killing the intent.

A working page is the inverse: average session over 120 seconds with at least three pageviews from that landing. People landed, read, kept reading, clicked into something else. The page earned the visit.

Bounce rate is a trap below 500 sessions a week. It moves on noise at low traffic. Below the threshold, the heuristic ignores it entirely and writes a one-line note that says traffic is too thin for bounce to mean anything yet. I would rather the report admit the data is thin than print a number that pretends otherwise.

The whole heuristic set fits on one screen. The point is not sophistication. The point is consistency. The same questions get asked every Monday. The answers move week over week. Trend lines beat snapshots.

## What the first run found.

Three findings. Each one a real dollar amount of work that had been quietly draining.

The first was the newsletter form. 32 starts. 6 signups. 19 percent completion. The script flagged it as a leak before I even read the report header. I had been watching the signup number climb slowly and feeling fine about it. The completion number changed the frame entirely. The form was not converting. The form was bleeding. There was a working version of the asks and a broken version of the form between them, and only the second number told me which was which.

The second was LinkedIn previews. The report flagged a referral drop from LinkedIn that had been happening for three weeks. I had not looked because LinkedIn is not the biggest traffic source, so a drop there reads as noise. The root cause turned out to be a metadata serialization quirk: the page-level openGraph object was replacing the layout-level images metadata instead of merging with it. Every new blog post shipped with no preview card. LinkedIn was scraping the URL, finding no preview, and posting a bare link with no thumbnail. Three weeks of LinkedIn traffic lost to a metadata bug nobody would have noticed by reading dashboards.

The third was the 404 audit. Five URLs with real inbound traffic landing on dead routes. Webflow leftovers, a plural-vs-singular typo on one blog slug, a deleted post somebody had bookmarked. None of these would have surfaced from looking at the conversion funnel. They only surfaced because the script reads the referral table and cross-checks against actual rendered status codes. Boring discipline. Real recovered traffic.

## The OODA loop. Monday email. Thirty minutes. One experiment.

The routine has four moves. Observe the report. Orient on the biggest leak. Decide on one experiment. Act, ship it that day.

Then the discipline. Next Monday compares. If the experiment moved the number, keep going. If it did not, kill it and pick the next leak. One cycle per week. No experiment runs past two cycles without proof.

The trap on solo marketing sites is the opposite move: ship three experiments at once because they all look reasonable, then a month later not know which one moved anything. The script forces one-at-a-time because the heuristics surface one biggest leak. Pick that one. Ship that one. Wait a week.

Discipline is killing what did not work after one cycle. Most teams skip the kill step. They keep both experiments running because both are technically still moving in the right direction. By month three the dashboard is a soup of half-results and nothing is attributable. The kill step is what makes the loop a loop instead of a pile.

## Why this is a fractional AI move, not just a marketing tip.

Production AI ops surfaces work the same way as a marketing site dashboard. A number on its own is not an answer. A number on its own is a question.

The eval suite that returns 87 percent accuracy is a question. Which 13 percent is the script wrong about. Are the wrong answers spread evenly or clumped on a specific intent. Is the wrong-rate climbing week over week against a fixed test set, or is the test set drifting.

The script writes the question. The operator picks the experiment.

This is true for analytics. It is true for evals. It is true for cost dashboards on model spend. It is true for latency p95 charts. The pattern compounds: build the layer that asks the right question every cycle, then spend your judgment time on the answer, not on remembering to ask.

The teams that ship AI in production are not the teams with the biggest model budgets. They are the teams that built the smallest, dumbest, most consistent question-asking routine and then ran it for a year. Same shape as a Monday analytics email. Different surface.

Most solo marketing sites are flying blind in the same three places mine was. A leaking form. A broken preview. A handful of 404s nobody noticed. The fix is not better tooling. The fix is a routine that catches them once a week, every week, without you having to remember to look.

That is the part that compounds. Pretty much that.

---

## Remove Complexity From Your MVPs

- URL: https://timurtek.com/blog/remove-complexity-from-your-mvps
- Published: 2026-05-16
- Author: Timurtek
- Category: Founder Lessons
- Tags: Operator lessons, Founder/Fractional

The first version of a product should be embarrassingly simple. Not "minimal." Not "lean." Embarrassingly simple.

Software naturally tends toward complexity. Every feature spawns three more requirements. Every requirement spawns its own support load, its own onboarding, its own dashboard. The work most teams don't do is subtraction. The work most teams should be doing is subtraction.

## Why complexity wins by default

Most product teams don't choose complexity. They drift into it. Each individual decision sounds reasonable. "We should add a settings toggle so the user can choose." "We should support both flows so we don't lock anyone out." "We should make this configurable in case the rollout pattern changes."

Each one of those, on its own, is defensible. The sum of them is a product nobody can describe in a single sentence. By the time you can see the complexity, you're three releases into maintaining it. The cost shows up as a slower team, a longer onboarding flow for users, and a backlog full of features no one asked for.

The teams that ship clean MVPs aren't smarter. They have a tighter "no." They turn down the same reasonable-sounding feature requests that other teams say yes to.

## A streamlined MVP

Chasing perfection in early development dilutes the core value proposition. Simplicity should be the focus, not by cutting corners, but by concentrating effort on what genuinely matters.

The first version is supposed to look unfinished. If it looks finished, you're already two versions late. The product that ships with rough edges and a sharp value-prop will outperform the product that ships with polish and no clear reason to exist. Users tolerate rough. Users don't tolerate confused.

This is the bar to hold yourself to in the first month. If a stranger lands on your product, can they tell you in 30 seconds what it does, why it exists, and what to do first? If yes, the simplicity is doing its job. If no, you have a positioning problem that more features will not fix.

## Streamlining the development process

Four strategies, in order of leverage:

1. Define the core value proposition. Write down the single problem your product solves before adding a single feature. If you can't write it in one sentence, you don't know what you're building. The sentence is the spec. Everything that doesn't serve the sentence is scope creep wearing a clever disguise.

2. Prioritize ruthlessly. Resist the urge to include every conceived feature. Cut. Then cut again. The features you don't ship are doing more for your product than the ones you ship. A short list of things you do well beats a long list of things you do okay, every time. The same applies inside features. A small handful of well-handled empty states beats a long backlog of "we'll get to that."

3. User-centric design. Conduct research and iterate based on actual user needs. Not assumed needs. Not "what we think they want." What they actually do when they touch the product. Watch a real person use your tool for 20 minutes and you'll see things no user interview surfaces.

4. Agile development and iteration. Work in small milestones. Ship a vertical slice. Watch what users do. Refine based on what you saw, not what you planned. The plan is the starting point, not the destination. If the plan and the data disagree, the data wins.

## What "complexity" actually costs

Complexity in an MVP is rarely about the code. It's about the cognitive load. Every feature you add increases the surface area users have to understand, the surface area your team has to maintain, and the surface area future-you has to refactor when the underlying assumption changes.

The math is harsh. A product with five features takes roughly five times the support effort of a product with one feature, and roughly twenty-five times the testing matrix. That's why early-stage products that try to do five things at once stall. The team isn't slow. The math is.

## Why this matters for AI systems

AI amplifies the complexity risk. Models can appear functional across a hundred tasks while failing unpredictably on the hundred-and-first. A rules-based system at least fails predictably. A model fails in novel ways your team hasn't imagined yet.

For AI MVPs, the rule is sharper. Pick one workflow. End to end. Human in the loop. A trace log you can actually read.

That sentence is the entire AI-MVP doctrine in one line. Most teams skip every clause.

- One workflow, not three. The fastest way to ruin an AI product is shipping two features that almost work. Pick the most painful, highest-frequency workflow your customers have. Build that one end-to-end before you build the second.

- End to end, not "the model part." Most failures aren't model failures. They're plumbing. Auth, identity, data freshness, retry logic, error states, observability. The model is one step in a ten-step pipeline. The other nine steps are what break in production.

- Human in the loop, not autonomous. Until you have eval data you'd bet on, the operator is the eval. Don't ship an autonomous agent before you've shipped the assisted version and watched a hundred real interactions. The "autonomous" version is the second milestone, not the first.

- Readable trace log, not opaque API. If you can't reconstruct what the model did, you can't debug it. You're just hoping. Every model call should produce a log a human can read, with inputs, intermediate steps, tool calls, and final output. Without it, you have a black box. With it, you have a product you can improve.

The successful AI projects share one pattern. They picked something small, made it bulletproof, then expanded scope. The stalled ones tried five agents, three tools, and a "platform" in week one. Same teams. Same models. Different sequencing.

Subtract. Then subtract again. The product that survives is the one that started small enough to actually finish.

---

## UX/UI Auditing: Tools and Best Practices

- URL: https://timurtek.com/blog/uxui-auditing
- Published: 2026-05-13
- Author: Timurtek
- Category: Founder Lessons
- Tags: Operator lessons

A UX/UI audit is a comprehensive review of a digital product's interface and experience to find issues and opportunities. Think of it as a health check, but only if you commit to acting on what you find. An audit without an action plan is theater.

The audits that produce value share three things. A clear scope. A diverse set of inputs. A team that's willing to fix what it finds. Drop any one of those, and you've spent two weeks producing a deck nobody implements.

## Auditing tools

### Heatmaps and session recordings

Heatmaps (Hotjar, Crazy Egg) show where users click, move, and scroll. You get visual insight into actual behavior, not imagined behavior. Session recordings let you watch real sessions, so you see how people interact with your product instead of how you assumed they would.

The pattern these tools surface most often is the gap between the "intended flow" and the "actual flow." Users hover over a button for three seconds before clicking, which means the label isn't clear. Users scroll past your hero CTA to read the next section, which means the section is more interesting than the CTA. Users rage-click on a non-interactive element because it looks clickable. None of these is obvious from a design review. All of them are obvious from a heatmap.

Watching a recording of a real user doing what your team built is one of the more humbling exercises in product work. Most teams come out of the first session with a backlog of small but high-impact fixes.

### User feedback tools

Direct user feedback is the highest-signal data you can collect. Tools like Usabilla and Qualaroo gather insight from the people actually using the product. Surveys and intercepts capture what surveys can capture. Sometimes you still need to call someone.

The trap with user feedback is over-indexing on what users say rather than what they do. The two diverge more than most teams expect. A user who says they want feature X often means "the existing solution is annoying in a way I can't articulate, and feature X sounds like it might help." Your job is to map the said-want back to the underlying friction and solve the friction, not the literal feature request.

The cleanest feedback signal is the one that comes unprompted. A churned user who emails support to explain why they left tells you more than ten survey responses. Build the channel that captures those unprompted signals before you optimize the surveys.

### Analytics

Analytics platforms (Google Analytics, Mixpanel, PostHog) give you behavior, traffic, conversion funnels, and drop-off points. Understanding these metrics is how you find rough edges worth fixing.

The trap is mistaking dashboards for action. Numbers diagnose. They don't prescribe. A 40% drop-off at step three of your onboarding indicates something is wrong there. It doesn't tell you what, and it doesn't tell you the fix. The number is the question. The user research is the answer.

The dashboards worth building are the ones where the metric directly maps to a user behavior you'd act on. Vanity metrics that go up and to the right without telling you why are worse than no metric at all. They produce confidence without insight.

### Accessibility tools

Accessibility is non-negotiable. WAVE and axe audit your product against accessibility standards and surface violations you can fix before they ship. Run them in CI. The cost of catching a contrast violation in code review is one minute. The cost of catching it after launch is months.

The argument for accessibility usually gets framed as compliance. The real argument is craft. An accessible product is more usable for everybody. Larger touch targets help thumbs. Higher contrast helps sunlight. Keyboard navigation helps the power user. Captions help the meeting room with the muted laptop. Accessibility done well isn't a tax on the design. It's the design at a higher standard.

## Best practices

### Set clear objectives

Before starting, define what you're trying to achieve. Conversion. Satisfaction. A specific usability issue. Clear objectives shape the audit and let you measure success. Vague objectives produce vague audits.

The objective also dictates the methods. Auditing for conversion is a different exercise from auditing for satisfaction. Auditing for usability of a single workflow is different from auditing for brand coherence across the whole product. Don't try to do all of them in one pass.

### Involve a cross-functional team

UX/UI audits aren't just for designers. Bring in engineers, product managers, and the marketing team. Each role surfaces different problems. Engineers spot the cost of a fix. PMs spot the impact on the roadmap. Marketing spots the brand drift. Customer support spots the support-ticket clusters that point back to specific UI failures.

The audit is also a forcing function for cross-team alignment. A finding that everyone agrees is important gets prioritized. A finding that one team cares about and others don't usually points to a deeper conversation that needs to happen before the fix.

### Prioritize ruthlessly

Not every finding is critical. Prioritize by impact on user experience, business goals, and feasibility. Most audits surface 30+ issues. The top five are where the leverage is. Ship those. The rest can wait.

Ranking is harder than identifying. The temptation is to fix the easy bugs first because they feel productive. The discipline is fixing the high-impact bugs first, even when they require a meatier rebuild. The post-audit roadmap should be ordered by user value, not by ease of execution.

### Build an action plan with owners and dates

Once issues are identified and prioritized, build a plan with owners and deadlines. Audits without action plans are theater. Repeat: theater.

Every finding should have a name, a fix proposal, and a target ship date. Findings without owners drift. Findings without ship dates drift faster. The clipboard with the bug list is not a plan. The PR with the fix is the plan.

### Iterate and re-audit

UX/UI work isn't one-and-done. Re-audit on a cadence to confirm changes worked and to catch new issues that surface as the product evolves. A quarterly audit cycle works for most products. A weekly micro-audit on the highest-traffic flows works for some. The cadence should match how fast the product changes.

## Applied to AI systems

The audit discipline carries over directly to AI products, and the gap is wider there than in traditional UIs.

Most AI features ship without ever being audited. The team builds the prompt, tests the prompt against examples the team wrote, and ships. Users hit the edges that no one anticipated. The feature gets quietly disabled six weeks later.

An AI audit is the same shape as a UI audit. Different tools.

- Eval harness instead of heatmap. What's the equivalent of "where did users click?" for an AI product? It's "what queries did the model get, and what did it produce?" Build an eval set from real production traffic. Score it. Watch the trends. Without an eval harness, you have no way to know whether a model upgrade improved things or quietly regressed them.

- Trace logs instead of session recordings. Every model call should produce a readable trace. Inputs, intermediate steps, tool calls, and final output. Watching a trace is the closest thing AI has to watching a session recording, and it's just as humbling. The first time you read traces from production, you usually find a class of failure your team didn't know existed.

- Refusal and hallucination rates, rather than accessibility violations. These are the AI-equivalent contrast errors. Surface them. Set a budget. Fix them before they ship. Hallucination rate isn't a vanity metric. It's the equivalent of a contrast violation: a baseline quality that the product fails to meet until you fix it.

- The same prioritization rule applies. Most audits surface dozens of model failure modes. The top five are where the work is. Ship fixes for those. The long tail is its own project.

The teams that audit their AI products the way mature design teams audit their UIs are the ones still shipping a year later. The teams that treat AI as un-auditable will spend that year explaining outages.

---

## Component-Driven UIs: Building Blocks of Modern Design

- URL: https://timurtek.com/blog/component-driven-uis
- Published: 2026-04-10
- Author: Timurtek
- Category: Tools & Stack
- Tags: design systems, components, architecture, AI systems

When a design team hands engineering a "page," something subtle goes wrong. The unit of thought is the screen, not the system. Two weeks later, the same button has three slightly different paddings in three places, and the bug tracker fills with edge cases that shouldn't exist.

Component-driven UI flipped that. You start from the smallest things (the button, the input, the token) and compose outward. Pages become the last thing you build, not the first.

## Why components work

Think of components like LEGO bricks. Each is standardized, interchangeable, and can be combined into whatever the project needs. By breaking complex interfaces into smaller reusable parts, the process becomes more manageable, more scalable, and more reliable. Each component is a tool designed for a specific job, and the same tool can be used across projects without having to be rebuilt every time.

This is about quality as much as convenience. When a component is built, tested, and refined in isolation, the final product is more robust. You can iterate on one piece without worrying about how the change ripples through everything else.

## How to start

The path into component-driven development begins with designing one element at a time. Don't rush to a finished page. Take time with each component. What does the button look like on hover, when disabled, when focused? How does a dropdown behave expanded versus collapsed? Answer those questions in isolation before composing the components into bigger pieces.

Once your core components are solid, you combine them into features and eventually full pages. The process is incremental: each part proven before it carries weight elsewhere in the system.

## What you get

- **Quality.** Building and testing components individually means the resulting UI handles edge cases without cracking. The product is polished because the pieces it's made from are polished.
- **Resilience.** Bugs are inevitable, but in a component-driven system they're easier to isolate and fix. Less time debugging, more time building.
- **Speed.** Reusability changes the math on every new project. Pull from your component library instead of starting from scratch, and development cycles shrink.
- **Collaboration.** When the UI is broken into discrete components, multiple people can work on different parts simultaneously without stepping on each other.

## The bigger picture

Component-driven development meshes naturally with adjacent practices like design systems, JAMStack, and agile delivery, all of which emphasize modularity, reusability, and rapid iteration. None of them are accidents. They're symptoms of an industry that learned, the hard way, that monolithic UI doesn't scale.

## Why this matters for AI systems

The same pattern is playing out right now in AI. Teams ship a single chatbot or a single agent and treat it as a feature. Then the second agent appears, then the third, and suddenly every prompt, every tool call, every eval harness is slightly different.

The fix is the same fix the design-systems generation already learned: pick your components. Your "button" is the tool. Your "input token" is the prompt template. Your "layout grid" is the evaluation harness that decides whether an answer is good enough to ship.

The teams that treat these as systems, not pages, are the ones who will still be shipping AI features in a year. The ones who treat them as one-off features will spend that year rewriting and wondering why.

Component thinking isn’t a design idea. It’s a systems idea. It just happened to show up on the design side first.

---