DEV Community: Ian

An ad engine where AI writes only the plan, a desktop release lane that rehearses itself, and a QA stage that demands proof

Ian — Mon, 14 Sep 2026 18:00:00 +0000

This was a building week, not a migration week. The brand ports slowed down and a brand-new tool took most of the hours: an engine that turns a library of proven ad layouts into finished ads for any brand. Around it, the framework grew a desktop release lane, the agent workflow engine learned to ask for proof, and a VS Code extension stopped going quiet for an hour at a time.

Adforge: the AI writes the plan, scripts do everything else

Adforge is new this week. The pitch: a template is a wireframe with named slots and knobs, and it carries no brand. A brand kit is pulled from the live site with headless Chromium: exact colors, fonts, logo, and two screenshots. Merge the two and you get an ad.

The design rule I am happiest about: the plan is the ONLY AI step. One claude -p call reads the recipe, the brand kit, and the template library, and writes a single plan.json: which templates, what copy, which brand value lands in which slot. The plan is validated against the recipe and the library, retried once with the errors, then it throws. Everything after that is a script. Merge, render every size with Playwright, cut each ad to video with ffmpeg from the same page its PNG came from, build the review gallery.

Why it matters: the AI cannot break the layout. Brand values reach a template only as CSS custom properties, so one plan renders on-brand for any kit, and over-length copy or a missing slot fails loudly instead of producing a slightly wrong ad.

What the library holds after one week:

Sixteen templates across five families, including six "disguise" layouts that look like a note, a search result, a push notification, a social post, a meme, or an article card, with the brand's message sitting inside.
Seven sizes, from square feed to 9:16 story to 2:3 pin. A recipe that names no sizes gets the default three.
Five stock themes (classy, neobrutalist, mono, retro, pastel) that swap the whole color, font, and shape kit while the logo, images, and copy stay the brand's. Neobrutalist goes square with hard offset shadows; classy keeps a hairline and no lift.
Four campaign recipes. The ten-ad rounds hold the template and knobs still so the only thing being tested is the message: one ad per ad set, ten dollars a day, ten days.

The layouts come from a harvest of scouted Meta ads, transcribed once into wireframes and owned from then on. A failing ad no longer stops a run; it shows up in the gallery as a red card saying what was missing. And adforge results closes the loop: drop the ad account's numbers in, and every template gets a running score with the best hook it ever carried. No public site yet.

OMEGA: a desktop release lane that rehearses in a throwaway repo

OMEGA is the framework under every product I own. This week the desktop target got the release plumbing it was missing.

Desktop builds are the hard case because they must run on a Windows signing box inside GitHub Actions, and the framework repo is private. The answer is a rehearsal: one command renders the workflow, composes the brand's secrets the same way the push-secrets verb does, snapshots the working tree through a temporary index onto a rehearsal ref (no local branch, main untouched), force-pushes it to a private throwaway repo, and dispatches the run. The snapshot repo exists only so a public build never publishes framework source.

The public half is a -releases repo per brand: release artifacts plus the auto-update feed, managed by the desktop package. Assets carry versionless names from one catalog, so releases/latest/download/<asset> is a stable link and releasing a version never touches the website. A brand's source repo now derives as <brand.id>-omega, sitting beside <brand.id>-releases, and the release verbs read the repo from config, never from a git remote.

Two other pieces landed:

The seven @omega.js packages ship in lockstep: one version, exact pins in a brand's manifests, and a boot check that refuses to run on a drifted target and names the fix.
User connections got a rework. A provider is one context per step (identity, authorize, exchange, refresh, revoke, status), the route owns the already-connected check so reconnecting your own account works, and the account page's cards come from config alone. Twitch and Kick ship built in.

workkit: the QA stage demands proof

workkit is the engine that runs my Claude Code sessions against GitHub issues. It cut 0.51.0 with a rule I should have had from the start.

An issue parked at status:qa used to say "this is built, check it." Now a park comment must carry a Proof: line naming every test layer the change has a surface on: unit, integration, end to end, or why a layer was skipped. The verifier agent checks the layers, and the standards heal names every parked issue without the line. Eleven issues on my own dotfiles board failed that check the first time it ran, which is the point.

Alongside it: a checkpoint skill that applies a long chat to the board before compaction (every verdict, decision, and question filed or commented onto its issue, and a spoken pass flips the status), a Parity lens in the review skill that names each changed file's siblings and reports where the new code's shape differs, and one fixed shape for every question put to the human.

Claude Meters: a silent hour, fixed

Claude Meters is a VS Code extension that shows Claude usage in the status bar. After an account switch, the API answered with a 429 carrying a long Retry-After, and the extension obeyed it perfectly: it went silent for up to an hour, showing a bare "Claude" with no reason.

The fix in 1.4.10: backoff caps at ten minutes, a window inheriting the deadline from the shared cache reports it instead of hiding it, jitter stops N windows racing the same fetch, and the status bar reads "usage unavailable" with the reason in the tooltip. Plus the first unit tests for the status bar, through a vscode stub.

Small but satisfying

My Claude Code harness shipped 3.22.0: the footer patcher now mounts a context dial at runtime, a reaper job ends orphaned MCP router process trees every ten minutes, and keep-awake holds the Mac up until a scheduled wakeup fires.
Last week's post scheduled itself. The dev.to API reference does not document scheduling, but front matter with published: true and a future published_at works: the post stores as published with a future date, the public URL returns 404 until then, and the slug is assigned at once. This post is going out the same way.

Next week: the first adforge batch against a real ad account, and the desktop rehearsal producing a signed Windows build. If you have built a pipeline where the model writes a plan and code does the rest, I would like to know where you drew the line. Comments open.

Cover photo by Maranda Vandergriff on Unsplash.

Five more brands onto one framework, a board that knows when QA passed, and a stream panel that talks to OBS

Ian — Wed, 02 Sep 2026 18:00:00 +0000

This was a migration week. Last time I wrote about scaffolding nine brands from one template in an hour. This week the wave kept rolling: five more products moved onto the framework, and everything around it shipped too. The framework cut three releases, the agent workflow engine cut fifteen, and a new streaming tool got its first usable panel. Here is what got built and why I think it is cool.

Five more brands onto OMEGA

OMEGA is the framework I am building to run every product I own: one set of packages for the website, the backend, the desktop app, and the browser extension. This week Proxifly, Optiic, Soundgrail, Trusteroo, and StudyMonkey each got a fresh monorepo on it, and the ITW Creative Works site itself followed.

Every port is the same move, which is the whole point:

The legacy Jekyll site becomes the web target.
The legacy backend becomes the backend target.
The browser extension, where the product has one, becomes an extension target.
The old settings, spread across a dozen files per product, get translated into one omega.json5.

The "how it works" detail a dev reader wants: the migration is a config conversion, not a rewrite. The framework packages already know how to render a site, serve an API, and build an extension. A brand supplies the facts (name, domain, plans, colors, which features are on) and the packages do the rest. Optiic was the fun one: its legacy clone had fallen fifteen blog posts behind, and the port caught them all up because the new site reads the same content source as the old one.

Mid-week I renamed apps/ to targets/ across every brand repo and aligned the config and test lanes with the current framework. Boring on its own, but it means every brand now has the same shape, so a fix in one is a fix in all.

The framework itself shipped 0.47, 0.48, and 0.49 in three "board-clear" waves, each one landing a batch of issues across the web, backend, manager, and client packages.

workkit: the board learned what "QA passed" means

workkit is the engine that runs my Claude Code sessions against GitHub issues. Issues are the single source of truth; the agents' job is to keep them true. It went from 0.44 to 0.50.5 this week.

The feature that mattered most is small and embarrassing in hindsight. An issue used to move from building to qa, and the ship step read from qa. That one column meant two different things: "waiting for Ian to check this" and "Ian checked it, ship it." Every ship run had to ask which was which.

Now there is a status:complete stage. qa means the check is pending. complete means the owner passed it, with a dated comment saying so. Ship reads only from complete. The question went away, and the board grew a second region for side pockets (ideas, parked work) so the pipeline column stays honest.

Two other pieces landed alongside it:

A checkpoint skill. Before a long chat gets compacted, it applies the conversation to the board: every verdict, decision, and open question gets filed as a comment or a status flip on its issue. Nothing durable lives only in chat anymore.
Rate-limit hardening in the tower. The live dashboard now reads the GitHub GraphQL rate limit the way GitHub actually sends it, names the reset time when it trips, pages the board sweep, and reads up to 1,000 issues per query. Both dashboards share the same sweep.

It also now cuts a GitHub release on every version bump and moved to the Functional Source License.

StreamForge: switchboard got a panel

New project from last week, first real progress this week. StreamForge is my attempt to turn long working sessions into edited video without living in a timeline editor. Switchboard is the control side: it shipped 0.4 and 0.5.

The panel now has key-based auth, a local backend, an OBS setup card, and a one-line chat. The relay underneath it uses a bare OBS key, keeps its API on loopback ports only, and tears down cleanly even when spammed. The end-to-end test runs under its own compose project so it cannot collide with a dev instance.

The part I like: the panel's pages are built on the same framework as the brand sites above. A tool I built for myself runs on the same packages as the products I sell. No public site yet; when the first output is watchable, that will be the post.

A content generator that makes videos

A private repo called automated-content-generator hit 0.2.0 with one large landing: a strategy system, a news pipeline, video assembly through Remotion, and voiceover through Edge TTS.

The shape: pick a strategy (which brand, which angle, which format), pull the week's news through the pipeline, assemble the segments as a Remotion composition (React components rendered to video), and voice the script with Edge TTS. It is early. But the pieces now connect end to end, which is the part that usually takes longest.

Small but satisfying

ultimate-jekyll-manager 1.9.33 changed the build template to a shallow checkout plus an orphan gh-pages deploy. Every downstream site picked it up on its next build.
The streamer-mode VS Code extension hit 0.6.0 and replaced its webview lock screen with a click shield, which blocks input without repainting the editor.
The blog pipeline published about seventy posts across fourteen product sites this week, all through the same admin flow.

Next week: more brands over the line, and hopefully the first watchable output from the video side. If you have migrated a portfolio of products onto one framework, I would like to hear which product fought you hardest. Comments open.

Cover photo by Chintan Vadgama on Unsplash.

This week: payments in the framework, nine brands migrated in an hour, and the start of a video pipeline

Ian — Thu, 27 Aug 2026 22:49:46 +0000

This was a consolidation week. I run a bunch of small products under ITW Creative Works, and for years each one carried its own slightly different website, backend, and config. This week most of that duplication died.

OMEGA, the framework under everything

Most of the week went into OMEGA, the framework I'm building to run every brand: ten minor releases in seven days (0.29 → 0.43).

The headline pieces:

Payments, end to end. Checkout, billing UI, discount handling, and production gating now live in the framework. A brand turns payments on with config, not code.
One analytics contract. Every target (website, backend, desktop, extension) now reports events through a single typed contract. One definition, no per-app drift.
Lifecycle plumbing. A retention dialog, a winback flow, and offline mode, all shipped once and inherited by every brand.

The reason this is cool: fixing something in one product used to mean fixing it in ten places. Now every brand picks it up on its next update.

Nine brands, one template, one hour

The payoff moment. I scaffolded monorepos for nine brands, including StudyMonkey, Giftly, DashQR, Bink, Ghostii, Chatsy, Kirue, Clockii, and the ITW site itself, all from a single brand template, all within the same hour.

Migration was config conversion, not a rewrite: each legacy site and backend got ported onto the framework packages, and its old settings were translated into one omega.json5. The brands with the most legacy baggage took a few extra commits; the clean ones were nearly free.

StreamForge: the start of a video pipeline

New project. I want long working sessions to become edited videos without me living in a timeline editor. This week its first repo, cutroom, got a working recap pipeline: ingest the footage, render a longform cut, then frame shorts out of it with proper edge anchoring. A second repo, switchboard, is seeded and waiting. No public site yet; when the first output is watchable, that will be the post.

The agent workflow engine

My Claude Code workflow tooling (an engine I call workkit) went 0.41 → 0.47: a live board for every project's issues, stale-work alarms, and documentation-density enforcement. The idea it encodes: GitHub issues are the single source of truth, and the agents' job is to keep them true. It manages a small fleet of coding sessions across all the repos above.

Small but satisfying

Dotfiles shipped 3.20.4 and 3.21.0: a Chrome E2E teardown fix and pinning jq so hooks stop resolving to the system build.

Next week: first real output from the video pipeline, and the brand rollout continues. If you have gone through a many-products-one-framework consolidation, I would genuinely like to hear what broke for you. Comments open.

How 'me' became 'us'

Ian — Mon, 11 May 2020 23:51:23 +0000

Hi! I'm Ian and I build apps that help entrepreneurs succeed.

I started programming at age 12 with simple game development using a visual programming language known as MMF2. It taught me the basics but the language is juvenile compared to most others so I eventually graduated to Java where I honed my skills a bit more.

I built nothing of note until I picked up web technologies (JS, HTML, CSS) and eventually Node.js where I began building my first successful project Somiibo: a social media automation platform. Somiibo was launched on November 20th, 2017, and would change everything for me.

The project took off with tens of thousands of signups and a few thousand paying users in just the first few months. I decided it was time to get serious so I started a company called ITW Creative Works to act as the parent company to Somiibo as well as all future projects.

After that, our company began building a diverse set of apps and tools including:

SoundGrail: A toolkit for musicians and DJs
Slapform: A form backend for web developers
Proxifly: A free https proxy API
Socialetto: An influencer search engine and database

I now run the company as my full-time job and manage the development of all of the above projects. At our company, we are constantly innovating and creating new things that make the world a better place and we have so much fun doing it!

Thanks for taking a second to hear my story and I hope we inspire you to build something great too!