Product Engineering
I build software with a team of people and agents. I knew what to build because of the enterprise product work I did before AI: users want consistency and trust, and a team delivers both through shared systems. This page traces the line from one to the other, through the products it shipped.
John Hiemstra, product engineer & owner · Agentic SDLC
- 50% less UI dev time from a shared component library
- 5 months from Tailor's first commit to v1.0.0
- 15–20 min of host review per podcast episode, down from 4–5 hours of work
What does enterprise product work teach about building with agents?
That users want consistency and trust, and a team earns both with shared systems: one component library, one set of standards, and a process the team can trust, and trust to improve when it is found wrong.
I started in UX and UI in a world of C# engineers. Ad agency work came next, then enterprise HTML, CSS and JavaScript, user experience, client-facing research and application architecture.
Behind enterprise lines, I designed product workflows and built shared component libraries used by multiple applications; one of them cut UI development time by more than half. I shipped framework migrations on live products and built web apps intended for 500,000 concurrent users, and managed a $40M-a-year move from legacy to cloud with no customer disruption. That work taught me what to build, and when I didn't know, how to learn what we should be building: by working directly with clients and the people who use the product.
The system lives in code
On those teams the design system lived in strongly typed, reusable code, and Figma stayed a just-enough tool for working ideas through. The code was the contract the whole team built against. Now it is the contract the agents build against too.
Governance holds the bar
A shared library earned its keep through governance: private registry publishing, semantic versioning, deprecation, and a clear way to contribute. That is what held the quality bar as a team grew, and it holds the bar for an agent team the same way.
Why is one shared skill like one shared component?
Both save work the same way: write it once, use it everywhere, fix it in one place. A shared Button serves every screen that needs one, and a fix to it reaches all of them. A shared skill does the same for agents.
Each agent holds an active, bounded role, a node in the harness. Work moves along defined handoffs, the edges, and a gate sits on every handoff. A skill is written once and loaded by every role that needs it. When the document brand kit began formatting every HTML file before it renders to PDF, that one change reached the proposal, report and content-development writers and the carousel engine at once.
The team behind this site spans engineering, operations and the studio: product, frontend, backend, test, security, design, voice, editing, evidence and video among them. They share one policy file and one skill library, organized as one stream-aligned team on agile practices, after Team Topologies.
What did learning to work with agents look like?
Like leading a new team: small jobs first, every lesson written down as a rule, and more handed over as the rules held. I trained the agents on the human SDLC I've always run, the agile, stream-aligned principles I learned shipping software with teams of talented engineers and product people.
The agent team started at the end of April 2026, with Tailor, the platform this site runs on. In May it took on the post-production of our family wellness brand's podcast. Tailor shipped 1.0.0 on October 1, and in October the team cut hours of stage video into reels.
Each step up came with a failure that became a rule. An episode once finished its first phase titled “TBD,” so every phase now shares one title gate. A deploy check once misread its own output and took a live shop offline for thirteen minutes, so every check now prints evidence that it ran and what it read. The agents design, build, test and ship; I train and lead them with the benefit of my own successes, failures and lessons learned, and I decide what ships.
How do you keep AI output in a person's own voice?
Write the voice down as gates, and have a person read every quote before it publishes. The brand publishes a podcast, a science blog, and the social clips cut from both. Generative tools made each episode's reels, quote cards, titles and summaries fast to produce, and just as fast to get wrong: a placeholder title, a paraphrased quote, a claim with no source. Each one spends the guest's words and the brand's trust.
The decision
I didn't ban the tools, and I didn't trust free generation and hope a reviewer caught the drift. I wrote the standards down as gates: code that fails a run loudly before anything irreversible happens, such as a render, an upload or a schedule write, and a studio of role-specialized agents, each with a named checkpoint. A direct quote is never edited, only cut. A factual claim ships only with a source that says it. A person reads every quote before anything publishes.
The system
Each gate has one definition, and every phase that needs it calls the same one. A title that breaks a rule goes back to the model with the broken rule named; if the rewrite fails, code repairs it; if that fails, a plain title stands in. The run records every change, so the person reading sees what changed and why.
def assert_real_title(episode_title: str, episode_code: str) -> None:
"""RULE: never advance/render/ship an episode with a missing or placeholder
title. …
Fail loudly here instead — before the counter bump and schedule write."""
if not is_real_title(episode_title):
raise GateFailure(
f"{episode_code}: refusing to proceed — episode_title is "
f"missing/placeholder ({episode_title!r}). …"
)ensure() never fails a run. A heading that breaks a rule is fixed, in order:
1. the model rewrites it, told exactly which rule it broke (up to `tries` asks);
2. code repairs it: "&" to "and", the banned marks removed, or the title's own half before/after a colon or dash;
3. a plain title that always passes: "<first name> in Conversation", or "In Conversation".
Every change is recorded on the quote (`title_check`) and in the report, so the read shows what was changed and why.Adoption evidence
The pipeline runs on its own server and turns each episode into reels, quote cards, a blog draft and a show summary. Post-production went from four to five hours an episode to a fifteen to twenty minute review, for under $1 of model spend. Gates are added where a failure proves the need. The pipeline is public: github.com/jhcreative/podcast-pipeline.
What I'd do differently
Write the gates before the first run, not after the first failure. Most of the gates in this pipeline exist because something got past us once.
What does it take to ship a platform with an agent team?
A written canon, a gate on every handoff, and one person who owns scope and direction. Every custom site for a small business used to start from scratch. Each one rebuilt its own design system, and a lesson learned on one client stayed in that client's repo.
The decision
I built Tailor, a platform I own end to end: React 19 and React Router 7, server-rendered, on the front; FastAPI and Postgres behind; and a scaffold that generates a complete, independent site for each client. I passed on a hosted page builder, and on shipping client packages the client would have to patch later. The client's repo is entirely theirs. A lesson from any build becomes a Tailor release every site gets.
The system
A strictly typed component surface, governed by a written house UI canon of numbered rules: contrast, hit areas, five options at most in any menu, titles and actions that never scroll away. Decisions are recorded as architecture decision records, and work passes a local quality gate before it merges. I build it with Claude Code and role-specialized agents for product, frontend, backend, test, security and design. Each role works to the same written policies, and every handoff between roles passes a gate.
Adoption evidence
Three production sites run on it: this one, a client's site, and our family wellness brand's shop. Version 1.0.0 shipped on October 1, 2026, five months after the first commit.
What I'd do differently
Test the checks as hard as the code. A deploy check once misread its own output and reported a failure that wasn't there; the rollback it set off took a live shop offline for thirteen minutes. Every check now prints evidence that it ran and what it read.
How do hours of stage video become short reels?
Code runs the steps that must come out the same every time, agents run the steps that need judgment, and a person reviews at the cut and at the final render. One recording of a women's health summit ran 7.8 hours. It became 19 reel masters, and every one passed the publish gate before a person saw it.
The transcript and the formatting are code. The topic map, the cut list and the caption draft are agents. Every ruling a person makes goes into the edit list. The same pipeline cut 10 reels from a private event filmed on one fixed camera, and reels from talks at four stage events. See the reels on Content Curation.
How does one brand kit make every client document?
With one shared base and a skill per document type, not a template per document. John Hiemstra Creative produces branded client documents: proposals, reports, audits and presentations. Each one had to read as the practice's own work, not a template, without a production designer on staff to lay it out.
The decision
I built a shared base: one stylesheet, one component set, one pagination engine, and a skill per document type that carries its structure and voice. I passed on a page-layout tool, and on scale-to-fit. Content that doesn't fit flows onto the next sheet; it is never shrunk.
The system
common.css sets the US-Letter sheet, the masthead and the footer; components.css adds the shared blocks: stat rows, bars, figures, fail-and-fix tables. pack.py paginates, and the render scripts compose the sheets into a PDF. The proposal, report and content-development skills all stand on that base.
Adoption evidence
Proposals, reports and content-development documents all extend the same base without forking it. A line of ingredient references for the family wellness brand reuses the sheet geometry and the assembly script under its own brand sheet.
What I'd do differently
Write the voice rules alongside the layout rules. The pagination canon was set in July; the canon for how we present our own work came in October, after a long round of steering a draft from internal and self-congratulatory to sharp and useful to the reader.
Why are four publishing tools turning into one app?
Because each one was built on the same UI library, and that library is the one thing we set out to build. The HTML and PDF writer, the podcast pipeline and the reel cutter each started as a tool for one job, and the social scheduler as a design for one more. None of them was planned as part of a larger product.
What we did plan was one React UI library: about 70 React 19 primitives with their tokens, built in Tailor, so everything we make looks and behaves the same. Because every tool speaks that library, the tools can compose into one app, Curation: separate modules on one domain that hand work to each other through typed contracts, with no second design system.
That composition is a design today, decided in October 2026. The first slice comes next: the shell, a library and projects, with the review tray as the first shared panel.
What standards does every build meet?
Code
- TypeScript in strict mode
- UI composed from data and config, not one-off components
- Component conventions documented beside the code
- Shared components owned and versioned; no package a client is left to patch
- Releases tagged; significant decisions recorded
- A local quality gate before every merge: tests, a cold review, a security review
- Automated accessibility checks in the gate
- No dependency added without a recorded reason
Visual
- Type, spacing and color as tokens
- Spacing on a consistent base unit
- Semantic color tokens above the raw palette; light accents never carry text
- WCAG 2.2 AA contrast throughout
- Motion restrained, and switched off when a reader asks for reduced motion
- Print layouts designed, not left to the browser
- Five options at most in any menu; titles and actions never scroll away
Content
- Voice rules written per surface
- Every factual claim carries a source that says it
- A direct quote is never edited, only cut
- Content lives beside the code it describes
- AI output passes gates before a person reads it, and a person reads it before it ships
- Reviewer load is a design input
- Content changes versioned like code
Questions
Who made this, who it is for, and where to see the work running.
Who made this page?
I did, with the agent team it describes. It is a Tailor page, built from a template in this site's repo and published through Tailor's API.
Who is this page for?
Teams hiring for AI product, forward-deployed or product-engineering work, and businesses that want software built this way.
Where can I see live examples?
This site runs on Tailor. So does Rockstar Blends, our family wellness brand's shop. The brand's podcast, its posts and its reels come out of the pipeline on this page.
Do you consult?
Yes. Tailor Builds, Content Curation and AI Build Consulting are on the Services page.
Can I see the code?
The podcast pipeline is public at github.com/jhcreative/podcast-pipeline. The rest of my public work is at github.com/jhcreative.