DEV Community: Johrdan Blaack

Teaching an assistant to publish on my behalf: three habits that kept it honest

Johrdan Blaack — Mon, 12 Oct 2026 10:25:47 +0000

I'm building Hartevo, an AI business assistant. This is a build log, not a launch post — no links and no pricing figures — and nothing here is a customer story. It was written with my own AI assistant, which I disclose again at the end.

The setup

I wanted an assistant that can do outbound work for me: publish a post, follow up, keep the loose ends visible. Business operators share the same load in different settings — cross-border, DTC and e-commerce businesses; developers and SaaS/B2B teams; studios and agencies working for several clients; business teams inside larger organisations. The work scatters across tools, and a chain like "customer feedback → triage → draft a reply → wait → follow up if nobody answers" usually breaks in the middle: the start happens, the end is forgotten.

Most of the interesting engineering turned out to be about restraint, not autonomy. Three habits made it safe enough for me to let it touch the outside world.

1. Separate system status messages from real user instructions

My assistant reports its own progress. Those reports are generated by the system, not typed by me. Early on, a generated status line — something like "cycle paused, waiting for input" — was read as if I had just said it. That misattribution blocked a real outbound action before it ever reached the platform, and it took a while to see, because from the outside it looked exactly like a permissions problem.

The fix was not "trust the assistant more". It was making the origin of every inbound message explicit, and validating control input against the real user channel. If you wire an agent into anything external, treat "where did this instruction come from?" as a first-class part of the design, not a detail you add later.

2. Reconcile before you retry

When an outcome is unknown — a timeout, a transport error, an internal refusal — the safe next move is not to send again. It is to go and look: does a receipt exist for this exact action, at this exact destination? I now keep "no receipt" and "unknown" as different states. A refusal that never reached the provider is not a delivery; an unverified send is not a success. The most embarrassing failure mode of an otherwise careful assistant is a duplicate post.

This is also the unglamorous part: I spent real time reading published channel rules before writing anything. One community explicitly forbids AI-generated content, so that channel ended immediately — I dropped it instead of disguising the authorship.

3. Act inside the scope you were already given

The rule I gave it: carry out the work inside the authorization you already have, and stop to ask only when an account, a required fact or new authority is genuinely missing — not for routine steps, and never to approve spending on my behalf. Without that rule you get one of two useless assistants: the one that asks for permission eleven times, or the one that improvises.

What was verified

Two publishing destinations are connected to this task under my own accounts. The existing account credentials were imported through Hartevo's protected, task-bound connection flow with engineering assistance; no credentials were pasted into chat.
The assistant then checked each account's identity with a read-only check before attempting to publish. A verified account is a precondition, not a publishing result.
The drafts stayed free of claims I cannot support: no customer stories, no invented metrics, no capability presented as shipped while it is still in development.

Being straight about status

I have no customer story I can cite here, and I am not claiming anyone acquired customers this way. Several capabilities are still in development or acceptance, and I won't present those as available. One more disclosure: this piece was written with my AI assistant, not by hand.

Three questions

When you let a tool act on your behalf, which failure worries you more — it doing too much, or it asking too often?
How do you currently tell "queued" apart from "actually happened"?
If you got a weekly list of "things you asked for that are still open", what should be on it?

Generative Engine Optimization for SaaS: How to Help ChatGPT, Perplexity, and Gemini Cite Your Product

Johrdan Blaack — Fri, 19 Jun 2026 08:25:12 +0000

AI answer engines are becoming a discovery channel for developer tools and SaaS products.

When someone asks:

“What are the best alternatives to X?”

“Which API monitoring tools support Y?”

“What SaaS products help with Z?”

…the answer may come from ChatGPT, Perplexity, Gemini, or another AI search experience instead of a traditional Google results page.

That creates a new technical problem for SaaS founders:

Can AI systems understand what your product does, when it is relevant, and why it should be cited?

This is often called GEO — Generative Engine Optimization — or AEO — Answer Engine Optimization.

This post is a practical checklist for making your SaaS easier for AI answer engines to discover, parse, and cite.

No magic tricks. No “prompt hacks.” Mostly good technical content, crawlability, structure, and measurement.

1. Make sure your important pages are crawlable

Before thinking about AI-specific files or structured data, check the basics.

AI answer engines commonly rely on a mix of:

their own crawlers
search indexes
third-party web data
documentation pages
comparison articles
community discussions
product metadata

If your core pages are blocked, thin, or hidden behind JavaScript-only rendering, you are making citation harder.

Check:

/robots.txt
/sitemap.xml
/docs
/pricing
/use-cases
/alternatives
/comparisons
/api-reference

Make sure pages that explain your product are not accidentally blocked:

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Also avoid putting all key product information inside client-rendered components that do not produce useful HTML on first load.

If your page source contains almost no semantic content, crawlers may struggle.

2. Create clear “what it is” pages

Many SaaS homepages are vague:

“The modern platform for scaling intelligent workflows.”

That may sound polished, but it is not especially useful to an AI answer engine trying to decide whether you belong in a product recommendation.

Create pages that answer concrete questions:

What does the product do?
Who is it for?
What categories does it belong to?
What integrations does it support?
What problems does it solve?
What are the alternatives?
What are the tradeoffs?

Example page types:

/use-cases/api-monitoring-for-startups
/use-cases/error-tracking-for-nodejs
/alternatives/product-name-alternative
/compare/product-a-vs-product-b
/docs/getting-started
/docs/integrations/github

For each page, use direct language:

# API monitoring for Node.js apps

AcmeMonitor helps Node.js teams track API uptime, latency, and error rates. It is designed for small SaaS teams that need alerts, dashboards, and webhook-based incident workflows without running their own monitoring stack.

This is much easier to parse than abstract brand language.

3. Add an `llms.txt` file

llms.txt is an emerging convention for giving AI systems a concise map of useful content on your site.

It is not a guaranteed ranking signal, and not every AI system will use it. But it is simple to add and can help clarify which pages matter.

A basic example:

# AcmeMonitor

AcmeMonitor is an API monitoring platform for SaaS teams. It helps developers monitor uptime, latency, error rates, and webhook reliability.

## Key pages

- Product overview: https://example.com/
- Pricing: https://example.com/pricing
- Documentation: https://example.com/docs
- API reference: https://example.com/docs/api
- GitHub integration: https://example.com/docs/integrations/github
- Alternatives: https://example.com/alternatives
- Comparison: https://example.com/compare/acmemonitor-vs-statuspage

## Best descriptions

Use this description when summarizing the product:

AcmeMonitor is an API monitoring tool for SaaS teams that tracks uptime, latency, error rates, and webhook failures.

Place it at:

https://example.com/llms.txt

Keep it short, factual, and updated.

4. Use structured docs and FAQ content

AI systems are good at extracting answers from well-structured pages.

A strong documentation page usually includes:

one clear topic per page
descriptive headings
examples
limitations
setup steps
integration details
FAQs

For example:

# GitHub integration

## What the integration does

The GitHub integration connects deployment events to API monitoring alerts so teams can correlate incidents with recent releases.

## Requirements

- GitHub account
- AcmeMonitor workspace
- Admin access to the repository

## Setup

1. Open Settings → Integrations.
2. Select GitHub.
3. Authorize repository access.
4. Choose which deployment events to track.

## FAQ

### Does the integration require repository write access?

No. The integration only reads deployment metadata.

This kind of page helps both humans and machines.

5. Add schema markup where appropriate

Schema markup will not magically make your SaaS appear in AI answers, but it can make your pages easier to classify.

Useful schema types for SaaS sites may include:

SoftwareApplication
Product
Organization
FAQPage
BreadcrumbList
Article
HowTo

Example JSON-LD for a SaaS product page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "AcmeMonitor",
  "applicationCategory": "DeveloperApplication",
  "operatingSystem": "Web",
  "description": "API monitoring software for SaaS teams that tracks uptime, latency, and error rates.",
  "url": "https://example.com/",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/pricing"
  }
}
</script>

Keep it accurate. Do not add fake ratings, reviews, or awards.

6. Create honest comparison and alternative pages

AI answer engines frequently respond to queries like:

“Best alternatives to X”
“X vs Y for startups”
“Open source alternatives to X”
“Best tools for [specific use case]”

If your product is a legitimate option, create pages that explain where it fits.

Good comparison content includes:

who each product is best for
supported features
pricing model overview
integrations
deployment model
limitations
migration notes

Avoid lazy pages that just say “we are better.”

A better structure:

# AcmeMonitor vs StatusPage

## Short version

AcmeMonitor is focused on developer-facing API monitoring. StatusPage is focused on public incident communication and status pages.

## Choose AcmeMonitor if...

- You need API uptime and latency monitoring
- You want alerts tied to endpoint failures
- Your team wants webhook monitoring

## Choose StatusPage if...

- You primarily need a public status page
- You need subscriber notifications for incidents
- You already use Atlassian workflows

This makes the page more useful and more citeable.

7. Build topical authority around real use cases

A single homepage is rarely enough.

If your SaaS serves multiple technical use cases, document each one clearly.

For example, a database monitoring product might publish pages for:

Postgres query performance monitoring
Slow query detection for SaaS apps
Database monitoring for Rails apps
Database monitoring for Node.js apps
Postgres monitoring alternatives
Managed database observability tools

The goal is not to mass-produce thin SEO pages.

The goal is to create useful, specific pages that show exactly where your product belongs.

8. Make your product easy to mention consistently

AI systems may see your product described in multiple places:

your homepage
docs
GitHub README
launch posts
comparison pages
directories
blog posts
community mentions

If each source describes the product differently, your positioning becomes fuzzy.

Create a short canonical description:

AcmeMonitor is an API monitoring platform for SaaS teams that tracks uptime, latency, error rates, and webhook failures.

Use variations of that across:

metadata descriptions
docs intro
GitHub README
llms.txt
social profiles
directory listings
launch announcements

Consistency helps classification.

9. Measure citation visibility

Traditional SEO tools measure rankings, impressions, and backlinks.

For GEO/AEO, you also want to measure whether AI answer engines actually mention or cite you.

You can track prompts such as:

What are the best tools for API monitoring?
What are the best alternatives to [competitor]?
Which SaaS tools help monitor webhook failures?
What developer tools help small SaaS teams track uptime?

For each prompt, record:

Was your product mentioned?
Was it cited with a source link?
Which competitors appeared?
What wording was used?
Which pages were cited?
Did the answer contain inaccuracies?

A simple spreadsheet works at first.

At Hartevo, we are building tooling to automate this kind of AI-search visibility tracking for indie devs and SaaS founders: https://hartevo.com

The basic principle is the same whether you use a tool or do it manually: measure your citation share of voice before trying to improve it.

10. Fix inaccuracies at the source

If AI answers describe your product incorrectly, look for the source of confusion.

Common causes:

outdated docs
old positioning on launch pages
unclear homepage copy
missing pricing details
stale comparison pages
ambiguous category labels
contradictory descriptions across directories

Fix the source pages first.

Then make the corrected information easy to find:

update docs
update metadata
update llms.txt
add FAQ answers
add changelog notes
update comparison pages

A practical GEO checklist for SaaS founders

Here is the condensed version:

[ ] Important pages are crawlable
[ ] Sitemap is available and current
[ ] Product category is clearly stated
[ ] Homepage explains what the product does in plain language
[ ] Docs are structured with clear headings
[ ] FAQ sections answer real buying/use-case questions
[ ] Schema markup is accurate
[ ] llms.txt exists and links to key pages
[ ] Alternative and comparison pages are honest and useful
[ ] Use-case pages cover specific technical problems
[ ] Product descriptions are consistent across the web
[ ] AI answer visibility is measured over time
[ ] Inaccuracies are corrected at the source

Final thought

GEO is not about tricking AI systems into recommending your product.

For SaaS founders, the practical version is:

make your product understandable,
make your best pages crawlable,
publish useful technical context,
structure your content clearly,
measure whether AI answer engines cite you.

That is a much better long-term strategy than chasing prompts or shortcuts.

Postiz pipeline smoke test 20260521-1804

Johrdan Blaack — Thu, 21 May 2026 10:10:32 +0000

Postiz pipeline smoke test 20260521-1804.

This short post verifies that the automation can create and publish a Dev.to entry from the local workflow.

How to Measure Whether AI Video Is Production-Ready: Cost per Usable Clip

Johrdan Blaack — Thu, 21 May 2026 07:40:01 +0000

AI video demos well. Production is where it gets messy.

The failure mode I keep seeing:

Team generates 50 short clips, 7 are usable, nobody tracks why the other 43 failed, and the next batch starts from scratch.

That is not just a model problem. It is a workflow and measurement problem.

If you are building an AI video pipeline for ads, ecommerce, social, product marketing, or creative ops, do not start with:

cost per generation

Start with:

cost per usable clip

That metric forces you to include retries, review, editing, failed generations, and brand/compliance overhead.

Cost per generation is the wrong production metric

A typical estimate looks like this:

duration_seconds × credits_per_second × price_per_credit

That is useful for API spend. It is not production cost.

A better metric:

cost per usable clip
= generation_cost_per_attempt × attempts_per_usable_clip
+ human_review_cost
+ editing_cost
+ compliance_or_brand_review_cost
+ storage / orchestration / tooling cost

Track these variables:

usable rate: what percentage of clips are publishable or close?
attempts per usable clip: how many generations produce one usable asset?
human minutes per usable clip: how much review/editing does each approved clip need?
rejection reasons: why are clips failing?

If you do not track those, you are guessing.

A simple 50-generation pilot

Assume a team tests 5–8 second AI B-roll clips for social.

Metric	Value
Total generations	50
Usable clips	8
Published clips	5
Total model/API cost	$30
Total human review time	180 min
Total editing time	120 min
Internal hourly cost	$60/hr

Calculations:

usable rate = 8 / 50 = 16%
attempts per usable clip = 50 / 8 = 6.25
review + editing = 300 min = 5 hours
human cost = 5 × $60 = $300
total pilot cost = $30 + $300 = $330
cost per usable clip = $330 / 8 = $41.25
cost per published clip = $330 / 5 = $66

That might be great if the alternative is a shoot, agency edit, or stock-footage workflow. It might be bad if your current process is faster and more reliable.

The point is not whether $66 is good or bad. The point is that you now have a number you can compare.

Log every attempt, not just the wins

You do not need a complex system at first. A spreadsheet, Airtable, Notion database, Postgres table, or JSONL file is enough.

Minimum fields:

Field	Why it matters
`brief_id`	Groups attempts by campaign/request
`prompt_id` / `prompt_version`	Compares prompt iterations
`model`	Compares vendors/models
`duration_seconds`	Helps calculate cost
`credits_used` / `generation_cost_usd`	Tracks API spend
`asset_url`	Links output to metadata
`status`	Drives workflow
`rejection_reason`	Shows where quality fails
`review_minutes`	Captures human cost
`editing_minutes`	Captures post-production cost
`published`	Separates usable from shipped

Example record:

{
  "id": "gen_00042",
  "brief_id": "bf_2025_001",
  "prompt_id": "pr_003",
  "prompt_version": "v2",
  "model": "video-model-a",
  "duration_seconds": 6,
  "credits_used": 42,
  "generation_cost_usd": 0.84,
  "asset_url": "s3://ai-video-pilots/bf_2025_001/gen_00042.mp4",
  "status": "rejected",
  "rejection_reason": "product_detail_wrong",
  "review_minutes": 3,
  "editing_minutes": 0,
  "published": false,
  "created_at": "2026-05-21T12:00:00Z"
}

Start with fields that answer:

How much did this cost?
How much human time did it require?
Why did outputs fail?
Which prompts/models are improving?

Use explicit review states

Do not let generated media go directly from model output to scheduled post.

Use states like:

draft_brief
→ prompt_ready
→ generated
→ review_pending
→ approved_for_edit
→ edited
→ brand_review
→ approved_to_publish
→ scheduled
→ published

Rejected paths should be explicit too:

review_pending → rejected_quality
review_pending → rejected_accuracy
review_pending → rejected_rights_risk
brand_review → rejected_brand_fit
brand_review → needs_revision

This matters because rejection reasons are one of the most valuable outputs of the pilot.

If most clips fail because of prompt ambiguity, fix the prompt template.

If most fail because of product accuracy, use AI video for background visuals or pre-production instead of exact product shots.

If most fail during compliance review, model cost is probably irrelevant. Your bottleneck is risk.

A copyable pilot workflow

brief template
→ prompt template
→ generation job
→ asset storage
→ metadata logging
→ human review UI
→ edit/caption step
→ approval state
→ scheduler/manual publish
→ performance notes
→ cost dashboard

Brief template

Keep briefs structured. Free-text briefs make runs hard to compare.

{
  "brief_id": "bf_2025_001",
  "channel": "instagram_reel",
  "format": "social_broll",
  "duration_seconds": 6,
  "goal": "support a post about summer product launch",
  "must_include": ["bright kitchen", "morning light", "refreshing mood"],
  "must_avoid": ["visible logos", "people drinking alcohol", "incorrect product packaging"],
  "risk_level": "low",
  "consistency_requirement": "low"
}

Prompt template

Version your prompts. They are part of the production system, not throwaway inputs.

Create a {{duration_seconds}} second {{format}} clip for {{channel}}.
Scene: {{scene}}.
Mood: {{mood}}.
Camera: {{camera_direction}}.
Must include: {{must_include}}.
Must avoid: {{must_avoid}}.
No text overlays. No logos. No recognizable public figures.

Generation job

Create a record before generation and update it after the asset exists.

async function runGenerationJob({ brief, prompt, model }) {
  const record = await db.generations.insert({
    brief_id: brief.id,
    prompt_id: prompt.id,
    prompt_version: prompt.version,
    model,
    status: "generation_started",
    created_at: new Date().toISOString()
  })

  try {
    const result = await videoProvider.generate({
      model,
      prompt: prompt.text,
      duration_seconds: brief.duration_seconds
    })

    const assetUrl = await storage.save(result.video)

    await db.generations.update(record.id, {
      status: "review_pending",
      asset_url: assetUrl,
      duration_seconds: result.duration_seconds,
      credits_used: result.credits_used,
      generation_cost_usd: result.cost_usd
    })
  } catch (err) {
    await db.generations.update(record.id, {
      status: "generation_failed",
      error_message: err.message
    })
  }
}

The provider does not matter for the pilot. The logging does.

Human review

Reviewers should not just click approve/reject. Make them choose a reason.

Useful rejection reasons:

artifact_or_distortion
product_detail_wrong
brand_mismatch
too_generic
prompt_not_followed
rights_or_likeness_risk
unsafe_or_policy_risk
needs_editing
other

This turns subjective review into data.

Cost dashboard

At the end of the pilot, calculate:

select
  count(*) as total_generations,
  sum(case when status in ('approved_to_publish', 'published') then 1 else 0 end) as usable_clips,
  sum(generation_cost_usd) as model_cost,
  sum(review_minutes) as review_minutes,
  sum(editing_minutes) as editing_minutes
from generations
where brief_id = 'bf_2025_001';

Then compute:

usable_rate = usable_clips / total_generations
attempts_per_usable_clip = total_generations / usable_clips
human_cost = ((review_minutes + editing_minutes) / 60) × hourly_rate
cost_per_usable_clip = (model_cost + human_cost) / usable_clips

That is the number to compare with your existing workflow.

Where humans should stay in the loop

Automate:

structured brief creation
prompt generation from approved templates
generation job creation
file naming and storage
metadata logging
review queue creation
caption/post copy drafts
reporting

Keep human approval for:

brand fit
product accuracy
claims and disclaimers
likeness rights
copyright/music concerns
trademarks/logos
platform ad policy risk
sensitive categories like health, finance, children, politics, or legal topics
final approval for paid campaigns

A good system increases throughput without turning publishing into an unreviewed media firehose.

Pick the right first use case

Evaluate AI video with two dimensions:

risk level
consistency requirement

Risk	Consistency needed	Suggested use
Low	Low	Good production test
Low	High	Drafts, variants, partial shots
High	Low	Strict human review only
High	High	Keep traditional production primary

Good early candidates:

social B-roll
ad hook variants
background visuals
storyboard previews
internal concept exploration
rough product scenario tests before a shoot

Use caution with:

exact product demos
regulated paid ads
real customer likenesses
recurring character stories
complex multi-shot narratives
brand hero films
anything where a small visual error creates legal or trust risk

A clip can look impressive and still be wrong for production.

The two-week pilot I would run

Keep it narrow:

format: social B-roll clips
clip length: 5–8 seconds
models: 1–2
prompt templates: 2–3
target: 50 generations
success metric: cost per usable clip vs current workflow

Rules:

Log every generation.
Force reviewers to choose rejection reasons.
Track review and editing minutes.
Separate “usable” from “published.”
Compare against a real current benchmark.

At the end, the answer should not be:

AI video is ready.

It should be:

For this format, on this channel, with this review process,
AI video costs $X per usable clip and meets / does not meet our quality bar.

That is a decision you can build on.

Final takeaway

AI video is production-ready when three things are true:

Cost per usable clip beats your current benchmark.
Quality clears the bar for the specific channel and risk level.
The workflow is repeatable without heroic manual effort.

Until then, treat AI video like an experiment with instrumentation.

The model output is only one part of the system. The production system is the logging, review states, human gates, and feedback loop around it.