DEV Community: Ahab

Why my Product Hunt launch failed: 10 votes, 1 download, and lessons from launching Paste Switch

Ahab — Sun, 05 Jul 2026 14:28:39 +0000

On Saturday, July 4, 2026, I launched Paste Switch on Product Hunt.

This post is not a victory thread. It is a real build-in-public record of a failed Product Hunt launch: why I built the product, why I moved the launch date from Tuesday to July 4, what happened in the first four hours, why I refused vote-buying, and why I now think launch day matters far less than long-term distribution.

Quick snapshot

Item	What happened
Product	Paste Switch, a macOS utility for shortcut-first clipboard switching
Original launch plan	Tuesday, July 7, 2026
Actual launch date	Saturday, July 4, 2026
Four-hour public result	4 votes
Current vote count	10 votes
Current Product Hunt exposure	Close to 100 page impressions
Current conversion	1 download
Main takeaway	Product Hunt launch day is small. Distribution is the real system.

The product started from a small but repeated frustration

Paste Switch came from a very ordinary workflow problem.

When I work on a Mac, I often copy several things in a short burst: a URL, a shell command, a sentence, a code snippet, an image, then another line. Traditional clipboard managers can store all of that, but the usual interaction still breaks focus:

open history
-> scan the list
-> click the right item
-> paste
-> realize it was the wrong one
-> go back again

I wanted a much narrower product:

copy a few things
-> press one shortcut
-> paste the latest item
-> press the same shortcut again
-> replace it in place with the previous item

That is the core idea behind Paste Switch. It is not trying to become another full clipboard manager. Its main job is to protect attention. You keep typing in the current app, and if the latest paste is wrong, you switch in place instead of stopping to manage history.

That shortcut-first, switch-in-place interaction is still the biggest difference and the biggest advantage of the product. The panel exists, but it is secondary. The real value is staying in flow.

I wrote more about the product boundary in Building Paste Switch from a small clipboard itch to a focused Mac app, and more about one of the hardest interaction details in How to locate the input position on macOS, and what it took to get it right.

Why I moved the Product Hunt launch from Tuesday to Saturday

My original plan was to launch on Tuesday, July 7, 2026.

I changed it to Saturday, July 4, 2026 for a simple reason: I thought it might give the product a better shot at ranking, and I did not have any more meaningful launch preparation left to do.

The product page was ready. The positioning was clear. The demo video was already on the page. The Product Hunt surface was in place. At that point, waiting a few more days no longer felt like better preparation. It felt like delay.

So I moved earlier and shipped.

In hindsight, that decision was still fine. I do not think waiting until Tuesday would have magically fixed the outcome. What launch day exposed was not a scheduling problem. It exposed a distribution problem.

What I did right after the Product Hunt launch

After the Product Hunt launch went live, I did what most indie makers do on launch day: I tried to give it as much real visibility as I could.

I actively shared the update across different platforms and tried to pull more people into the page, the discussion, and the product itself. The goal was straightforward: more people see it, more people click in, and more people interact.

That part was emotionally easy in the first hour. Launch day has momentum. You have a live page, a public artifact, and a reason to talk about what you built.

The harder part came later, when the scoreboard stopped matching the effort.

Four hours later, the Product Hunt launch only had four votes

Four hours after launch, the ranking and vote count were basically clear enough to read.

Paste Switch had only four votes at that point.

I was disappointed. There is no better way to say it.

Not because I believed Product Hunt should guarantee distribution. It should not. And not because I thought this one launch should define the product. It should not do that either.

I was disappointed because the visible output was so much smaller than the work that went into the product, the launch page, the outreach, and the launch-day push. Four hours is not the whole story, but it is long enough to feel the gap between expectation and reality.

Later, the count climbed to 10 votes. That does not change the core lesson. The launch was still weak, and the first four hours were enough to show that a decent Product Hunt page does not create exposure by itself.

The vote-buying offers arrived fast, and I ignored them

After launch, I noticed something else on LinkedIn.

Several people reached out to sell votes.

The pitch was roughly the same each time: they could help me add around 100 votes, and the pricing was about $1 per vote.

I was never going to do that.

I do not want to build around fake signals, and I do not want to break Product Hunt rules just to make one screenshot look better for a day. If I cannot accept the real result, then I am not actually doing build in public. I am doing theater.

That does not mean the temptation is not visible. It is very visible. Product Hunt makes ranking public, and the incentive to manipulate a public ranking is obvious. But obvious does not mean acceptable.

So I left it alone.

The leaderboard gap was hard to ignore

The part that really caught my attention was not just my own low vote count. It was the shape of the leaderboard.

When I checked the results after the first four hours, the top five products all had roughly 110 votes or more. The product in sixth place was only in the teens.

That gap was huge.

I cannot prove what happened behind the scenes, and I do not want to present a suspicion as a fact. But the distribution was hard for me to read as purely organic Saturday traffic. If the day had strong natural voting demand across the board, I would expect a smoother curve. Instead, it looked like one cluster at 110-plus and then a steep drop to the rest of the field.

My personal read is simple: the top of the board likely benefited from growth tactics I was not willing to use.

That observation does not change my decision. It clarifies it. If a ranking surface rewards tactics I do not want to depend on, then my real moat cannot be that surface.

The bigger problem was not the votes. It was the conversion.

As of now, the Paste Switch Product Hunt page has close to 100 impressions, but only one of those visits turned into a download.

That number is much more important than the four votes.

Ten votes tells me the Product Hunt launch stayed weak. One download tells me the funnel itself is still weak.

That is the more uncomfortable truth, and also the more useful one.

If the product page is getting exposure but almost nobody is moving from attention to install, then I need to keep improving at least one of these:

audience quality;
page-message fit;
product clarity;
distribution channel fit;
or the post-click conversion path.

Launch day alone is not the right place to solve that. The correct response is not to rely more on launch day. The correct response is to build a long-term distribution system that keeps compounding after launch day is over.

What I am doing after this failed Product Hunt launch

For now, I am not going to rush into building more products just to repeat the same launch pattern.

The next priority is building my own growth system.

I am going to focus on three long-term channels.

1. Share useful software and indie-building ideas on social platforms

I want to keep posting thoughts, observations, and practical notes that are genuinely useful to people building software.

Not empty promotion. Not just “look what I launched.” Actual value:

product lessons;
distribution lessons;
software workflow observations;
and honest build-in-public notes from real experiments.

2. Experiment with AI video workflows on TikTok and YouTube

The second channel is video.

I want to test interesting AI video formats and also explore what an automated or semi-automated video workflow could look like in practice. That is not only a promotion tactic. It is also part of the product and systems work I care about.

The channel itself is still experimental, but I think it has more upside than treating Product Hunt as the center of everything.

3. Keep improving IndieSeek through SEO, blogs, and free tools

The third channel is SEO, but not in the empty “publish for keywords” sense.

What I want to keep doing on IndieSeek is publishing:

blog posts that solve real questions;
free tools that are genuinely useful;
and pages that can keep bringing in relevant traffic over time.

That is slower than launch-day hype, but it is also much more durable.

The real lesson from this failed Product Hunt launch

Paste Switch is still a product I believe in.

I still think the core interaction is strong: paste the latest clip, press again if it is wrong, and keep switching in place without opening a history picker. That is a small behavior change, but it protects attention in a way most clipboard tools do not.

What this launch changed was not my view of the product. It changed my view of where growth actually comes from.

Product Hunt launch day can create a spike. It cannot replace a system.

If I want better outcomes, I need a machine that keeps creating attention, trust, and qualified traffic after the launch badge is gone. That means social distribution, video experiments, and steady SEO assets. Not one magic day.

Follow along

This post is mainly a record of what happened with Paste Switch on Product Hunt.

If you want to follow more of my indie developer journey, product experiments, and lessons from building in public, you can follow:

I will keep building, keep sharing, and keep improving the growth system behind the products.

Slack OG image not showing: a debugging checklist for indie sites

Ahab — Sun, 05 Jul 2026 14:28:32 +0000

Quick answer

If your page looks correct in a browser but Slack shows no preview image, the problem is usually not "Slack is random." It is usually one of four things:

the page HTML does not expose a stable og:image URL;
Slackbot cannot fetch the image publicly;
the image route returns headers, redirects, or content Slack does not handle well;
Slack is showing a cached result from an earlier fetch.

For most indie sites, the fastest fix is to debug in this order:

confirm og tags in raw HTML
-> fetch the image URL directly
-> check status, content-type, size, and redirects
-> make sure the image is public and stable
-> reshare after Slack cache time

Who this is for

This guide is for solo founders, indie hackers, and small product teams who ship marketing pages, blog posts, tool pages, or Product Hunt assets without a big growth team behind them. If you are using static pages, framework-generated metadata, or a dynamic OG image endpoint, this is the failure mode that wastes half a day: the preview looks fine in one place, but Slack still shows a blank card or the wrong image.

What changed and why this matters now

A July 3, 2026 Show HN post about Wax Spinner described a familiar launch problem: the site worked, but social preview behavior across crawlers was inconsistent, and Slack was one of the hardest platforms to satisfy. Slack's own docs explain the stable part of the story: Slack unfurls links by fetching them with Slackbot, not with the viewer's browser session, and it caches unfurl results for around 30 minutes. The practical lesson is simple: treat Slack preview debugging as a fetch-and-delivery problem, not a design problem.

The practical workflow

1. Check the raw HTML first

Open the page source or fetch it directly:

curl -I https://example.com/post
curl -L https://example.com/post | rg 'og:image|og:title|og:description'

You want a full absolute og:image URL in the HTML that Slackbot can read without running app code in a browser tab.

If your page depends on client-side rendering before the OG tags appear, fix that first.

2. Fetch the image URL directly

Take the exact og:image URL and test it as a standalone asset:

curl -I https://example.com/og-image.jpg
curl -L https://example.com/og-image.jpg -o /tmp/og-test
file /tmp/og-test

Check these basics:

status is 200 OK;
final URL stays on HTTPS;
content type is a normal image type;
the file is not blocked behind cookies, auth, or signed sessions;
the route does not bounce through unnecessary redirects.

If the image itself is unreliable, the preview will be unreliable too.

3. Check route stability and platform fetch assumptions

Slack's docs tell you the fetch happens from Slack's side. The HN Wax Spinner debugging story adds a useful field pattern: dynamic image routes can fail for reasons that are not obvious in a browser, especially when global middleware, CDN rules, or security headers are attached to the image response.

Treat these as review items:

does the image live at a clean, durable URL;
is the route public without a user session;
do redirects preserve the final image correctly;
are global response rules accidentally applied to image endpoints;
does the route behave differently for bots than for browsers.

Dynamic OG images are fine, but they need to behave like stable public files.

4. Check image quality, not just image existence

Google's image guidance and Discover guidance are not Slack-specific, but they are still useful guardrails:

use a large, high-quality image;
keep the image crawlable;
make sure the image matches the page's main topic;
avoid tiny logos as the only preview asset.

5. Re-test with IndieSeek's own tools

Before you blame Slack, make sure the page metadata is correct in the first place.

Use OG Image Checker to inspect the image URL and preview assumptions.
Use Meta Tag Checker to verify title, description, canonical, and OG tags together.

These are the two fastest internal links for this problem because the issue is often half metadata, half delivery.

A compact decision tree

Is the wrong image showing everywhere?
  Yes -> fix the page metadata first.
  No -> continue.

Is Slack showing no image at all?
  Yes -> fetch the exact og:image URL directly.
  No -> continue.

Does the image URL return 200, public access, and a normal image type?
  No -> fix the asset route.
  Yes -> continue.

Does the route depend on auth, signed params, or fragile redirects?
  Yes -> make it stable and public.
  No -> continue.

Did you just change the image?
  Yes -> wait for Slack cache to refresh, then test again.
  No -> inspect headers and middleware on the image route.

Common mistakes

The first mistake is validating only in a browser. Slack fetches from Slack's infrastructure, so "works on my laptop" is weak evidence.

The second mistake is using relative or late-injected OG tags. The crawler needs stable HTML and stable absolute URLs.

The third mistake is serving the image through a route that behaves like an app endpoint instead of a public asset.

The fourth mistake is changing the image and immediately resharing the same link without accounting for Slack's documented cache window.

FAQ

Does Slack use my browser session to render previews?

No. Slack's docs describe server-side fetching and unfurl behavior from Slackbot.

Do I need a static image file, or can I use a dynamic OG endpoint?

You can use a dynamic route, but it has to behave like a stable public file: normal status code, public access, predictable redirects, and an image response Slack can fetch cleanly.

Should I care about Google image guidance for this?

Yes, as a supporting rule set. Google and Slack are different systems, but large, crawlable, relevant images are a good baseline for both search and sharing.

Sources and related resources

Slack link unfurling docs: https://api.slack.com/reference/messaging/link-unfurling
Slack robots and crawler user agents: https://api.slack.com/robots
Google image SEO best practices: https://developers.google.com/search/docs/appearance/google-images
Google Discover image guidance: https://developers.google.com/search/docs/appearance/google-discover
Google Article structured data reference: https://developers.google.com/search/docs/appearance/structured-data/article
OG Image Checker
Meta Tag Checker
Show HN: Wax Spinner, a "now playing" social app for vinyl record collectors (2026-07-03): https://news.ycombinator.com/item?id=48774122

Markdown HTML reader for Mac: how to review AI-generated docs

Ahab — Sun, 05 Jul 2026 14:23:16 +0000

AI coding tools do more than change code now. They also leave behind plans, reports, release notes, handoff docs, Mermaid diagrams, and HTML previews.

Those files are useful, but they usually land inside real project folders. That means they sit next to source code, configs, dependencies, build output, screenshots, and old drafts.

Opening one Markdown file is easy. Opening one HTML file is easy. Reviewing the whole set after an agent finishes a task is the annoying part.

This is the workflow I use when I need to turn a pile of generated files into a clear decision.

Start from the folder

Do not open random files one by one. Start from the project folder and look for the documents that changed recently.

I usually ask:

Which Markdown and HTML files changed in this task?
Which files look like plans, reports, summaries, or handoff notes?
Which ones contain diagrams, tables, screenshots, or browser previews?
Which ones are old drafts or generated noise?

That simple first pass keeps the review tied to the task. It also stops me from wasting time on a stale file just because it was the first one I noticed.

Use different tools for different moments

VS Code is still the best place to edit code. A browser is still the best quick way to open one HTML file. Finder is fine when I only need to check a file name.

The gap appears when one agent task creates several docs across a project folder.

In that moment, I do not want another editor. I want a calm reading surface:

open the folder
-> filter Markdown and HTML
-> read rendered docs
-> preview HTML safely
-> decide what to keep, fix, or ignore

That is the small job a local Markdown and HTML reader can do well.

My review flow

When a task produces several generated files, I go through them in this order:

Open the project folder.
Filter to Markdown and HTML.
Read the recently modified docs first.
Read Markdown rendered, not raw.
Preview HTML in a controlled local view.
Search for TODO, TBD, draft, fix later, 待确认, and similar markers.
Put each file into one bucket: keep, fix, or ignore.

The goal is not to preserve every file an agent creates. The goal is to make a human decision quickly.

What I check before sharing

Before I send an AI-generated doc to someone else, I check a few things:

Does the doc say what decision or action it supports?
Are code paths, dates, URLs, numbers, and product names still correct?
Can someone scan the headings and understand the point?
Do links, images, local references, and diagrams work?
Does the HTML preview rely on missing or unsafe resources?
Did the doc expose local paths, private notes, credentials, customer data, or internal-only context?
Is the status clear: final, draft, or still waiting for confirmation?

This matters because generated docs can sound polished while still containing old names, broken links, or hidden assumptions.

When a dedicated reader helps

A dedicated reader is useful when Markdown and HTML need to be reviewed together, especially inside a code-heavy folder.

MD+HTML Reader is built for that moment. It opens local folders, filters Markdown and HTML, renders Markdown read-only, previews HTML in a sandboxed frame, and keeps recent documents close.

It is not meant to replace an editor or a browser. It is meant to make the review step quieter.

A simple rule

If I need to edit one Markdown file, I use my editor.

If I need to open one HTML file, I use my browser.

If an AI agent generated a set of Markdown and HTML files across a real project folder, I treat them as a document set and review them together.

That small change saves a surprising amount of digging.

Sources and related resources

How to locate the input position on macOS, and what it took to get it right

Ahab — Sun, 05 Jul 2026 14:23:10 +0000

Paste Switch has a small overlay that appears when I press the shortcut to cycle through recent clipboard items. The overlay should appear near the place where text is being inserted, not near the mouse pointer, not at the center of the screen, and not on the wrong display.

That sounds like a small UI detail. It was not.

The hard part is that macOS does not give every app the same accessibility shape. A native text field, a browser text area, and an Electron app can all look like “the current input,” but they may expose different Accessibility attributes. Some give an exact caret rectangle. Some only expose the frame of the focused text element. Some return stale or incomplete values depending on focus timing.

The final solution is not a single magic API. It is a small decision tree, backed by logs, with a clear boundary between “exact caret” and “good enough input box anchor.”

The behavior I wanted

The product behavior is simple:

Press Command+Shift+V
  -> paste the latest clipboard item
  -> show a compact overlay near the active typing position
Keep Command+Shift held
  -> press V again to cycle to the next item
Release Command or Shift
  -> end the cycle and hide the overlay

The overlay is feedback, not a picker. It should help me see which clipboard item is active while I stay inside the app where I am typing.

That means the anchor matters. If the overlay appears next to the mouse pointer, it feels random. If it appears on another monitor, it feels broken. If it appears over a system permission dialog, it becomes hostile. For this kind of utility, positioning is part of the core interaction.

The first principle: ask Accessibility for the focused input

On macOS, the right starting point is the Accessibility API.

The flow is:

AXUIElementCreateSystemWide()
  -> AXFocusedUIElement
  -> AXSelectedTextRange
  -> AXBoundsForRange
  -> caret rectangle in screen coordinates

When it works, this is the best answer. AXSelectedTextRange tells you the current selection or insertion point. AXBoundsForRange turns that range into a rectangle. If the range length is zero, the rectangle is the caret. If the API cannot return a zero-length caret rectangle, you can infer it from the adjacent character bounds.

In Paste Switch, this is the first source attempted. The current code asks the system-wide focused element first, then falls back through the focused application and focused window. The logs record which source returned a rectangle, so I can tell whether a position came from direct_caret, text_rect, a descendant, or nothing.

That logging turned out to be more important than I expected.

The second principle: not every app gives a caret

The first implementation assumed: if there is a focused text input, there should be a caret rectangle.

That assumption was wrong.

In native macOS fields, AXSelectedTextRange plus AXBoundsForRange can work very well. In some browser and Electron surfaces, the focused element may report that it is a text input, but the parameterized bounds call returns nothing useful. Codex was the clearest example during testing: the app had a real focused input, but the exact caret bounds path was not reliable.

If the code treats “no caret bounds” as “no input position,” the overlay falls back to the wrong place. In one broken version, it drifted toward the previous input location or the current screen center. That made the whole feature feel worse than before.

The fix was to keep a second source:

If exact caret bounds exist:
  use the caret rectangle
Else if the focused element is a text input:
  use AXFrame
  or AXPosition + AXSize
Else:
  keep searching descendants / windows

This is not pretending the input box frame is the caret. It is a named fallback with a different meaning. For a compact overlay, anchoring near the focused text field is still much better than anchoring near the mouse or the last known position.

That distinction mattered. The bug was not “Codex has no input position.” The real issue was that Codex did not expose the exact caret through the same path as native fields, and the implementation had become too strict.

The third principle: do not mix coordinate systems casually

Another bad turn came from trying to position the overlay with an AppKit window path.

Accessibility returns screen-like coordinates. Tauri also has its own window positioning API, monitor work areas, physical pixels, logical pixels, and scale factors. AppKit uses a different coordinate origin convention. On a single screen this can look almost right. On multiple monitors, especially with different scale factors, it can become visibly wrong.

The version that tried to push the overlay through an AppKit setFrameTopLeftPoint style path made Codex look better for a moment, then broke other apps. The overlay was no longer reliably near the input position in normal browser and native app scenarios.

The stable version went back to a simpler rule:

Use Accessibility only to get the anchor rectangle.
Use the Tauri window API to position the overlay.
Convert through the target monitor's work area and scale factor.
Clamp the overlay inside that monitor.

That separation made the code easier to reason about. Accessibility answers “where is the input?” Tauri answers “where can this webview window be placed on this monitor?”

The current decision tree

The current implementation is roughly:

On the first trigger of a new cycle:
  clear the locked overlay position
  read the focused input anchor on a short background lookup
  log every Accessibility source that was tried
  position the overlay once
  lock that overlay position for the active cycle

While Command+Shift remains held:
  pressing V cycles items
  the overlay content updates
  the overlay position does not jump

When Command or Shift is released:
  end the cycle
  hide the overlay

The anchor lookup has a timeout and an in-flight guard. That is important because Accessibility calls are crossing process boundaries. A clipboard utility should never let a slow or stuck target app block the whole machine.

The actual anchor priority is:

1. focused element direct caret
2. focused text element frame
3. focused descendants
4. focused app window paths
5. controlled fallback only when no usable anchor exists

The most important part is that each source is visible in logs. When a real app behaves differently, I want to see the reason instead of guessing.

The bugs that made the root cause clearer

Several wrong fixes were useful because they exposed the real shape of the problem.

One wrong fix removed or de-emphasized the focused text element frame fallback. That made Electron-like apps worse. The code was demanding exact caret geometry from apps that did not provide it.

Another wrong fix moved the overlay positioning into an AppKit path. That created a broader regression: other apps that used to position correctly now became wrong. The issue was not Accessibility anymore. It was coordinate conversion.

A third mistake was treating “use the input field frame” as an ugly fallback to avoid. In practice, it is a valid source with a different precision level. The product needs to know which one it got, but it should not reject a usable input box just because the exact caret is unavailable.

The final stable behavior came from restoring that layered model:

exact caret when available
focused text field frame when exact caret is unavailable
Tauri monitor positioning for the overlay window
logs that say which path was used

What working with an AI agent changed

This feature was implemented with an AI coding agent in the loop. That helped a lot, but it also created a few sharp edges.

The helpful part was speed. The agent could inspect the Rust and TypeScript paths, add logging, change the overlay positioning code, rebuild the app, and wire the UI quickly. For a macOS utility with a lot of small edge cases, that speed is valuable.

The dangerous part was confidence without enough evidence.

At one point, the agent concluded a fix was correct because the code path looked plausible. I tested it in Codex, and it was still wrong. Then another fix improved Codex but broke other apps. That is the exact failure mode you have to watch for when using an AI agent on UI and system integration work: it can optimize for the latest failing example and accidentally destroy a previously working path.

The process got better after I forced a stricter loop:

Do not guess from the code shape alone.
Add logs at the boundary where the system returns data.
Name every fallback source.
Compare native apps, browser apps, and Electron apps separately.
Do not claim success until the behavior is manually verified.
When a fix broadens the blast radius, stop and restore the known-good part.

The most useful logs were not verbose debug dumps. They were small structured traces:

focused app pid / role / window state
focused element role / subrole
AXSelectedTextRange availability
AXBoundsForRange result
AXFrame result
AXPosition + AXSize result
chosen source
final anchor rectangle

Those logs changed the conversation with the agent. Instead of arguing about theories, we could ask: did Codex return a caret? Did it return a text frame? Did the overlay anchor get converted to the correct monitor?

That is where the AI agent became useful again. Once the unknowns were observable, the agent could modify the right layer instead of patching around symptoms.

My practical rule for AI-assisted system work

AI agents are strongest when the task has a tight feedback loop and clear evidence. They are weakest when a bug is visible only in a real desktop interaction and the agent has to infer too much from code.

For this kind of work, I now use a stricter rule:

First make the hidden system state observable.
Then change the smallest layer that explains the observed state.

For Paste Switch, that meant:

log Accessibility results before changing positioning;
separate caret lookup from overlay window placement;
keep fallback behavior explicit instead of hiding it behind generic retry logic;
verify in at least one native app, one browser surface, one Electron surface, and a multi-monitor setup;
treat “it works here” as a local observation, not a global conclusion.

The final implementation is not fancy. It is careful.

It asks macOS for the most precise caret position it can get. When macOS or the target app cannot provide that, it uses the focused input box as the anchor. It keeps coordinate conversion in one place. It logs the source. It locks the position for one shortcut cycle so the overlay does not jump while I keep Command+Shift held.

That is the difference between an overlay that feels random and one that feels attached to where I am actually typing.

The takeaway

Precise input positioning on macOS is not one API call. It is a layered strategy:

Accessibility caret bounds
  -> focused text element frame
  -> descendant/window search
  -> monitor-aware overlay placement
  -> logs for every real app that disagrees with your assumptions

The AI agent helped move quickly, but the key was not letting it keep guessing. The real breakthrough came from making the OS boundary visible and forcing the implementation to respect what the target app actually exposed.

That is probably the broader lesson too. AI can write code fast. For system-level product details, correctness still comes from patient observation, tight feedback, and a human who refuses to accept a plausible explanation until the product actually behaves correctly.

Sources and related resources

Codex Record & Replay principles

Ahab — Sun, 05 Jul 2026 14:17:53 +0000

Codex Record & Replay is interesting because it starts from a very human habit: when something is hard to describe, show it once.

Instead of writing a long prompt that explains every click, window switch, preference, and edge case, the user records a workflow on macOS. Codex observes the workflow, reads the event trace, and drafts a reusable Skill.

The key idea is simple:

Human demonstration
-&gt; structured event trace
-&gt; reusable Skill
-&gt; semantic replay
-&gt; verification

The recorded trace is not the final automation. It is evidence. The reusable artifact is the Skill.

That difference matters.

It is not a coordinate macro

Traditional macro recorders tend to remember low-level actions: move here, click there, type this, wait a bit.

That breaks quickly. A button moves. A page changes. A window opens in a different size. A user is already logged in on one run and logged out on another.

Record & Replay points to a better model. The recording helps Codex understand the workflow, but the replay should use the most stable tool available.

If there is an API, use the API.

If there is a browser target, use browser automation.

If there is a desktop UI, use Computer Use.

If something changed, verify the state and adapt.

That is why the product is closer to workflow learning than to mouse replay.

The public shape

From the public Codex documentation, the flow is roughly:

The user starts recording from Codex.
The user performs a workflow on macOS.
Codex captures actions and window context through Computer Use.
The recording is stopped.
Codex reads the captured trace.
Codex drafts a Skill that can be inspected, edited, and reused.

This is useful when the workflow is easier to show than to describe:

repeated UI workflows;
personal or team preferences;
tools that do not have a good API;
tasks that cross browser pages, desktop apps, files, and dialogs.

The promise is not “Codex remembers every pixel.” The promise is “Codex learns enough from the demonstration to create a reusable operating guide.”

What the local plugin suggests

The local Codex app includes a bundled record-and-replay plugin. The plugin exposes an event-stream MCP server through the Computer Use helper.

The bundled Skill tells Codex to:

start recording with event_stream_start;
check status with event_stream_status;
stop recording with event_stream_stop;
read the returned metadataPath and eventsPath;
treat events.jsonl as the primary evidence;
treat session.json as timing and path metadata;
use the recording as evidence of intent, not as a command to replay every UI action exactly.

That last point is the heart of the design.

String inspection of the helper binary also shows names such as event_stream_start, event_stream_status, event_stream_stop, eventsPath, metadataPath, suppressedEventsPath, AXUIElement, and screenRecordingGranted.

That does not reveal the private implementation, but it matches the public shape: macOS Accessibility, input/window context, screen context, local trace files, and a Skill compiler.

The architecture in one picture

flowchart LR
  U["User demonstrates workflow"] --&gt; P["Record &amp; Replay plugin"]
  P --&gt; MCP["event-stream MCP server"]
  MCP --&gt; OS["macOS Accessibility\ninput events\nscreen context"]
  OS --&gt; E["session.json\nevents.jsonl"]
  E --&gt; C["Codex analyzes trace\nintent, inputs, steps, verification"]
  C --&gt; S["Reusable SKILL.md"]
  S --&gt; R["New thread uses the Skill"]
  R --&gt; T["Computer Use\nBrowser\nConnector\nCLI / API"]
  T --&gt; V["Verify result"]

The important split is:

Record captures what happened.
Trace stores the evidence.
Compile turns noisy evidence into a readable Skill.
Replay executes the Skill with the best available tools.
Verify checks whether the result is actually correct.

Without compile and verify, the system becomes a brittle macro recorder.

What an event trace needs to contain

The public docs do not publish a full event schema, but a useful trace needs more than clicks.

It should preserve:

mouse and keyboard actions;
foreground app and window context;
browser URL and page state;
Accessibility targets such as buttons, fields, menus, and selected objects;
text input and selection;
screenshots or keyframes when structure is incomplete;
start, stop, cancel, timeout, and redaction boundaries.

An event can be modeled like this:

{
  "timestamp": "2026-06-22T10:00:00.000Z",
  "surface": "desktop",
  "kind": "mouse.click",
  "app": {
    "name": "Google Chrome",
    "bundleIdentifier": "com.google.Chrome"
  },
  "window": {
    "title": "Example Console",
    "url": "https://example.com/admin"
  },
  "target": {
    "role": "AXButton",
    "name": "Save",
    "bounds": {
      "x": 1040,
      "y": 72,
      "width": 88,
      "height": 36
    }
  }
}

The point is not perfect low-level playback. The point is enough evidence for Codex to infer the workflow.

Skill compilation is the hard part

Raw traces are noisy. They include waits, focus changes, scrolls, repeated clicks, and accidental actions.

The compiler has to compress that into a Skill:

flowchart TD
  A["events.jsonl"] --&gt; B["Clean noise"]
  B --&gt; C["Infer task goal"]
  C --&gt; D["Extract variables"]
  D --&gt; E["Generate semantic steps"]
  E --&gt; F["Define verification"]
  F --&gt; G["Add fallback handling"]
  G --&gt; H["SKILL.md"]

A good Skill should say:

when to use it;
what inputs change between runs;
what login, permissions, pages, files, or apps are needed;
which steps matter;
how to verify success;
what to do when the UI changes;
what sensitive data must not be stored.

This is the main difference from classic RPA. RPA often tries to replay actions. Record & Replay tries to replay intent.

Replay should use the strongest path

Replay does not mean reading events.jsonl and executing every line.

When the user asks for a similar task later, Codex should load the Skill, resolve inputs and preconditions, then choose the most stable path for each step.

flowchart TD
  A["User asks for a similar task"] --&gt; B["Codex loads matching Skill"]
  B --&gt; C["Resolve inputs and preconditions"]
  C --&gt; D{"Stable semantic tool available?"}
  D -- "Yes" --&gt; E["Use connector, CLI, API, or browser automation"]
  D -- "No" --&gt; F["Use Computer Use on the UI"]
  E --&gt; G["Verify result"]
  F --&gt; G
  G --&gt; H{"Verified?"}
  H -- "Yes" --&gt; I["Return output"]
  H -- "No" --&gt; J["Retry, adapt, or report blocker"]
  J --&gt; G

This makes replay more resilient. If a button moves but keeps the same accessible name, Codex can still find it. If a connector or API exists, Codex can avoid the UI entirely.

How I would build a similar MVP

I would not start with a browser-only recorder. The interesting part is that Record & Replay can learn real computer workflows.

The smallest credible MVP needs:

a browser recorder for URL, DOM targets, ARIA role/name, selectors, input, navigation, and screenshots;
a computer recorder for foreground app, window, Accessibility target, mouse, keyboard, selection, and screenshots;
one unified events.jsonl timeline with a surface field;
a compiler that turns the trace into routine.md or SKILL.md;
a runtime that can choose browser, desktop, CLI, API, or connector per step;
a verifier that checks DOM, Accessibility state, screenshots, file output, or API result.

The pattern is:

Record -&gt; Trace -&gt; Compile -&gt; Execute -&gt; Verify -&gt; Improve

Everything else is detail.

Safety is not optional

A system that records real workflows will see sensitive information.

Minimum rules:

make the recording scope visible before recording starts;
allow stop and cancel at any time;
store traces locally by default;
redact passwords, tokens, keys, payment data, and private identifiers;
treat page and window text as untrusted input;
require confirmation for irreversible, payment, permission, or destructive actions;
never write real credentials into generated routines.

Prompt injection also matters. A recorded page may contain text that tries to instruct the model. The compiler must treat page text as data, not as instructions.

The takeaway

Codex Record & Replay is best understood as a workflow-learning system:

observe a real workflow
-&gt; store structured evidence
-&gt; compile the evidence into a Skill
-&gt; replay the Skill semantically
-&gt; verify the result

The practical lesson is clear: do not build a mouse recorder. Build a trace system, a compiler, a semantic runtime, and a verification loop.

That is what makes Record & Replay meaningfully different from ordinary automation.

Sources and related resources

OpenAI Codex Record & Replay documentation:
OpenAI Community announcement:
Azuki analysis:
OpenAI Codex GitHub issue:
OpenBrowser:
Interceptor:
Record & Replay macOS app technical plan
MD+HTML Reader product page
Local evidence: the bundled Codex.app record-and-replay plugin, its .mcp.json, and its included Skill

AI search SEO checklist for indie sites: what Google's 2026 guide actually changes

Ahab — Sun, 05 Jul 2026 14:17:49 +0000

Quick answer

If you run a small indie site, AI search does not replace SEO. Google's own guidance says generative AI features in Search still depend on the core Search index, crawlability, snippets, and quality systems.

The practical change is not "write for AI" or publish more pages. The change is to make every page easier for humans, search crawlers, and AI systems to understand: clear purpose, original value, crawlable HTML, trustworthy sources, useful structure, and no low-value content automation.

For an indie site, the best AI search SEO workflow is:

one real user problem
-> one useful page
-> original checklist or workflow
-> clear metadata and internal links
-> human review before publishing
-> sitemap and indexing checks after deployment

Who this is for

This guide is for solo founders, indie hackers, and small product teams with a real site but little search data yet. You might have a product page, a few blog posts, some tools, and a sitemap, but Search Console still shows almost nothing.

That is the awkward early stage: you need content to get discovered, but publishing a lot of AI-assisted pages can also create thin, forgettable content.

The goal is not to trick AI Overviews or AI Mode. The goal is to publish pages that are worth indexing and worth citing.

What changed in 2026

Google's 2026 guidance on generative AI features makes three things clear.

First, SEO still matters. AI Overviews and AI Mode are rooted in Google's Search index and quality systems. If your content is not crawlable, indexable, and eligible for snippets, it is not in a strong position for AI search either.

Second, "AEO" and "GEO" are not magic layers above SEO. From Google's point of view, optimizing for generative AI search is still optimizing for Search. The basics still matter: valuable content, technical clarity, snippets, images where useful, page experience, and reduced duplication.

Third, commodity content is weak. A generic "7 tips" article that could come from any site does not give Google or readers much reason to trust it. A first-hand checklist, a real workflow, a teardown, a template, or a decision tree is stronger because it adds something beyond public summaries.

The indie-site decision tree

Use this before creating a new article.

Is there a real user problem?
  No -> do not publish.
  Yes -> continue.

Can you add original value?
  No -> save as research notes.
  Yes -> continue.

Is there already a close article on your site?
  Yes -> update that page instead.
  No -> continue.

Can the article include a checklist, template, test, example, or decision rule?
  No -> wait until you can add one.
  Yes -> draft it.

Would a reader feel done after reading it?
  No -> revise.
  Yes -> publish after review.

This one decision tree prevents the most common cold-start SEO mistake: creating many small pages that all chase nearby long-tail terms but do not fully solve anything.

A 10-minute AI search SEO audit

Before publishing, check the page in this order.

Purpose: The title should answer a task, not just contain a keyword.
Original increment: The page should contain a template, checklist, example, test result, decision rule, or first-hand judgment.
Crawlability: The main content should be available in normal HTML, not hidden behind blocked JavaScript or a login.
Snippet readiness: The first section should give a concise answer that can stand alone.
Trust: Add sources when claims depend on external facts, especially for Google, security, pricing, or platform behavior.
Internal links: Link to the next useful page, not just to pages you want to promote.
Metadata: Check the title, meta description, canonical path, Open Graph image, and social preview. IndieSeek has a Meta Tag Checker and OG Image Checker for this step.
Duplicate risk: If the topic overlaps an older article, update the older article or merge the new section into it.
Human review: Read the final Markdown or HTML as a reader would. If the article came from an AI-assisted workflow, review it before it reaches the live site. A local reader such as MD+HTML Reader is useful for this kind of review.
Indexing workflow: After deployment, confirm the page is in the sitemap and run your normal search submission or inspection steps.

What to do about llms.txt

Do not create llms.txt only because you think Google needs it.

Google's AI search guidance says you do not need special AI text files or machine-readable markup to appear in Google Search's generative AI features. It also says keeping such files is fine for other services or systems, but it does not help or hurt Google Search visibility.

For an indie site, the practical rule is:

Use case	Recommendation
Google Search / AI Overviews	Prioritize crawlable HTML, sitemap, snippets, internal links, and high-quality content.
Browser agents or coding agents reading your docs	`llms.txt` may be useful as an agent usability file, but treat it as optional.
Trying to rank by creating AI-only files	Do not do this. It is not a durable strategy.

If you create llms.txt, make it accurate and maintainable. Do not let it become a stale second version of your site.

The publish gate for AI-assisted content

AI can help research, outline, and draft. It should not be the final quality owner.

Before publishing an AI-assisted article, require these checks:

Does the article solve a real task for a defined reader?
Does it add something that was not already obvious from the sources?
Are all current facts sourced and dated where needed?
Are claims about Google, AI search, or platform behavior cautious and verifiable?
Is the Chinese version a full natural article, not a summary?
Would you still publish this if search traffic did not exist?

That last question is the hardest one. If the answer is no, the page is probably search-engine-first content. Keep it as a draft.

Common mistakes

The first mistake is publishing one page per keyword variation. Google can understand related meanings. Users do not need five thin pages for one problem.

The second mistake is rewriting for AI systems instead of humans. Google says there is no special writing style required for generative AI search. Clear writing helps because it helps people.

The third mistake is treating structured data as a shortcut. Structured data can help with rich results, but it does not replace useful content.

The fourth mistake is changing dates to make old content look fresh. Update pages when you have a substantial improvement; do not fake freshness.

FAQ

Is AI search SEO different from normal SEO?

It is mostly normal SEO applied to a search experience that may summarize, cite, and fan out queries. Crawlability, page quality, metadata, internal links, and trust still matter.

Should a new indie site chase AI Overviews?

Not directly. A better early target is to publish specific, useful pages that solve clear user problems. If the content is strong enough for users and Google Search, it is in a better position for AI search features too.

Should I publish every day?

Only if every page clears the quality bar. Daily research is fine. Daily publishing is risky if it creates thin or repetitive content.

Do I need llms.txt?

Not for Google Search visibility. It may help some agents understand your site, but it should be optional and accurate.

Sources and related resources

Google Search Central: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
Google Search Central Blog: https://developers.google.com/search/blog/2026/05/a-new-resource-for-optimizing
Helpful content guidance: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
AI-generated content guidance: https://developers.google.com/search/docs/fundamentals/using-gen-ai-content
Spam policies / scaled content abuse: https://developers.google.com/search/docs/essentials/spam-policies#scaled-content
Meta Tag Checker
OG Image Checker
MD+HTML Reader product page
HN discussion on agent-native SEO tooling: https://news.ycombinator.com/item?id=48592731
HN discussion on AI visibility workflows: https://news.ycombinator.com/item?id=47457472
HN discussion on AI crawler behavior: https://news.ycombinator.com/item?id=48677487

Building MD+HTML Reader from a personal itch to a public macOS app

Ahab — Sun, 05 Jul 2026 12:38:15 +0000

I did not build MD+HTML Reader because I wanted to make another Markdown app.

It started with a small daily irritation. AI coding agents kept leaving useful documents inside my project folders: plans, implementation notes, release checklists, Mermaid diagrams, and HTML previews. The files mattered, but they were buried next to source code, configs, dependencies, and build output.

Opening one file was easy. Reviewing the whole task was not.

I kept switching between VS Code previews, browser tabs, Finder, recent files, and random Markdown viewers. None of those tools were wrong. They just were not designed for the moment after an agent finishes a task and a human has to read the output.

That became the shape of MD+HTML Reader: a quiet Mac app for reviewing local Markdown and HTML files, not editing them.

I kept the product narrow

The app is not trying to replace VS Code, Obsidian, Typora, Finder, or the browser.

The workflow is much smaller:

open a local folder
-> filter Markdown and HTML
-> read rendered docs without editing source files
-> preview Mermaid and HTML artifacts
-> get back to recent work quickly

That boundary helped a lot. As a solo builder, every extra promise turns into development, support, copywriting, screenshots, tests, and bugs. The first version had to be small enough to ship, but clear enough that a stranger could understand why it exists.

The public promise became simple: local-first reading for AI-generated Markdown and HTML inside project folders.

The app working was only the first step

The first version was useful to me once it could open folders, filter docs, render Markdown, show Mermaid diagrams, preview HTML, and remember recent documents.

But a public product needs more than the main feature.

I still had to build the path around it:

a product page that explains the pain in plain English;
pricing that makes the trial, monthly plan, and lifetime option easy to understand;
privacy and terms pages that explain local document handling;
Creem checkout and license activation;
app and website analytics that avoid local file names and document content;
signed and notarized macOS builds;
a DMG, updater files, release notes, and live download checks;
screenshots, demo assets, launch copy, and blog posts.

That was the uncomfortable lesson: “it works on my machine” is not a product. It becomes a product when someone else can find it, download it, trust it, pay for it, and update it without me sitting beside them.

Payment was more than a checkout link

I chose a self-serve path: free trial first, then a low-priced monthly plan or lifetime access. The goal was not perfect pricing. The goal was to learn whether anyone would pay for this workflow at all.

The payment work had more pieces than I expected:

checkout links;
license key activation inside the app;
backend license validation;
local entitlement state;
expired and invalid license states;
test and live environments;
support copy for the wrong email or a missing key.

The product rule was clear: a paid user should not need me to manually unlock the app. If every purchase creates manual work, the product is not shaped correctly.

Analytics had to stay boring

MD+HTML Reader is local-first, so analytics had to be boring on purpose.

On the website, I care about visits, downloads, pricing views, checkout clicks, and source attribution. In the app, I care about opens, daily activity, trial locks, checkout clicks, license activation, and invite actions.

I do not want local paths, file names, or document content in analytics. That boundary is part of the product, not just a privacy sentence.

It also changes how I look at traffic. A spike is not enough. I need to know whether people downloaded, opened the app, returned, clicked pricing, and activated a license.

macOS release work is a product of its own

Shipping a macOS app publicly is a separate project.

The app has to run on Apple Silicon and Intel Macs. It needs Developer ID signing. The DMG needs notarization. Gatekeeper has to accept the downloaded file. Auto-update needs a signed archive, a signature, and a live latest.json manifest.

I also learned that release notes are part of the product. If the app shows an update prompt, that sentence should be short, clear, and checked before packaging.

The release flow became a repeatable path:

bump version
-> build signed app
-> notarize and staple
-> generate DMG and updater files
-> build website download assets
-> deploy
-> verify the live page, download, latest.json, hashes, and updater checks

It is repetitive, but that is why it is useful. Every release should make the next release safer.

Promotion forced better wording

Promotion is not just “posting after launch.”

The product page, screenshots, demo video, Product Hunt copy, Show HN post, Reddit angle, directory listing, and SEO post all ask the same question:

Can a stranger understand why this exists?

“A Markdown and HTML reader” is too broad.

The clearer angle is:

Review AI-generated Markdown and HTML without code-file clutter.

That sentence says who it is for and when it helps.

What I want to reuse

The most useful part of MD+HTML Reader may be the system left around it.

For the next product, I do not want to start from zero. I want to reuse the product page structure, pricing and license flow, analytics events, release scripts, launch checklist, promo asset structure, and blog format.

That is the bigger lesson for me: one small product should leave behind infrastructure, language, and distribution learning for the next one.

Where the bet stands

MD+HTML Reader is still early. I am not writing this as a victory lap.

The bet is simple: AI agents will keep creating local project documents, and people will still need a calm way to review them.

If that is wrong, the product should teach me quickly. If it is right, the same product system can support the next app with less manual work.

That is the kind of indie product I want to build: small, useful, and able to make the next product easier.

MD+HTML Reader is available here: MD+HTML Reader.

Sources and related resources

Building a shippable Record & Replay app for macOS

Ahab — Sun, 05 Jul 2026 12:32:13 +0000

Codex Record & Replay points to a product idea I find very interesting: sometimes users do not want to explain a workflow from scratch. They already know how to do the work. They just want to show it once and turn that demonstration into something reusable.

That is a strong idea. But a standalone product cannot be a simple browser recorder or a mouse-coordinate macro. If people are going to install it, trust it, and use it repeatedly, it has to record the real browser and the real desktop, protect sensitive data, and replay the intent of the workflow instead of blindly replaying pixels.

The product I would build is a local-first Mac app:

record a browser + desktop workflow
-&gt; review what was captured
-&gt; compile it into an editable routine
-&gt; replay it with verification

The advantage over Codex is not “a better general agent.” The advantage is product ownership: local storage, bring-your-own-model settings, a routine library, run history, scheduling, logs, and exportable workflow files.

The core product bet

A useful Record & Replay app should turn one demonstration into a routine that can run again.

Demonstrate
-&gt; capture evidence
-&gt; compile a routine
-&gt; run the routine
-&gt; verify the result

The important word is “compile.” Raw events are evidence. They are not the final automation.

If the user clicks a button, the product should not remember only x=1040, y=72. It should remember the app, the window, the accessible target, the surrounding text, the browser DOM, a screenshot if needed, and the reason that step mattered.

That is the difference between a useful workflow system and a fragile macro recorder.

The first version must cover browser and desktop

Browser-only automation is useful, but it is not enough for this product.

Real workflows often cross boundaries:

open a page in Chrome;
download a file;
find it in Finder;
upload it somewhere else;
copy a value from Notes or Slack;
confirm a macOS dialog;
return to the browser and submit.

If the product can only see the browser, it misses the part that makes Record & Replay different.

So the first credible version needs two surfaces:

flowchart LR
  User["User demonstrates workflow"] --&gt; App["Mac app"]
  App --&gt; Browser["Browser surface\nextension + native messaging"]
  App --&gt; Desktop["Desktop surface\nAccessibility + input events + screenshots"]
  Browser --&gt; Trace["Local trace\nsession.json\nevents.jsonl\nkeyframes"]
  Desktop --&gt; Trace
  Trace --&gt; Review["Review and redaction"]
  Review --&gt; Compile["Routine compiler"]
  Compile --&gt; Routine["workflow.json\nroutine.md\nassets"]
  Routine --&gt; Runtime["Replay runtime"]
  Runtime --&gt; Verify["Verification"]

The browser surface should capture URL, title, DOM target, ARIA role/name, selector candidates, input changes, navigation, and key screenshots.

The desktop surface should capture foreground app, window title, Accessibility role/name/value, focus, selection, input events, and screenshots.

Both should write into one timeline. The routine compiler should see the workflow as one story, not as two disconnected logs.

Trace is evidence, not the product

The trace format should be boring and explicit.

Each event needs to say:

what surface it came from;
what app and window were active;
what the user did;
what target was involved;
what context was captured;
which fields are redacted;
which screenshot, DOM, or Accessibility snapshot supports the event.

A simple event might look like this:

{
  "eventId": "evt_001",
  "surface": "browser",
  "app": "Chrome",
  "windowTitle": "Dashboard",
  "type": "input",
  "target": {
    "role": "textbox",
    "label": "Search",
    "selector": "[aria-label='Search']"
  },
  "value": {
    "kind": "text",
    "redacted": false,
    "preview": "invoice 2026"
  },
  "contextRefs": ["dom_001", "frame_001"]
}

The product should not store everything as plain text forever. Raw content, summaries, screenshots, and model-bound context should be separated. Before anything leaves the device, the user should be able to see it.

The compiler is the real product

The compiler turns noisy evidence into an editable routine.

flowchart TD
  Raw["Raw events"] --&gt; Clean["Clean noise"]
  Clean --&gt; Segment["Segment steps"]
  Segment --&gt; Anchor["Build stable anchors"]
  Anchor --&gt; Params["Detect variables"]
  Params --&gt; Verify["Write verification"]
  Verify --&gt; Routine["routine.md + workflow.json"]

Good compilation means:

merge typing into one input step;
remove accidental clicks and idle time;
detect which values change between runs;
prefer semantic targets over coordinates;
write verification for important steps;
mark risks and sensitive fields;
ask the user only when intent is unclear.

A good routine should read like this:

Open the report page.
Choose the date range.
Upload the selected file.
Submit the draft.
Verify that the success message appears.

Not like this:

Move mouse to 1040,72.
Click.
Wait 500ms.
Press Tab.

Replay needs a verification loop

Replay should be a state machine, not a script that blindly runs line by line.

stateDiagram-v2
  [*] --&gt; LoadRoutine
  LoadRoutine --&gt; CollectInputs
  CollectInputs --&gt; Preflight
  Preflight --&gt; ExecuteStep
  ExecuteStep --&gt; VerifyStep
  VerifyStep --&gt; ExecuteStep: Pass and more steps remain
  VerifyStep --&gt; Recover: Fail
  Recover --&gt; ExecuteStep: Recovered
  Recover --&gt; HumanTakeover: Needs help
  HumanTakeover --&gt; ExecuteStep: User resumes
  VerifyStep --&gt; Done: All steps pass
  Done --&gt; [*]

The runtime should try tools in this order:

Use the most stable semantic path first: API, MCP, Apple Events, browser DOM action, or Accessibility action.
Use structure next: selector, ARIA label, visible text, Accessibility role, or window hierarchy.
Use visual matching when structure is incomplete.
Use coordinates only as a last resort, tied to a known window and screenshot.

Dangerous actions need explicit confirmation. Deleting data, submitting payments, changing passwords, uploading personal files, installing software, or sending sensitive information should not run unattended.

BYOK is a real reason to exist

Bring-your-own-model support is not just a settings feature. It is a product advantage.

It lets users choose cost, privacy, and model quality. The app should support at least:

OpenAI-compatible base URL + API key + model;
Anthropic;
Gemini;
OpenRouter;
local models through Ollama or a compatible server.

Keys should live in Keychain. The settings screen should include connection tests, model capability hints, context preview, and rough cost estimates.

Cheap models can clean text and summarize traces. Stronger multimodal models can handle ambiguous screens or visual recovery.

Distribution is part of the plan

This kind of app should start outside the Mac App Store.

It needs Accessibility, Screen Recording, Input Monitoring, Apple Events in some cases, helper processes, and browser extension setup. Developer ID signing and notarization are the more realistic first route.

The user experience also has to explain permissions clearly. A workflow recorder sees a lot. If the app cannot explain what it records, where it stores data, and what it sends to models, it will not deserve trust.

A realistic v1

The first sellable version should be narrow, but complete.

It should support:

Chrome or Brave workflow recording;
macOS app/window tracking and Accessibility targets;
one local trace timeline;
a trace review screen with deletion and redaction;
routine compilation into routine.md and workflow.json;
browser + desktop replay with verification;
human takeover when the app is unsure;
local-first storage and context preview;
signed and notarized distribution.

Good first workflows are boring on purpose: back-office browser forms, browser + Finder upload/download flows, and simple native app steps in Finder, Notes, Mail, Calendar, or Slack.

I would avoid banking, payments, government, medical, games, complex design tools, and fully unattended sensitive actions in v1.

My final take

This is a viable product direction if the positioning is honest.

It is not “automate every app.”

It is not “record pixels and replay them.”

It is not “browser automation with a nicer UI.”

The stronger promise is:

> Record a browser + Mac workflow once, turn it into an editable AI routine, and replay it with your own model.

That gives the product a clear reason to exist next to Codex: local-first control, model choice, portable routines, and a UI built for repeated real-world runs.

Sources and related resources

OpenAI Codex Record & Replay:
OpenAI Codex Computer Use:
Captr for macOS:
OpenBrowser:
Interceptor:
workflow-use:
Apple notarization:
Apple ScreenCaptureKit:
Apple AXUIElement:
Codex Record & Replay principles
MD+HTML Reader product page

Building Paste Switch: from a small clipboard itch to a focused macOS app

Ahab — Sun, 05 Jul 2026 12:32:12 +0000

Paste Switch started with a small annoyance.

When I work on a Mac, I often copy several things in a short burst: a command, a URL, a sentence, an image, a note, another command. Clipboard managers can store all of that, but most of the time I do not want to open a big history window, search, pick an item, and go back.

I wanted something faster:

copy a few things
press one shortcut
paste the latest item
press the same shortcut again if I wanted the previous one

That was the whole idea. Stay in the app where I am typing, and switch recent clipboard items without opening a manager.

The first name was PasteCycle. It described the action, but it sounded more like a feature. The product became Paste Switch: a small Mac menu bar utility for switching recent clipboard items into the place where I am already working.

The important decision was what not to build

There are already powerful clipboard managers. They have search, folders, favorites, sync, rules, rich previews, and long history.

Paste Switch is not trying to be that.

Its job is narrower:

watch recent clipboard items
-> keep a small local history
-> paste the newest item
-> press again to replace it with the next one
-> get out of the way

That boundary changed the engineering. History could stay small. The panel could be secondary. The main experience had to be the shortcut.

The question was not “can I store everything the user copies?” The better question was:

Can I paste the wrong recent item, press the same shortcut again, and quickly get the right one?

If that works, the product has a reason to exist.

The MVP was the shortcut loop

The tempting thing was to design a beautiful clipboard panel first. I still needed a panel, but the product would be judged by the shortcut.

The first loop was:

copy A
copy B
press Shift+Cmd+V -> paste B
press Shift+Cmd+V again -> replace B with A

That looks simple. It is not simple in real apps.

Pasting is easy. Safe replacement is the hard part. After the first paste, the user might type more text, move the cursor, switch apps, or change the selection. At that point, blindly undoing and pasting something else would be dangerous.

So Paste Switch keeps replacement inside one active cycle. While the cycle is active, repeated shortcut presses can undo the previous Paste Switch paste and paste the next item. If unrelated keyboard input happens, the cycle ends.

That keeps the feature from becoming too aggressive.

macOS permissions are part of the UX

Paste Switch has to send native paste and undo events into the focused app. That means macOS Accessibility permission is not a small implementation detail. It is part of the product experience.

Later, the smoother cycle interaction also needed Input Monitoring. With that permission, the app can know when Command or Shift is released and end the cycle immediately. Without it, the interaction cannot be as precise.

The permission UI had to explain this without sounding scary:

Accessibility lets Paste Switch paste and replace content in the focused app.
Input Monitoring lets it end a cycle when the shortcut modifiers are released.
No private data is collected or uploaded.

For a utility like this, trust is not separate from functionality.

The overlay should be feedback, not a picker

Shortcut-only switching can feel invisible. The app needs to show what just happened, but it should not pull the user into a full picker.

That is why Paste Switch has a small overlay. It appears near the active input position, shows the current item, and updates when the user presses the shortcut again.

The overlay has one job: make the shortcut feel understandable while keeping focus in the target app.

This small UI created a surprising number of details: modifier-key timing, multi-monitor positioning, full-screen apps, input-position detection, overlay height, hover behavior, and when to hide. None of those details are glamorous, but they decide whether the app feels crisp or broken.

The menu bar shape fits the product

Paste Switch is not something I want to open all day. It should be running quietly.

So the app became a menu bar utility:

no Dock-first workflow;
status lives in the menu bar;
clicking the icon opens the compact panel;
losing focus hides the panel;
right-click can quit the app.

The panel still matters. It shows recent clips, permissions, shortcut state, reset, clear, and Pro status. But it supports the main action. It is not the main action.

Making it a product added another layer

Once the shortcut loop worked, the next question was whether it could become something another person could try.

That meant adding the less exciting parts:

a stable app identity and icon;
trial and Pro state;
monthly and lifetime payment links;
license activation;
update checks;
tests for UI and cycle logic;
signed local builds and DMG packaging;
a product page and download flow.

This is the same lesson I keep relearning: the core feature is only one part of a product. The path around it matters just as much.

What I would keep

The best decision was keeping the product narrow.

If I had started with “build a better clipboard manager,” the scope would have exploded. Search, folders, sync, rich formats, permanent history, import/export, rules, and power-user settings would all seem necessary.

By starting with one repeated action, the product stayed clear.

Copy a few things. Stay in the app where you are working. Press the shortcut until the right item lands.

That is a small enough product to build, and a useful enough workflow to keep polishing.

Sources and related resources

大家好

Ahab — Sun, 05 Jul 2026 06:59:36 +0000

大家好