DEV Community: Łukasz Blania

Stop AI articles from hallucinating: retrieve, then write

Łukasz Blania — Tue, 02 Jun 2026 17:55:16 +0000

Last year a single fabricated statistic in a published article cost me a client's trust. The model wrote "73% of small businesses report X" with total confidence. The number did not exist. Nobody had ever measured it. The client found out before I did.

That one sentence taught me more than any prompt engineering thread ever did. I have since shipped 63,000 articles through a production pipeline, and the thing that moved quality the most was not a better model or a cleverer prompt. It was deciding that the model is not allowed to know anything it cannot cite.

This post is the pattern I use to get there. It works with any LLM and any framework.

TLDR

A language model writing from memory will invent facts that sound plausible. The fix is to retrieve real sources first, extract the facts you trust, and then force the model to write only against those facts. You build a small "fact context" per article and treat anything outside it as off-limits. I will show the three stages with code and the validation pass that catches what slips through.

The actual problem

People frame hallucination as a model defect. It is, partly. But in a content pipeline it is mostly an architecture choice.

When you send a prompt like "Write a 1500 word article about peptide bioavailability," you are asking the model to generate fluent text on a topic. Fluency is what it optimizes for. Truth is a side effect it reaches for from training data that may be old, averaged, or simply wrong for this specific claim.

The model has no signal telling it "you do not actually know this number, so do not state it." So it states it anyway, in the same confident voice it uses for things it does know. That confidence is the dangerous part. A reader cannot tell a real stat from an invented one by tone alone.

So the goal is not "make the model smarter." The goal is to remove its permission to free-associate facts.

Stage 1: Retrieve before you write

Before generating anything, gather real material about the topic. I pull from three source types because they fail in different ways:

A live web search for current facts and recent events
An encyclopedia source for stable entities and definitions
A synthesis source for harder questions that need reasoning across pages

Here is a trimmed version of the retrieval step.

async function gatherSources(topic, keywords) {
  const queries = [topic, ...keywords].slice(0, 5);

  const [web, encyclopedia, synthesis] = await Promise.all([
    braveSearch(queries.join(" ")),      // current facts
    wikipediaLookup(topic),              // stable entities
    perplexityAsk(`Key facts about ${topic} with sources`), // reasoning
  ]);

  return normalizeSources([...web, encyclopedia, ...synthesis]);
}

function normalizeSources(raw) {
  return raw
    .filter((s) => s.text && s.url)
    .map((s) => ({
      url: s.url,
      title: s.title || "",
      text: s.text.slice(0, 4000), // keep token budget sane
    }));
}

The output is a list of source objects, each with a URL and a chunk of real text. Nothing here is generated. It is all pulled from somewhere a human could go and verify.

Stage 2: Extract the facts you trust

Raw sources are noisy. The next step turns them into a short list of clean, attributed claims that the writer is allowed to use. I run this through the model too, but with a tight job: pull claims out, do not add any.

const EXTRACT_PROMPT = `
You are a fact extractor. From the SOURCES below, list atomic factual
claims relevant to the topic "{{topic}}".

Rules:
- Every claim must be supported by the source text. Do not infer.
- Attach the source url to each claim.
- If a claim includes a number, the number must appear in the source.
- Do not add background knowledge. Only what is in the sources.

Return JSON: [{ "claim": string, "url": string }]
`;

async function extractFacts(topic, sources) {
  const sourceBlock = sources
    .map((s, i) => `SOURCE ${i + 1} (${s.url}):\n${s.text}`)
    .join("\n\n");

  const res = await llm.json(EXTRACT_PROMPT
    .replace("{{topic}}", topic) + "\n\nSOURCES:\n" + sourceBlock);

  // drop anything the model failed to attribute
  return res.filter((f) => f.claim && f.url);
}

Now you have a fact sheet. Each item is a claim plus a URL. This is the only knowledge the writer gets to use. If a fact is not on this sheet, it does not go in the article.

The reason this works: extraction is a much easier task than generation. Asking "is this claim in the text in front of you" is close to a lookup. Asking "write a true article about X" is open-ended. Narrow tasks hallucinate far less.

Stage 3: Write against the facts, not from memory

Now generation. The prompt changes shape completely. Instead of "write about the topic," it becomes "write using only these approved facts."

const WRITE_PROMPT = `
Write a section titled "{{heading}}" for an article about "{{topic}}".

You may ONLY use facts from the APPROVED FACTS list below.
- Do not introduce statistics, dates, or named studies that are not listed.
- If you need a fact that is not approved, write around it without inventing one.
- Keep claims attributable. Prefer specific over vague.

APPROVED FACTS:
{{facts}}
`;

async function writeSection(topic, heading, facts) {
  const factList = facts
    .map((f) => `- ${f.claim} [${f.url}]`)
    .join("\n");

  return llm.text(WRITE_PROMPT
    .replace("{{topic}}", topic)
    .replace("{{heading}}", heading)
    .replace("{{facts}}", factList));
}

The model still writes fluent prose. It still controls phrasing, flow, and structure. What it lost is the ability to reach outside the fact sheet for a number that "feels right."

When the writer needs a statistic that is not approved, the instruction tells it to write around the gap instead of filling it with a guess. In practice this produces sentences like "peptide absorption varies with delivery method" instead of "peptide absorption improves by 4x with method Y," where the 4x was never real.

The validation pass that catches the rest

Constraints reduce hallucination. They do not zero it out. So I run a cheap check after generation: pull every number and named claim out of the draft and confirm each one traces back to a source.

async function validateDraft(draft, facts) {
  const claims = await extractClaimsFromDraft(draft); // numbers + named facts
  const approved = facts.map((f) => f.claim.toLowerCase());

  const unsupported = [];
  for (const c of claims) {
    const grounded = approved.some((a) => overlaps(a, c.text.toLowerCase()));
    if (!grounded) unsupported.push(c);
  }

  return {
    clean: unsupported.length === 0,
    unsupported, // flag these for a rewrite or human review
  };
}

Anything in unsupported is a claim the writer produced that the fact sheet does not back. You can route those to a rewrite of just that paragraph, or to a human. Either way, the fabricated stat never reaches publish without someone seeing it first.

This pass is where the client incident from the opening would have been caught. The fake "73%" would land in unsupported, because no source ever contained it.

A few things that made it better

Cap source text per chunk. Long sources blow your token budget and bury the useful lines. 4000 characters per source has been a fine ceiling for me.
Extract facts once, reuse across sections. Running extraction per section wastes calls and produces inconsistent fact sheets. One sheet per article keeps the whole piece consistent.
Keep URLs attached the whole way through. Even if you never render citations, carrying the URL lets validation and human review trace any claim back fast.
Prefer "write around the gap" over "omit the fact." Telling the model to omit makes it drop whole sentences. Telling it to write around the gap keeps the prose flowing while staying honest.
Log the unsupported claims over time. The patterns tell you which topics your sources are too thin on, which is a retrieval problem, not a writing one.

Reality check: when this is overkill

This pattern has real cost. Three retrieval calls, an extraction call, and a validation call sit on top of generation. That is latency and money per article. It is not free.

Skip it when the content is not factual. Personal essays, opinion pieces, brand storytelling, and creative copy do not have facts to ground. Forcing a fact sheet onto a founder's opinion post just makes it stiff.

Skip it when a human reviews every word anyway. If an editor fact-checks each article before it ships, the validation pass is redundant. The grounding still helps the first draft, but the full machinery earns its keep mostly at volume, where no human reads every line.

And be honest about the ceiling. Grounding stops the model from inventing facts. It does not check whether your sources are correct. Garbage sources produce confidently grounded garbage. The retrieval quality is now your real bottleneck, which is a better problem to have but still a problem.

Stack notes for the curious

The version I run in production uses Brave Search for live web results, Wikipedia for entities, and Perplexity for synthesis questions. The extraction and writing both run on a frontier model with JSON mode for the structured steps. Sections generate in parallel, then stitch, which is a separate pattern worth its own post. The fact sheet is the spine that keeps the parallel sections from contradicting each other.

I built this into Articfly (articfly.com) because at 63,000 articles across 9 retainer clients, one hallucinated stat per few hundred posts is still dozens of trust-breaking errors a year. The grounding layer is the difference between a tool a client can rely on and a toy that writes pretty lies.

Back to that client

The article that cost me trust was fluent, well-structured, and wrong in exactly one sentence. That is the trap. Fluency hides the error. The reader trusts the tone.

Retrieve-then-write does not make the model smarter. It changes what the model is allowed to claim. Once a fact has to exist in a real source before it can appear in the draft, the most damaging failure mode mostly goes away.

If you are shipping AI content at any volume, what is your actual process for catching a fabricated fact before it goes live, or are you still trusting the tone?

The dead internet theory is half right

Łukasz Blania — Mon, 25 May 2026 16:34:43 +0000

Last year I built a tool that has now shipped 50,000 AI-written articles for paying customers. So when developers post the dead internet theory on Twitter, I am one of the people being accused of killing the web.

After a year of watching how real users actually use the thing (logs, edit patterns, traffic, conversions), I have to admit it: half of the dead internet panic is correct. The other half is a vibes-based moral panic that does not survive contact with data.

This post is the engineering view. The patterns that produce slop versus the patterns that produce content people actually finish reading. With code.

TLDR

AI content farms got worse. That part of the dead internet theory is real.
But "AI content" and "AI-assisted content" produce different traffic, conversion, and decay curves. The panic blurs them.
The technical pattern that separates the two is not which model you use. It is whether you generate as one monolithic prompt or as a chained pipeline with per-section briefs, voice constraints, and fact pinning.
I will show the difference with actual prompt code below.

Where the dead internet theory is right

Before GPT-3.5, a content farm needed five cheap writers on Upwork. Now it needs one prompt and a CMS.

The volume of low-effort AI text on the open web has roughly 10x'd since November 2022. Google search results page 1 for low-intent queries ("best CRM 2025", "how to drink water", "is X a good idea") is now mostly garbage. Comment sections on big-traffic sites trend 30 to 50 percent bots talking to bots. LinkedIn is a hallucinated thought-leader loop. Reddit is laundering generated content as personal stories.

I do not pretend my tool has nothing to do with this. In the hands of someone who clicks generate, picks the cheapest title, and publishes without reading, my product is part of the problem.

That is not the full picture though.

Where the dead internet theory is wrong

The panic treats every AI-written word as identical garbage. From my logs across 50,000 published articles, that is not what happens.

70 percent of articles get manual edits before publish. People rewrite intros, fix specific claims, swap headlines, add personal context.
The top 20 percent of accounts (by retention and traffic) edit harder than they generate. They use the tool for a 60 percent draft and then spend 45 to 90 minutes on the post.
The 10 percent who publish raw also see the worst traffic. Google demoted that layer in the September 2024 helpful content update and never undid it.

The internet that pays (places where someone buys something, signs up, or hires you) does not run on raw AI slop. It runs on AI as a draft layer plus a human who knows what they are saying.

The actual technical difference

Here is the part nobody outside the AI writing tools space talks about. There is a difference between AI content and AI-assisted content, and it is not vibes. It is a prompt architecture difference.

The slop pattern: monolithic prompt

This is what the dead internet theory is mostly worried about. It looks like this:

async function generateSlop(topic: string, wordCount = 2000): Promise<string> {
  const prompt = `Write a ${wordCount} word article about ${topic}.
Include an introduction, 5 sections, and a conclusion.
Use SEO best practices. Make it engaging.`;

  const response = await client.messages.create({
    model: "claude-3-5-sonnet",
    max_tokens: 4096,
    messages: [{ role: "user", content: prompt }],
  });
  return response.content[0].text;
}

This produces output that is technically grammatical English and technically about the topic. It also produces output that:

Drifts off topic between section 3 and section 5 because the model loses attention on long generations.
Repeats the same generic claims across all sections (it has no shared brief to constrain it).
Includes hallucinated statistics ("studies show 73 percent of users prefer X").
Reads identically across topics because the prompt has no voice constraints.
Cannot be updated without regenerating the entire article.

This is the slop the dead internet panic is rightly angry about. It floods low-intent SERPs. It does not convert. It does not retain readers. It does not build a brand.

The useful pattern: per-section briefs

Same model, same goal, but a chained pipeline with shared state. This is what actually works.

type ArticleBrief = {
  topic: string;
  targetKeyword: string;
  audience: string;
  voiceExamples: string[];
  factualAnchors: string[];
  forbiddenTerms: string[];
};

type SectionBrief = {
  heading: string;
  purpose: string;
  keyPoints: string[];
  targetWords: number;
};

async function generateOutline(brief: ArticleBrief): Promise<SectionBrief[]> {
  const outlinePrompt = buildOutlinePrompt(brief);
  const raw = await callModel(outlinePrompt, { maxTokens: 2000 });
  return parseSections(raw);
}

async function generateSection(
  brief: ArticleBrief,
  section: SectionBrief,
): Promise<string> {
  const prompt = `Write the section "${section.heading}" only.
Target length: ${section.targetWords} words.

Purpose: ${section.purpose}
Key points to cover: ${section.keyPoints.join(", ")}

Voice constraints. Match the rhythm and vocabulary of these samples:
${formatVoiceExamples(brief.voiceExamples)}

Factual anchors. You must cite these or stay silent on the topic:
${formatAnchors(brief.factualAnchors)}

Forbidden terms (rewrite if any appear): ${brief.forbiddenTerms.join(", ")}
`;
  return callModel(prompt, { maxTokens: section.targetWords * 4 });
}

async function generateArticle(brief: ArticleBrief): Promise<string> {
  const sections = await generateOutline(brief);
  const bodies = await Promise.all(
    sections.map((s) => generateSection(brief, s)),
  );
  return stitch(bodies);
}

What this changes:

Each section gets focused attention because it is a separate model call with a tight word budget.
The article brief is shared state, so every section knows the voice, the anchors, the banned words.
The outline step forces a top-down structure before any prose exists.
You can regenerate one section without trashing the rest.
Hallucinations drop sharply because the model is constrained to factual anchors.

I built this because I had to. The first version of my pipeline used a monolithic prompt. Customer retention was bad. Traffic was bad. Edit rate was high enough that users complained the tool was not useful. The second version (per-section briefs with shared state) is what 50,000 articles have shipped through.

Why this matters for the dead internet theory

The monolithic pattern produces dead-internet content. The chained pattern produces something closer to a junior writer's first draft. Both use the same underlying model. The technical architecture is what separates them.

When people post the dead internet theory, they are usually reacting to monolithic-prompt output. That is the genre of content that floods low-quality SERPs. They are not usually reacting to chained-pipeline output, because chained-pipeline output gets edited by a human before publish and looks like normal modern writing.

Reality Check (when the dead internet panic IS right)

I am not arguing AI writing is fine. There are categories where it absolutely is the problem.

Pure SEO content farms. No human in the loop, no editing, hundreds of articles per week. This is dead internet content even with a chained pipeline. Volume kills value.
Astroturf comments. Generated forum posts pretending to be a real user with a story. This is unambiguously bad and the panic is correct.
Hallucinated expert content. AI-written medical, legal, financial advice with no human review. The technical pipeline does not save you here. You need a domain expert.
AI-on-AI loops. SEO content scraping other SEO content, scoring AI against AI. Eventually the entire signal degrades because nothing in the loop is grounded in reality.

If you are doing any of these, the dead internet theory is your fault and you should stop. My own product has terms against the first two.

The complaint that gets it wrong is the version that says "any AI-written word is killing the web". A human using a per-section pipeline to skip the empty first draft is not the same person running a content farm. The data is not the same. The output is not the same.

What I actually tell customers

Three rules. I repeat them on every onboarding call.

The AI does the first draft. You do the last 30 percent. Always.
Specific numbers, named people, and personal context are the parts AI cannot fake. Put them in the post yourself.
If your edit rate is below 30 percent, you are about to get demoted by the next Google update. Bring it up.

This is also why I do not market my product as "10x content output" or "AI articles on autopilot". Both of those framings produce the bad version of customer behavior. I market it as a draft layer.

So is the internet dead

The cheap layer of it got cheaper, faster, and more annoying. That layer was already empty calories before AI. Now there is more of it.

The parts that pay (specific expertise, real numbers, named people, brand voice, technical depth) are harder to fake. That layer still rewards humans who write things only they can write.

The dead internet theory describes the empty-calories layer of the internet. It does not describe the entire internet, even though the panic says it does. Both of these can be true at the same time:

AI writing tools have polluted low-intent SERPs.
AI writing tools, used with a real pipeline and a real human, are a draft layer that helps writers ship more of the work they are already capable of.

If you are building anything in this space, the architecture you ship determines which side of that line your product lands on.

If you are publishing content, your edit rate determines the same thing.

What is your edit rate when you use AI for a draft? Be honest. And if you have shipped a chained-pipeline architecture that works better than per-section briefs, I want to hear about it.

Anatomy of a form POST: 9 things that fire before your inbox pings

Łukasz Blania — Thu, 21 May 2026 11:04:26 +0000

Last March I spent forty minutes tracing one POST request through my own form backend and found three bugs along the way. The request looked simple from the outside. HTML form, action attribute, submit button, email lands. From the inside it was nine separate operations firing in sequence and parallel, with four ways to silently lose the submission and one race condition I had shipped to production without noticing.

This is the walkthrough I wish I had when I started. If you are building anything that takes user input over HTTP (contact forms, signup flows, file uploads, lead capture), most of the work happens in places you cannot see until something breaks. Here is everything that runs between the browser hitting Submit and the form owner getting an email, in execution order, with the code patterns and the failure modes for each step.

TLDR

A modern form backend is not a single endpoint. It is a pipeline of nine stages: rate limit, automation fingerprint, multipart parsing with magic-byte validation, honeypot, optional CAPTCHA, adaptive spam heuristics, database insert, async email notification, and async fanout to webhooks plus chat integrations. Some run sync on the hot path. Most should not. The order matters more than the individual layers.

I built this for FormTo, an open source Formspree alternative. Code on GitHub at github.com/lumizone/formto. Every snippet below is real production code, simplified for clarity.

1. Rate limit check

The first thing a POST handler should do is reject obvious abuse. Cheap to compute, cheap to fail, runs before you touch the body.

The key shape matters more than the limit numbers. Two patterns are tempting and both are wrong on their own:

// wrong: key only on IP
// one shared NAT gateway throttles every legitimate user behind it
const key = `submission:${ip}`

// wrong: key only on endpoint
// one attacker takes the form down for everyone
const key = `submission:${endpoint}`

The correct shape is both axes:

const key = `submission:${ip}:${endpoint}`
const count = await redis.incr(key)
if (count === 1) await redis.expire(key, 60)
if (count > 5) {
  return reply.code(429).send({ error: 'Too many requests' })
}

Five requests per IP per endpoint per sixty seconds. Returns 429 if exceeded. Sync, blocks the request. The whole check is one round trip to Redis and adds maybe two milliseconds on the hot path.

2. Automation fingerprint

After rate limit, look at the user agent. Most spam fails here before doing any real work.

const automationSignatures = [
  /curl/i, /python-requests/i, /go-http-client/i,
  /node-fetch/i, /axios/i, /httpie/i,
  /headlesschrome/i, /phantomjs/i, /puppeteer/i,
  /scrapy/i, /wget/i
]

if (automationSignatures.some(re => re.test(userAgent))) {
  return reply.code(429).send({ error: 'Automation detected' })
}

This is not a strong signal on its own. Determined spammers spoof user agents. The point is it catches the lazy 60% for free before you spend a CPU cycle on parsing or storage.

3. Multipart parsing and file upload

If the form has file inputs, the body is multipart/form-data and you cannot just call JSON.parse. You need a streaming parser.

Three things go wrong here in production.

First, MIME validation. The Content-Type header on each file part is client-controlled. A real bot uploads a PHP shell with Content-Type: image/jpeg. The fix is to validate the file by reading its first eight bytes (magic numbers) and matching against a known list.

const magicBytes = {
  jpeg: [0xFF, 0xD8, 0xFF],
  png:  [0x89, 0x50, 0x4E, 0x47],
  pdf:  [0x25, 0x50, 0x44, 0x46],
  gif:  [0x47, 0x49, 0x46, 0x38]
}

function validateMagicBytes(buffer, claimedType) {
  const sig = magicBytes[claimedType]
  if (!sig) return false
  return sig.every((byte, i) => buffer[i] === byte)
}

Second, size limits. The default streaming parsers in Fastify and Multer let everything through unless you configure a cap. Set a per-plan limit (10MB for free users, 25MB for paid, whatever your numbers look like) and reject early. A 50GB upload that bursts memory before you check is your fault, not the attacker's cleverness.

Third, cleanup. The streaming parser writes to a temp file first. Forget the finally block that deletes it and you fill the disk in a week. Ask me how I know.

4. Honeypot check

A honeypot is an invisible form field that humans cannot see (CSS hidden, off-screen positioned, autocomplete tricks). Bots fill in every input they find. If the honeypot has a value, it is a bot.

const honeypotFields = [
  'website', '_gotcha', 'honeypot', 'url',
  'phone', 'fax', 'company', 'subject',
  'address', 'zip', 'country', 'fullname',
  'nickname', 'middlename', 'title', 'comment2',
  'email_confirm'
]

const isHoneypotTriggered = honeypotFields.some(name => body[name])

Pair it with a timing check. Add a hidden timestamp field on page load and compare against the server time on submit. Anything under three seconds is almost always a bot.

const formAgeMs = Date.now() - parseInt(body._formto_ts, 10)
const isTooFast = formAgeMs < 3000

The clever part is what you return when either trips. Returning 400 tells the bot to mutate inputs and retry. Returning 200 with a fake submission ID convinces the bot the spam landed. It moves on. This single layer catches roughly 80% of the spam I see at zero CPU cost.

5. CAPTCHA verification

Only run this if the form owner enabled it. CAPTCHA costs latency and a provider API call, so I gate it behind a paid plan.

async function verifyTurnstile(token, ip) {
  const res = await fetch(
    'https://challenges.cloudflare.com/turnstile/v0/siteverify',
    {
      method: 'POST',
      headers: { 'content-type': 'application/x-www-form-urlencoded' },
      body: new URLSearchParams({
        secret: process.env.TURNSTILE_SECRET,
        response: token,
        remoteip: ip
      }),
      signal: AbortSignal.timeout(1500)
    }
  )
  const json = await res.json()
  return json.success === true
}

The trap is that this call sits on the hot path. A Cloudflare or Google API hiccup adds 800 milliseconds to every submission. Set an aggressive timeout (1.5s tops) and decide explicitly what happens if the verification request fails. Fail open and you let bots through. Fail closed and a CAPTCHA outage takes your form down. Pick one. Do not let the network decide for you.

6. Adaptive spam score

What honeypots and CAPTCHA miss, heuristics catch. This is the layer that does the most work without ever showing a challenge to a human.

The score is a stack of signals:

Temp-email domain (mailinator, 10minutemail, guerrillamail): +3
Headless browser hints in user agent: +2
Link density above 30% of message body: +4
Missing Origin and Referer headers: +1
Burst: 8 submissions from one client in 300s: blocked
Burst: 4 submissions from one email in 600s: blocked
Duplicate fingerprint within 60s: blocked

The fingerprint is a SHA256 of (form ID + client fingerprint + body + file hash). Same fingerprint inside the dedupe window means the user double-clicked or a bot is replaying a single payload.

const fingerprint = crypto
  .createHash('sha256')
  .update(`${formId}|${clientId}|${JSON.stringify(data)}|${fileHash}`)
  .digest('hex')

const acquired = await redis.set(
  `dedupe:${fingerprint}`,
  '1',
  'EX', 60,
  'NX'
)

if (acquired === null) {
  // duplicate within 60s, silently accept (fake 200, bot moves on)
  return reply.code(201).send({ success: true, submissionId: fakeId() })
}

Score above five blocks. Score above three blocks if the request also tripped step 1 or step 2. The goal is to leave humans alone and burn bots.

7. Submission insert

Now you are committed. The request looked legitimate enough to store.

const submission = await db
  .from('submissions')
  .insert({
    form_id: form.id,
    form_endpoint: endpoint,
    data: cleanedData,
    file_urls: uploadedFiles,
    metadata: {
      ip,
      user_agent: userAgent,
      referrer,
      spam_risk_score: score,
      spam_signals: signals
    }
  })
  .select('id')
  .single()

The metadata column is the part you will wish you had during incidents. Save more than feels necessary. The spam risk score in particular is gold when a customer complains about missing submissions and you can show them the row was scored, accepted, and emailed.

One race condition burned me here. Forms with a "close after N submissions" feature: two concurrent submitters both check the count, both see it under the limit, both insert. The fix is to enforce the limit inside a Postgres trigger with row-level locking.

CREATE FUNCTION enforce_submission_limit() RETURNS trigger AS $$
DECLARE
  current_count int;
  max_count int;
BEGIN
  SELECT close_after_submissions INTO max_count
    FROM forms WHERE id = NEW.form_id FOR UPDATE;

  IF max_count IS NULL THEN RETURN NEW; END IF;

  SELECT count(*) INTO current_count
    FROM submissions WHERE form_id = NEW.form_id;

  IF current_count >= max_count THEN
    RAISE EXCEPTION 'FORM_SUBMISSION_LIMIT_REACHED';
  END IF;

  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

SELECT ... FOR UPDATE locks the form row until the transaction commits. Concurrent inserts wait their turn instead of all passing the check.

8. Email notify (fire and forget)

Notifications are the visible product. They are also the thing most likely to fail silently.

The temptation is to await the email send so you can return a clean error to the client. Do not. Network calls to Resend, SendGrid, or Postmark add 200 to 400 milliseconds. Multiply by your traffic and your forms feel slow for no good reason.

// fire after the response is on its way back to the browser
sendNotificationEmail({
  to: form.notification_emails,
  template: form.email_template_enabled
    ? form.email_template
    : defaultTemplate,
  data: cleanedData
}).catch(err => {
  logger.error({ submissionId, err }, 'notification email failed')
  // alert if failure rate crosses 1% in a 5min window
})

The dangerous part is that fire-and-forget is a lie if you do not track what fired. If you catch the error, log it, and never look at the log, every silent failure looks like a happy path. Add a notification_status field to the submission: pending, sent, failed. Review the failed ones weekly. A proper retry queue is the real answer once you have volume.

9. Fanout (Slack, Discord, Telegram, webhook)

Everything in this step runs after the response is already on its way back to the browser. All async, all fire-and-forget, all with timeouts.

The webhook is the only one with a security model worth showing. The form owner registers a secret. Every webhook delivery includes a timestamp header and an HMAC-SHA256 signature of timestamp.body signed with that secret.

const timestamp = Date.now().toString()
const body = JSON.stringify({
  event: 'form.submitted',
  form,
  submission
})

const signature = crypto
  .createHmac('sha256', form.webhook_secret)
  .update(`${timestamp}.${body}`)
  .digest('hex')

await fetch(form.webhook_url, {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'x-formto-timestamp': timestamp,
    'x-formto-signature': signature
  },
  body,
  signal: AbortSignal.timeout(10_000)
})

The receiver computes the same signature with the same secret and compares with crypto.timingSafeEqual. If it matches, the request is from you. If it does not, somebody is replaying.

Slack, Discord, and Telegram get block-formatted messages with cruel field limits you only discover in production. Slack caps message blocks at fields[8]. Discord caps embed fields at 15. Telegram messages cap at 4000 characters total. Spammers send forms with 200 fields. Truncate or your formatter throws.

The response

201 Created. JSON body with three keys: success, submissionId, and an optional redirect.

return reply.code(201).send({
  success: true,
  submissionId: submission.id,
  redirect: form.redirect_url || null
})

Validate the redirect URL server-side when the form is configured, never accept it from form data on submit. The javascript:, data:, and unicode-spoofed domains live there.

When you should NOT build this yourself

This is the part most posts skip. After the trace was done and the bugs were fixed, I asked myself if it was worth it. The honest answer for most people is no.

Build your own form backend when:

You have an unusual storage or compliance requirement (data residency in a specific region, on-prem, custom encryption-at-rest)
You are already running infrastructure that this slots into (your own Postgres, your own queue, your own observability)
You need to integrate the submission step into a longer workflow that does not exist in any hosted product
You have a team of two or more developers who can carry the operational load (paging, monitoring, security patches, customer reports)

Buy a hosted form backend (Formspree, Basin, Web3Forms, FormTo, Netlify Forms) when:

You are a solo developer or an indie maker shipping a marketing site, a landing page, or a contact form
The form is not the product, it is a thing the product needs
You bill yourself for your own time at any rate above zero

I built mine because the form backend IS the product. If I were running a marketing site I would pay nine dollars a month to make this problem go away. The pipeline above is two months of bug fixes and three rewrites in disguise.

Three lessons from rewriting this

The order matters more than the layers. Run cheap checks (rate limit, fingerprint, honeypot) before expensive ones (CAPTCHA, storage, DB). Bots get rejected in five milliseconds, humans never notice the difference.

Fire and forget is a lie. If you do not track what fired and what failed, every silent failure looks like a happy path. Add a status field to every async job. Look at the failures once a week. The customers who quietly leave because notifications stop working will never tell you that is why.

The response shape is part of the API even when the API is public. Bots watch what you return. Returning 200 with a fake ID for honeypot hits is more effective than returning 400, because failure tells them to mutate and retry. Lying is a feature.

Back to the forty minutes

The three bugs I found tracing that one POST request: a missing carriage-return strip in the autoresponder subject (header injection waiting to happen), an await on the email send that pushed every submission to a 600ms response time, and the missing row-level lock on the close-after-N counter. All three were one-line fixes. All three had been in production for weeks.

I kept the trace as a runbook for my future self. The next time something looks slow or something looks lost, I have the map.

If you write form backends by hand, what is the bug you wish you had caught earlier?

How 6 AI agents write a single blog post (and why

Łukasz Blania — Thu, 21 May 2026 10:44:01 +0000

About a year ago I shipped a one-prompt blog writer. It worked once.

The second article sounded identical to the first. The third article sounded identical to the second. By the tenth article, every blog I was generating could be mistaken for the same writer with mild amnesia.

That was the moment I started ripping the single prompt apart.

What replaced it is a backend that runs six specialized agents per article. Each one has a narrow job. None of them sees the whole article. The output reads like a human wrote it because the steering is human-shaped all the way down, not because any single model magically learned voice.

This is a walk-through of that pipeline. The exact agents, what they do, why they exist, and what each one breaks if you remove it.

TLDR: one giant prompt is the reason your AI articles sound the same. Split the job into agents with their own contracts, and the output starts behaving.

The problem with a single prompt

A naive AI writer looks like this:

const article = await llm.complete({
  prompt: `Write a 1500 word blog post about ${topic} for ${audience}.
           Use these keywords: ${keywords}. Match this tone: ${voice}.`,
});

It runs in one call. The model gets the whole job in one shot. The output gets returned.

It works. It also produces the same article every time, with cosmetic surface changes.

A 1500 word prompt to a single model produces a 1500 word output that follows the model default essay shape. The intro is always a setup. The conclusion is always a recap.

The body always builds in a smooth gradient. The vocabulary stays in the model safe band. The sentence rhythm averages out.

You can prompt against all of this. You can ask for variety. You can ask for "no AI tells".

The model nods politely and writes another essay that looks exactly like the last one.

The fix is not a better prompt. The fix is to stop treating one model call as the unit of work.

Agent 1: Research

The first agent does not write. It searches.

Input: topic and a short description from the user.

Output: a research brief with real URLs, real quotes, real numbers, and optional canonical links for the strongest claims.

async function research({ topic, description }) {
  const sources = await Promise.all([
    braveSearch(topic, { count: 10 }),
    wikipediaSummary(topic),
    perplexityQuery(`${topic}. ${description}`),
  ]);

  return rankAndDedupe(sources);
}

Why a dedicated agent: a model writing without grounded research hallucinates names, numbers, and citations. A research pass gives the rest of the pipeline a fact substrate. If the substrate is empty, the post gets flagged as "no sources found" and the user is asked to refine the topic.

What breaks if you remove it: every article reverts to model priors. Same three founders quoted. Same dates wrong. Same fake statistics.

Agent 2: Structure

Second agent does not write either. It outlines.

Input: the research brief plus the topic.

Output: an H2 outline. Each H2 gets a one-line angle, a target word count, and a list of entities that should appear inside that section.

async function outline({ topic, research }) {
  return await llm.complete({
    system: "You produce blog post outlines. Return JSON.",
    prompt: outlinePrompt(topic, research),
    responseFormat: { type: "json_schema", schema: outlineSchema },
  });
}

The outline is treated as a contract. Downstream agents have to honor it. No section creep. No drifting into new themes. No skipping a planned H2 because the model felt the article was complete.

Why this agent exists: a single-prompt model picks its own structure mid-paragraph, which is why two articles on the same topic end up structurally identical. An explicit outline forces structural variety to come from the topic and not from the model.

What breaks if you remove it: every article follows the same intro / three-part body / conclusion shape. AI detectors pick this up first.

Agent 3: Section briefer

The brief agent expands each outline item into a per-section brief.

A section brief looks like this:

{
  "h2": "How to set up the webhook",
  "angle": "Concrete walk-through, not a theory primer",
  "wordCount": 280,
  "requiredEntities": ["Stripe", "Express", "raw body parser"],
  "bannedPhrases": ["let us explore", "in this section", "diving in"],
  "codeBlocks": 1,
  "tone": "instructional"
}

Each brief is also a contract. The section writer agent only gets one brief at a time. It does not see the whole outline. It does not see the other sections. It writes for the brief in front of it.

Why this agent exists: it strips the model essay-shape reflex. A model writing one paragraph against a tight brief produces a tight paragraph. A model writing a whole article in one go produces an essay.

What breaks if you remove it: sections lose their distinct voice and collapse back into one homogenous middle. The intro and conclusion get fatter than they should. Examples get washed out.

Agent 4: Section writer

Now we write. One agent call per section.

async function writeSection({ brief, voiceProfile, prevSection }) {
  return await llm.complete({
    system: voiceProfile.systemPrompt,
    prompt: sectionPrompt(brief, prevSection),
    temperature: 0.7,
  });
}

The writer gets the section brief, the voice profile, and a short summary of the previous section so transitions feel intentional. It does not get the full article so far. It does not get the outline. Its job is small enough to stay focused.

This is the agent most teams skip. They keep the single-prompt approach for the actual writing step and only wrap research and outline agents around it. The result still sounds like the same writer because the writer step is still doing the bulk of the cognitive work in one shot.

What breaks if you remove it: rhythm uniformity. Vocabulary uniformity. Paragraph length uniformity. The exact signals AI detectors and human readers both pick up.

Agent 5: Voice profile

The voice agent runs offline, before any article generation, against the user own published writing.

Input: 10 to 20 URLs from the user existing blog or site.

Output: a JSON voice profile.

{
  "averageSentenceLength": 14,
  "vocabularyTier": "casual-technical",
  "preferredOpeners": ["I", "We", "Last", "Honestly"],
  "avoidWords": ["actually", "basically", "stuff"],
  "punctuationPatterns": {
    "semicolons": "rare",
    "exclamation": "never",
    "questionsInBody": "yes"
  },
  "systemPrompt": "You are writing in the voice of..."
}

Every section writer call uses this profile as its system prompt. Two users with different blogs get two completely different article shapes from the same backend.

Why this agent exists: it is the only mechanism that gives the output a non-generic voice. Brand voice cannot be prompted inline. It has to be baked into the system message, derived from real writing, and applied at every section call.

What breaks if you remove it: every article from every user starts sounding like the same model. The product loses its main differentiator.

Agent 6: Polish and artifact strip

Final agent runs a deterministic post-process pass, not a model call.

function polish(markdown, voiceProfile) {
  let out = markdown;
  out = out.replace(/[\u2014\u2013]/g, ", "); // em and en dashes
  out = out.replace(/\u2026/g, ".");          // ellipsis
  out = out.replace(/[\u201C\u201D]/g, '"');  // smart double quotes
  out = out.replace(/[\u2018\u2019]/g, "'");  // smart single quotes
  out = stripBannedOpeners(out, voiceProfile.avoidWords);
  out = enforceSentenceLengthVariance(out);
  return out;
}

This pass strips the obvious AI tells. Em dashes. Smart quotes. Sentence-initial connectors the voice profile banned. It also enforces sentence-length variance so paragraphs do not settle into the model preferred rhythm.

A model could do this step. A deterministic pass is cheaper, faster, and never reintroduces what it just removed. Use a model when you need judgment. Use code when you need rules.

When NOT to use this

Six agents per article is expensive. If you are writing one blog post a week for your own site, this is heavyweight engineering for a problem you could solve by editing a single-prompt output yourself.

Use the multi-agent pipeline when:

You ship dozens to thousands of articles a month
The output has to read consistently across many users
Voice has to vary per customer
Detection or ranking risk is real

Skip the pipeline when:

You write one to five articles a month
A human will edit every output anyway
Latency matters more than quality (a one-shot prompt returns in three seconds, this pipeline takes thirty plus)

The pipeline is also overkill for short formats. Tweets, captions, ad copy, email subject lines. A single prompt is fine there because the cognitive work fits in one call.

What it actually costs

For reference, one article through the six-agent pipeline runs about:

3 to 8 search calls (research agent)
1 outline call
5 to 10 brief calls (one per H2)
5 to 10 section calls
0 model calls in polish (deterministic)

Per-article cost lands around 12 to 25 cents at current GPT-4 class pricing. Total wall-time runs 25 to 45 seconds when the section calls run in parallel.

A single-prompt approach costs around 1 to 2 cents per article and finishes in 5 seconds. The price gap is real. The output gap is also real. Pick which one your product needs.

The article you are reading

Eleven months after I gave up on the single prompt, I have shipped more than 50,000 articles through this pipeline at articfly.com. The articles read like the customers wrote them because the steering profile was extracted from the customer writing. The model still does most of the typing. The pipeline does most of the thinking.

The second article does not sound like the first one anymore. Neither does the ten thousandth.

If you are about to build an AI writer and you are starting with a single prompt, you are about to learn this the slow way. Skip the year. Split the prompt.

What is the one agent in your stack that you wish you had split out earlier?

I built an AI narrative story app because life lacks adventure

Łukasz Blania — Tue, 19 May 2026 17:52:47 +0000

So I built this little thing called an AI narrative story maker and I want to be honest about why.

I grew up on fantasy books, manga, manhwa, anime, JRPGs, MMOs. Like every kid who reads too much, I spent half my brain wondering what I would do if I were in there. What would I do at that tavern? Which side would I pick? Would I trust the cursed knight? Childish, sure, but if you're reading this you've probably done the same.

Then you grow up, you stop. You read a manhwa here and there. Life happens.

Recently I finally managed to leave my 9-5 and suddenly I had time again. As a long-time fan of Omniscient Reader's Viewpoint (if you know, you know), I had this stupid idea. What if I built a kind of story-RPG where the AI is the narrator and you're the character who decides what happens next. I know plenty of apps already do this. But I always wanted to make a game, always wanted to write a fantasy book, and I never did either. So this is more about doing the thing than about market logic.

The app is called First Person Viewpoint (FPV). It's on iOS and Android. You make up your own world, create your character, and the AI handles the narration while you take actions. Basically the same family as AI Dungeon and the others, but vertical-scroll, no chat bubbles, reads more like a manhwa than a chat window.

Genres are pretty open: fantasy, sci-fi, romance, manga, horror, custom, even NSFW (the app is 18+ only). There's a small community feed where users can publish their own worlds.

Honest about the business side

We don't own an LLM. We're not OpenAI. We use third-party APIs and somebody has to pay the per-token bill.
Free tier has ads, just enough to cover token cost on free users so I don't have to sell a kidney every month.
Paid tiers are ad-free with more actions and a better narration model.
We don't sell your data. Sessions live mostly on your device, the server only has what it needs.

It's pretty fair I think. I'm not trying to flip it for a billion. I just wanted it to exist.

What I'd actually love feedback on

Right now most users are friends and family. If you have iOS or Android and you want to try it, I'd be very grateful for any honest reaction. If something feels broken or confusing, even more grateful, that's the feedback that actually helps a solo dev.

The things that keep me up at night:

The first 60 seconds of onboarding. Does the "you are the character" framing land or feel like work?
The "older text fades to navy" effect. Cool or annoying?
Free tier at 250 actions per month. Too tight or about right?
Pricing. Premium is $9.99 and Max is $24.99. Does that read as fair or as another AI tax?

Where this kind of stack is wrong

I'm not going to pretend this approach fits every project. If you're considering shipping a solo AI app, here is when I'd say do not bother:

You need offline first. LLM-driven apps need a network round trip per action. Not viable on a plane.
You need real-time voice. Text-stream latency is fine for prose, terrible for live conversation.
You can't tolerate per-token costs that scale with usage. Pick a flat-fee API or run your own model on a fixed-cost server. The unit economics of a free tier paid for by ads are tight.

For everyone else, the maths is doable. The pieces exist. The hard part is the taste decisions, not the wiring.

So

I built the game I always wished existed. It is live. People are playing it. The kid in me who used to sit in the tavern wondering which faction to join finally got to actually decide.

If you have shipped a solo project that started as a "stupid idea you couldn't shake", I want to hear it. What is the dumb thing you finally got around to making?

Why I built my SaaS without TypeScript on the frontend (and don't regret it)

Łukasz Blania — Tue, 19 May 2026 13:34:28 +0000

I shipped my SaaS dashboard in plain JavaScript. React 19, JSX, no .ts files, no tsconfig.json, no type imports. The marketing site that surrounds it is full TypeScript. The backend is a JavaScript codebase with TypeScript creeping in addtively. Three codebases, three decisions, one indie hacker.

The dashboard is the most opinionated part. Almost every dev.to comment thread I have read on this topic ends in "just use TypeScript, it costs nothing". I disagree, and I want to walk through why for the specific case of a solo-built SaaS dashboard.

This is not an anti-TypeScript post. The marketing site sitting next to the dashboard is TypeScript. The backend is moving to TypeScript file by file. The case I am making is narrower: on a fast-moving, small-team, internal-only React SPA, JavaScript was the right pick, and I would do it again.

What I actually built

To make the rest of this make sense, here is the lay of the land.

dashboard/ — React 19, Vite, React Router v7, Zustand, Tailwind v4, Radix UI. Plain JavaScript (JSX). About 130 components, 28 tests, no tsconfig.
marketing/ — Next.js 16, React 19. Full TypeScript. About 30 pages, MDX blog, SEO-critical.
backend/ — Fastify, Node 20, Postgres. JavaScript with additive TypeScript (utils and middleware migrated, routes still JS).

The dashboard is what users see after they log in. Submissions inbox, form builder, settings, billing, analytics. Internal product surface. The marketing site is the public face: landing, pricing, docs, blog. The backend is the API both call.

The case for TypeScript is strongest on the backend (security, types are contracts) and on the marketing site (long-lived content, multiple contributors potentially). The case is weakest on the dashboard, which is where I drew the line.

Reason 1: I am one developer

The hidden axis on the JavaScript-vs-TypeScript debate is team size.

TypeScript's biggest payoff is on a team of more than three developers. When five people touch the same file in a month, types act as a contract between them. You change a function signature, the type errors light up everywhere it breaks, the team aligns.

On a team of one, that contract is in my head. I changed the function. I know where it is used. The compiler running for 30 seconds to confirm what I already know is a tax I pay every save.

This will change when I hire. I have an escape hatch (Reason 6) for that. Until then, the tax does not earn its keep.

Reason 2: Real shipping bugs are not type bugs

I went through six months of bug reports and self-caught issues across the dashboard. I tagged each one with "TypeScript would have caught this" or "TypeScript would not have caught this".

The breakdown was roughly:

8% — type bugs (passed wrong-shaped object, called undefined as a function, missed null)
92% — everything else (wrong copy, broken API responses, race conditions, layout breaks, browser quirks, missing edge cases, regex errors, off-by-ones, CORS, CSP, hydration, state machine glitches)

TypeScript prevents the 8%. It does not touch the 92%. The 92% is what actually breaks production. Better tests, better error monitoring, and slowing down to think catch more bugs than the strictest tsconfig.json ever has for me.

Reason 3: The IDE already gives me 80% of TS

Modern VS Code reads JSDoc comments and Radix UI's TypeScript definitions and gives me autocomplete on every prop I touch. I can hover over a component import and see its prop types. I can rename a function and have the language server find usages.

I get this without paying for the build step, the strictness ratchet, or the type-import ceremony at the top of every file.

/**
 * @param {{ form: { id: string, name: string }, onArchive: () => void }} props
 */
export function FormCard({ form, onArchive }) {
  return <div>{form.name}</div>;
}

That JSDoc block above gives me autocomplete inside the component, lights up errors when I call onArchive with arguments, and never blocks a vite build from succeeding when I am trying to ship a fix at 11 PM.

Reason 4: My API is the source of truth

The dashboard reads JSON from the backend. The shape of that JSON is defined in one place: the backend route handler. If I tighten the dashboard's expectations using TypeScript types, those types are duplicates of the backend's reality, and they will drift.

Solving the drift problem usually means OpenAPI generators, tRPC, or shared package monorepos. Each of those is a separate complexity budget. The shortcut my dashboard uses: small defensive helpers around fetch, and Optional Chaining everywhere I touch data.

// Reading a submission
const email = submission?.data?.email ?? '(no email)';
const submittedAt = new Date(submission?.created_at ?? Date.now());

That two-line pattern handles every shape-drift case I have hit so far. The cost is one ?. per access. The savings is not duplicating 200 backend types into the frontend.

Reason 5: Speed of iteration matters in year one

The dashboard ships a new feature every week or two. Spam blocklist UI, bulk archive, tag filtering, hosted form pages, email reply, plan upgrade flow. Most of those features were specced and shipped within a few days each.

The bottleneck on indie SaaS in year one is not "we ship code with bugs". It is "we are not shipping anything users want". Anything that slows my loop between "user reports a missing feature" and "user sees the missing feature on production" is taxed against my survival.

TypeScript adds ceremony to that loop. Define the type. Pass the type through three layers of components. Re-run tsc when something five files away changed. Fight the never-have-I-ever-seen-this-error generic inference message. I have been through that loop on past projects and I know the cost.

I would rather ship a small bug than block a fix on a refactor of types.

Reason 6: Migration is cheap when I am ready

The decision to skip TypeScript on day one is reversible. Vite supports TypeScript out of the box. I can rename a file from .jsx to .tsx, add // @ts-check to start with checking, and adopt strictness file by file. No big-bang rewrite. The exit ramp is paved.

I have a written trigger for when I do it: second developer hired, or dashboard exceeds 50,000 lines of code, whichever comes first. At that point, the team contract benefit kicks in and the migration cost becomes worth paying.

Until then, the option is preserved without paying for it.

The honest counter-arguments

I want to address the ones I find genuinely strong.

"TS catches refactor bugs." True. I refactor the dashboard maybe once a quarter. The bugs it would have caught I caught via tests and manual QA. On a faster-refactoring codebase, this argument hits harder.

"Library types are valuable." True, and I get them anyway via my IDE. The TypeScript ecosystem produces type definitions whether or not my code is TypeScript. I read Radix UI's types in autocomplete without my project being TypeScript.

"Onboarding new developers." True. This is the strongest single argument, and it is the exact trigger I set for migration. Day one of a second developer is the day TypeScript starts earning its keep.

"It's not really that slow." True at small scale, false at large scale. tsc on a thousand-file project is a real wait. Vite's transpile-only mode hides it during dev, but CI still feels it. Worth noting.

I am not arguing TypeScript is bad. I am arguing it has costs, and those costs were higher than the benefits for my specific situation.

Why the marketing site is TypeScript

For symmetry, here is why the marketing site got the opposite call.

It is Next.js, where TypeScript is the default. Going against the default would be its own tax. The marketing site is a content surface, not a feature surface. It changes slowly, and changes that break it (broken links, missing meta tags) are caught by type checks. There are no API calls to argue about. The dynamic routes are typed against the file system. Cover images, slugs, frontmatter all benefit from types.

Different code, different decision.

What "no TypeScript" actually looks like

For anyone curious about how a serious React app survives without TS, here is the load-bearing tooling.

JSDoc on shared components and utility functions. Not religiously, but on anything reused.
PropTypes via Zustand store shapes. The store's shape is documented at the top of each store file.
Optional Chaining and Nullish Coalescing everywhere. Cheap insurance against backend drift.
A small api.js that wraps every fetch. Centralized error handling, response unwrapping, retry logic. No type imports needed.
Vitest tests for anything stateful. Tests cover the surface that types would have covered, plus the surface they would not have.
ESLint with eslint-plugin-react. Catches the easy mistakes TypeScript brags about catching.

The total tooling is not zero. It is just not TypeScript.

The takeaway

If you are a solo developer shipping a SaaS dashboard, JavaScript is a defensible default. If you are on a team of three or more, TypeScript almost certainly pays for itself. If you are anywhere in between, look at your bug reports and ask which percentage is type bugs versus the other 92%.

The default advice on dev.to is to reach for TypeScript automatically. I am not against that default. I am against not questioning it.

The dashboard is in production, used daily by paying customers. The marketing site is TypeScript. The backend is migrating. Three codebases, three decisions, one indie hacker who tries to spend complexity where it actually pays off.

What would change your mind on this tradeoff for your own SaaS?

Your contact form is the only page that touches money

Łukasz Blania — Mon, 18 May 2026 11:19:50 +0000

In March 2025 a startup founder filled out my contact form to ask about a six-month consulting engagement. I never got the email. He moved on.

Four months later I bumped into him on a different thread and he replied with "thought you weren't interested."

I never figured out exactly what broke. SMTP credentials had rotated three weeks earlier and my Nodemailer wrapper was eating the auth error. My /api/contact endpoint returned 200. My uptime monitor stayed green. My error tracker had nothing to log. Twenty-eight submissions vanished into the void before I noticed.

That single missed submission was worth more than my AWS bill for the entire year.

TLDR

Your contact form is the only page on your site that directly touches revenue. The rest is content. The form is a cash register, and if you wrote your own /api/contact handler, there is a real chance it is leaking right now and you have no way to know.

This post is about why that happens, what a real contact endpoint needs, and a 5-minute test you can run before lunch.

Why devs misclassify the form

Most contact forms are written something like this:

app.post('/api/contact', async (req, res) => {
  const { name, email, message } = req.body;
  await transporter.sendMail({
    from: 'site@mysite.com',
    to: 'me@mysite.com',
    subject: `Contact from ${name}`,
    text: message,
  });
  res.status(200).json({ ok: true });
});

That code looks fine. It works on your machine. It works in staging. It works the first time you ship it.

Then it sits untouched for years, because you treat it like another endpoint. Just another POST handler. Same priority as /api/health or /api/status.

It is not the same. /api/health failing wakes you up. /api/contact failing is invisible. The user calling it does not refresh the page. They send the message, see the success animation, and assume you got it. Nobody DMs you on Twitter to say "hey, your contact form ate my message, you might want to check it."

A broken /api/contact is the worst kind of bug, because the only person who knows it broke is the person you most needed to hear from.

The silent failure list

Here is a partial inventory of ways my contact handler has actually broken in production across half a dozen projects:

SMTP credentials rotated by the email provider. The handler returns 200, the email never sends. No exception, because Nodemailer logs the auth failure to stderr by default and your serverless platform discards stderr
Resend free tier hits 3,000 emails. Submissions 3,001 through whenever-you-notice silently drop with a quota error you never read
A dependency upgrade changes how multipart/form-data parses. iPhone Safari submits return 415, every other device works fine, you only test on Chrome
DNS MX record swap during an infra migration. Mail delivered straight to spam for 11 days before anyone checks the recipient inbox
A scraping bot fires the endpoint 4,000 times overnight. Real submissions get buried under spam. You stop opening the inbox because it is mostly junk
Vercel cold start times out the first submission of the morning. User retries, gives up after the second try

Each of these felt instantaneous when it broke. Each took me days or weeks to spot.

The common thread: there is no error. Just an absence of an expected signal. And nobody monitors for absence.

Why error tracking cannot catch this

Sentry catches exceptions. A silent 200 with a missing email is not an exception. The handler did its job, by the strictest reading of the code. It returned a status code. The bug is what your handler did not do, and the absence of an action is invisible to a stack trace.

Your uptime monitor catches downtime. The endpoint responds 200, the page loads, the dashboard stays green. Green dashboard, broken revenue.

The only signal that exists is a real human sending a real message and noticing nothing came back. That signal is one customer follow-up away from you noticing. Which means you only notice when the customer cares enough to follow up. Most do not.

What a production contact endpoint actually needs

I wrote this list on a napkin in 2024 after another silent failure. It was embarrassing how short it was, and how much of it my homegrown handler did not have.

A delivery receipt. Did the email actually leave the server? Not "did the SMTP transaction return 200", but "did the message hit the recipient mailbox". Without this you are flying blind.
A dashboard showing every submission. Regardless of whether the email arrived. The submission and the notification email are two separate concerns. Treating them as one is how silent failures happen.
Spam protection that does not show CAPTCHA. Honeypot fields, timing checks, and rate limits handle 95% of bot traffic without ever interrupting a human. CAPTCHA on a contact form kills conversion. Do not ship it unless you have run out of other options.
Per-IP rate limiting on the endpoint. Bots flood. Without this, your inbox becomes useless and your real submissions get triaged into the trash by your own pattern-matching.
Notification redundancy. Email plus Slack, or email plus Telegram. If one channel breaks, the other still pings you. I learned this the hard way.
Audit log with timestamps, IP, and user agent. When something looks fishy (a submission that mentions a feature you do not ship, or a contact at 4 AM their local time), you want the metadata. When something looks lost, you want a record that proves the submission existed.
Replay capability. When a notification email goes missing, you should be able to forward it to yourself or to the right teammate from a dashboard. Not by writing a SQL query.
Auto-responder for the submitter. A short "we got your message, here is what happens next" email. Proves to the customer that the form worked, which means if they do not hear back from you they will follow up instead of assuming you ghosted them.

You can build all 8 yourself. I have. It is somewhere between 40 and 80 hours of work, depending on how careful you are about edge cases. Then you maintain it for the life of the project.

The build vs buy math

Here is the math I run every time someone asks why I do not just write my own:

Initial build: 40 to 80 hours, depending on how thorough you are
Ongoing maintenance: 10 to 20 hours a year for dependency upgrades, infra changes, and email provider migrations
Hidden cost: every silent failure costs you the value of a missed inbound lead, and you cannot measure this until after it happens

Against that:

Free tier of any decent form service: $0, up to roughly 50 submissions a month
Paid tier: $5 to $15 a month, unlimited
Time to first working submission: under five minutes

I have spent days arguing with engineers who insist they can do it in an afternoon. They are right, they can. The first time. The cost is not the first time. The cost is years 2 through 5 of every project they ship, multiplied by the fact that they will never spot the silent failures.

The stack choice

There is no single right answer. The right hosted form service depends on your stack and your budget.

Formspree has been around since 2017, well-tested, decent free tier
Basin is the same shape with simpler pricing
Web3Forms is the cheapest option I know if you just need an inbox
Getform has the best file upload support I have seen
FormTo is the one I built (formto.dev), because I wanted self-host plus custom SMTP plus a dashboard I actually wanted to open every morning

The brand matters less than the fact that you stop trusting your own /api/contact and start trusting a service whose only job is to not lose your submissions. That single change moves the failure mode from "invisible" to "someone else's dashboard with a status indicator."

When NOT to use a hosted form service

Three real cases where rolling your own makes sense:

You have hard data residency requirements. If your industry forbids submission data crossing into US-based SaaS, you either self-host an open-source option (FormTo has a self-host build, Formspree does not) or you build your own. The decision then becomes self-host vs DIY, and self-host still wins on time.

Your form is one input to a complex pipeline. If submissions trigger a workflow that touches your auth, your billing, your CRM, and your internal Slack in real time, a hosted form adds a hop you have to coordinate. At that point your form is part of your product, not a marketing surface, and you should treat it like product code with the same rigor as your billing path.

You are at zero visitors and learning. If you are building your first SaaS and the contact form sees three submissions a year, the failure cost is small enough that the learning value of building it yourself wins. Build it badly, watch it break, then switch to a hosted service the day you actually start caring about leads.

If none of those describe you, the math is not close. Use a hosted service.

The 5-minute test you should run right now

Stop reading and do this:

Open your live site in an incognito window
Fill out your contact form with a Gmail address you do not normally check
Submit it
Open the Gmail inbox

Now verify four things:

Did the email arrive at all?
Did it land in inbox, not spam?
Did it arrive in under 60 seconds?
Is the from-address sane, or does it look like a default noreply you forgot to configure?

If you cannot confidently say yes to all four, your form is leaking. Maybe a little, maybe a lot. You will not know until you look.

I run this test on every project I own once a quarter. It takes five minutes. It has surfaced two silent failures so far this year.

Back to the founder from March 2025

He never came back. I built him a perfectly normal contact form in 30 minutes one weekend in 2021 and assumed it would keep working. It did, until it did not, and then it lied to me about whether it was working.

The cost of a working contact form is between $0 and $15 a month. The cost of a broken contact form is every inbound lead you miss until the day a customer pings you on Twitter to ask why you ghosted them. Those numbers are not close.

Treat the form like the cash register it is. Use a service. Run the test.

When was the last time you tested your contact form in production, not in your dev environment? Be honest.

Per-Section Briefs: How to Stop AI Agents Losing the Plot at 2000 Words

Łukasz Blania — Sun, 17 May 2026 16:35:26 +0000

In March 2025 I wired up my first long-form content agent. One prompt. A 2000 word target. A list of seven H2s pasted in at the top. The first 600 words read fine. By word 1200 the model had quietly forgotten the original thesis. By word 1800 it was paraphrasing the introduction back at me, just with worse vocabulary.

That article never shipped.

TLDR

Instead of asking an LLM to write a 2000 word article in one shot, give each H2 section its own brief, generate the sections in parallel, then stitch the result together. The model only has to hold one section at a time. You can regenerate any failing section without burning the entire piece.

I have shipped over 50,000 long-form articles through this pattern in production for Articfly. Every time I have tried to skip a step and collapse back to a single prompt, output quality dropped. Here is the full pattern and the failure modes it actually solves.

Why single-prompt long-form fails

What goes wrong when you push past 1000 to 1500 words in a single completion:

The model loses recency. Anything in the first 30 percent of the system prompt drifts out of working attention.
Internal repetition explodes. Without a section-level scope, the model rehashes earlier points to fill the word budget.
Transitions degrade. The model strings paragraphs together with generic connectors because it has no scoped goal for the current section.
Errors compound. If section three is weak, section four often inherits the same weakness because the model treats its own earlier text as ground truth.

This is not a model-size problem. I tested the same single-prompt setup with GPT-4o, Claude Sonnet, and Gemini 1.5 Pro. All three drifted past the 1200 word mark. The mechanism is structural, not capability based. You can throw more parameters at it and the failure mode moves from word 1200 to word 1500. It does not go away.

The pattern

Three moving parts:

An outline pass that produces a list of H2 sections, each with a target claim, supporting evidence, and a one-line transition
A section pass that writes one H2 at a time using only the brief and the article-level voice profile
A stitch pass that joins the sections, fixes paragraph-level transitions, and runs a final consistency check

Three calls per article, not one. Sometimes four if you add a fact-check loop. The token cost is only about 50 percent higher than the single-prompt approach because each call is shorter and tighter. You pay for the structure, not for raw token volume.

Step 1: The outline

The outline is the most important call in the pipeline. Get this right and the rest is mechanical.

Outline prompt template:

Topic: <topic>
Primary keyword: <keyword>
Target length: 2000 words
Voice profile: <attached>

Produce an outline with 6 to 8 H2 sections.
For each section provide:
- title (under 60 chars)
- claim (one sentence, what this section argues)
- evidence (2 to 3 bullets, what supports the claim)
- transition (one sentence, how this section leads into the next)
- target_words (integer, must sum to 1800 to 2100)

Output strict JSON.

The key constraints are the claim per section and the target_words sum. Without a per-section claim, the model invents one mid-write. Without a word budget, sections drift to 400 words each and the article overshoots to 3200.

Use a strict JSON output and validate it with Zod or Pydantic. Reject and retry if the word sum is off by more than 10 percent, or if any section is missing a claim. I do not retry the outline silently. If it fails validation twice in a row, the pipeline hard-fails and I see it in logs. A bad outline poisons everything downstream.

Step 2: Write the sections

For each H2 in the outline, fire a section call. These can run in parallel because they do not depend on each other.

js
async function writeSection(brief, voiceProfile) {
  const prompt = buildSectionPrompt(brief, voiceProfile);
  return llm.complete({
    model: "claude-sonnet-4-6",
    system: prompt,
    max_tokens: 1500,
    temperature: 0.7,
  });
}

const sections = await Promise.all(
  outline.sections.map(s => writeSection(s, voiceProfile))
);

The section prompt:

You are writing H2 section "<title>" of a longer article on <topic>.
The full article will be 2000 words. This section targets <target_words> words.

Section claim: <claim>
Supporting evidence: <evidence>
Transition out: <transition>

Voice profile:
<voice>

Constraints:
- Do not restate the article introduction
- Do not preview future sections
- Open with the claim or a concrete example, not a generic setup line
- End with the transition or a sentence that sets it up
- Use first person if the voice profile uses first person
- No headers inside the section (the H2 is handled at stitch time)

Write the section now.

The "do not restate" and "do not preview" lines are load-bearing. Without them, every section starts with "In this article we will explore" and ends with "Next we will look at". The model wants to be helpful in a way that breaks long-form structure. You have to say no.

Step 3: Stitch

The stitch pass is short. It takes all sections, joins them, and runs one more LLM call to fix paragraph-level transitions and remove duplicate phrases.

js
async function stitch(sections, outline) {
  const joined = sections.map((s, i) =>
    `## ${outline.sections[i].title}\n\n${s}`
  ).join("\n\n");

  return llm.complete({
    model: "claude-sonnet-4-6",
    system: `Fix paragraph transitions between sections.
      Do not rewrite. Do not change facts.
      Remove duplicate phrases that appear across sections.
      Replace generic connector words with concrete prose.`,
    user: joined,
    max_tokens: 4000,
    temperature: 0.3,
  });
}

Low temperature here on purpose. The stitch call is an editor, not a writer. If you let it ride at 0.7 it will start adding new content and the article inflates past target length.

The voice profile

The voice profile is what stops per-section calls from sounding generic. I generate it once per customer by scraping 10 to 20 of their published articles and extracting patterns:

Average sentence length
Vocabulary level (Flesch reading ease)
First person versus third person
Common rhetorical moves (anecdote opener, contrarian claim, structured list, war story)
Banned words specific to the brand

The voice profile gets injected into every section call. Without it, each section sounds like a different writer wrote it. The stitch pass cannot fix that drift, only prevent it upstream. You cannot edit voice into existence at the end.

Voice extraction warrants its own article. I will not cover the extraction prompt here, only flag that it is required for any pipeline that wants outputs to read like one writer.

Tips that matter in production

Cache the outline. If the user regenerates one section, do not redo the outline. Hash the topic plus keyword plus voice profile and reuse the cached outline.
Run section generations in parallel. Latency drops from 90 seconds (sequential) to under 30 (parallel).
Validate section word counts. If a section comes back at 50 percent of its target, regenerate only that section.
Keep the stitch model the same as the section model. Mixing models at stitch time changes the voice subtly and readers notice.
Log each section call separately. When a customer complains about an article, you can trace exactly which section drifted and why.
Token budget the section call hard. If you leave max_tokens unbounded, the model fills the context with one runaway section.
Strip generic closers like "in summary" with a regex after stitch. The model still inserts them about 15 percent of the time even when told not to.

When NOT to use this pattern

Per-section briefs add real complexity. Three LLM calls instead of one. Outline validation logic. Section retry logic. Stitch pass. Section storage so you can recover from partial failure. For some content types this is wasted engineering.

Skip this pattern when:

You are generating under 800 words. Single-prompt handles short-form fine.
The content is templated (job posts, product descriptions, FAQ entries). A template plus variable injection beats both single-prompt and per-section.
You need sub-five-second latency. Three sequential calls plus stitch will not hit that, even with parallelization in the middle step.
A human editor reviews every output anyway. The marginal quality gain does not survive a full editor pass.
The output is low-quality-bar SEO filler. Per-section briefs do not save bad input topics.

I run a separate pipeline for short-form (under 600 words) that is one tight call with a tight brief. The cost of the agentic pattern is not free. Treating every output the same is its own kind of one-size-fits-all problem.

Stack notes

For anyone wiring this up from scratch:

Outline pass: any frontier model works. I use Claude Sonnet because the structured JSON output is reliable across temperature settings
Section pass: parallel calls, Claude Sonnet or GPT-4o, temperature 0.6 to 0.8
Stitch pass: same model as the section pass, temperature 0.2 to 0.3
Validation: Zod (TypeScript) or Pydantic (Python) on the outline JSON
Retry policy: 2 attempts per section with exponential backoff. Fail-fast on the outline pass with no retry, just hard fail
Storage: I write each section to Postgres as it completes. If the stitch step fails, I can resume without re-running section calls

Total cost per 2000 word article runs about $0.04 to $0.08 depending on model. The single-prompt version cost $0.03 to $0.05. The per-section pattern costs roughly 50 percent more in tokens. The quality difference shipped 50,000 articles. I will eat the 50 percent.

Conclusion

The article that drifted back in March 2025 did eventually ship. After I rewrote the pipeline around per-section briefs, I ran the same topic through. Same target length. Same H2 list. Same voice profile. The result read like one writer wrote it from start to finish.

The single-prompt version is still in my git history. About once a quarter I dig it up to remind myself why three calls beat one.

What pattern do you use to keep long-form AI output coherent past the 1000 word mark?

40 hours I wasted before I built my own form backend

Łukasz Blania — Sun, 17 May 2026 11:59:48 +0000

Last Friday night I opened my GitHub and ran a search across every personal repo. The query: anything mentioning "form", "submission", "contact", or "POST /". Forty seven results came back. Most of them were variations of the same file.

I sat there counting. Twelve different projects. Five different stacks (PHP, Express, Hapi, FastAPI, Next API routes). Each one had a handler that did roughly the same things. Receive POST. Validate. Check honeypot. Save somewhere. Send email.

I tried to estimate how long each one took. Three hours minimum for the simple ones. Six or seven for the ones that needed Slack notifications or file uploads. Add up the dozen, factor in the bugs I caught later, count the rate limit code I copy pasted from Stack Overflow each time.

The number came out to forty hours. A full work week, spent solving the same problem over and over, across six years.

That night I started building FormTo, the tool I should have written in 2019. This post is the story of why it took me so long, and the things I wish someone had said to me back then.

TL;DR

If you have built a contact form for more than one project, you have probably already lost more hours than you think. The handler feels small every time. The handler is not the problem. The hidden tax around the handler (spam, deliverability, notifications, exports, edge cases) is what eats your weekends. Building once and reusing is cheaper, even if you have to pay nine bucks a month or self host something.

The first handler (2018)

A friend asked me to build a small site for his consulting practice. Plain HTML, a couple of pages, a contact form. I quoted him five hundred euros. We agreed on a deadline.

The HTML and CSS took two evenings. The contact form took three. I wrote a PHP script that mailed me whenever someone submitted. It worked. He paid me. I went on with my life.

Two weeks later he called. The form was getting spam. Like a lot of spam. I added a honeypot field, redeployed, and went back to bed. Three weeks after that he called again. Email delivery from his shared hosting was failing for half the recipients. I migrated him to Mailgun, added DKIM and SPF records to his DNS, billed him for the extra work, and felt smart.

I had no idea that this small contact form would become a pattern I would repeat for every freelance project for the next six years.

The exact same thing, twelve times

In 2019 I wrote an Express handler for a client whose stack was Node. Same five steps, slightly different syntax. Mailgun for email again.

In 2020 I wrote a Hapi handler for a startup that hired me for two months. Their dev lead insisted on Hapi, which I had never used. I learned just enough Hapi to write the form handler, then forgot all of it.

In 2021 I wrote a FastAPI handler for my own SaaS, the one before this one. I added a small queue because submissions were spiky.

In 2022 I wrote two more Next API route handlers. By this point I had a private gist with my "starter snippet" that I copy pasted in. The snippet was 180 lines.

In 2023 and 2024 I wrote four more. The snippet had grown to 240 lines. I had added blocklist support, file upload validation, and a hacky retry loop for failed email sends.

Each time, the first hour of work was "ok, what was that thing I did last time". Each time, the next hour was "wait, my snippet does not handle this new edge case". Each time, the third hour was a fresh round of testing against Postman.

Three hours, twelve times. Plus rework, plus the spam incident in 2020, plus the deliverability mess in 2022, plus the time I shipped a regex for email validation that rejected anything with a plus sign in the address.

Forty hours.

The night I broke

Last summer I deployed a small admin form for a client at 11 PM on a Friday. I was tired. I skipped the honeypot field "because the form is behind auth anyway". My wife came in to ask when I would be in bed. I said twenty minutes.

At 2 AM I was still working. The form was open behind auth, but auth let unauthenticated POSTs through because of a misconfigured middleware. A bot found the endpoint within an hour of deploy and submitted four thousand fake leads. Most of them triggered the email notification to my client. His inbox was destroyed.

Worse: one of the four thousand was a real lead. A real customer had used the same form to ask about a contract. The real email was buried in the spam, my client missed it, the deal went somewhere else.

I patched the middleware, added a honeypot at 3 AM, refunded my client for the missed deal, and went to bed angry. Not at my client. At myself, for shipping the same broken pattern for the seventh year in a row.

Two weeks later I started counting the hours. That was when I decided to build the thing.

What I actually learned

I built FormTo over four months of evenings. The act of writing it as a product, instead of a snippet, forced me to think about the things I had been sweeping under the rug for six years.

Honeypots beat CAPTCHA most of the time

Every project I shipped had a CAPTCHA on the form by default. Most of those forms did not need one. A hidden field with a bait name (something like website, url, or phone_number) catches almost every bot, costs zero user experience, and works without JavaScript.

I now check for nineteen common bait names automatically. CAPTCHA is the last resort, not the first move. Most of the spam I used to get was solved by removing CAPTCHA and adding honeypots.

Email delivery is its own job

I spent more time over the years debugging email delivery than I did writing form handlers. Shared hosting SMTP. DKIM set up but not signing. SPF too loose. Hosts whose IPs landed on a blocklist between Tuesday and Thursday.

The pattern I settled on: a default Resend integration that works out of the box, plus the option to plug in your own SMTP credentials so emails ship from your own domain. Your domain gets the reputation. Your inbox gets the replies. The host does not see the email content.

Notifications matter more than the dashboard

For six years I assumed people would log in to a dashboard to see new submissions. They do not. They check email for ten minutes, then they tune it out. The signal that actually gets read is Slack, Discord, or Telegram. Especially Telegram, which I underestimated for years.

Per form notification toggles, with the credentials saved at the user level. One Telegram bot for all your forms. The dashboard exists, but most people barely open it after the first week.

File uploads are a tax

Every form tool I have ever used either pretends file uploads do not exist or adds them as an enterprise feature. I added them as part of the paid plans. The implementation is small: multipart parsing, MIME validation, a size limit per tier. The reason I had skipped this for six years across freelance projects was not that it was hard. It was that I always told myself "the client will not need this" and then they always did.

Self hosting is an option, not a headline

I open sourced the backend under AGPL 3.0. Docker Compose, Caddy, PostgreSQL. No telemetry. People who want to run it themselves can. The vast majority do not want to, and that is fine. The SaaS pays for the maintenance, the self host option keeps me honest. Both versions read from the same codebase.

When the snippet is still the right answer

This post would be useless if I did not say where the trade goes the other way.

Use a form backend (mine or anyone else's) when the form is a contact form, a feedback form, a waitlist signup, or any case where the submission lives on its own and just needs to land somewhere visible.

Write your own handler when the form is part of a larger workflow with conditional logic per step, when the submission needs to write across half a dozen tables, or when you are already running a backend with fifty endpoints and the form is just one more.

I still write custom handlers. I just do not write them for contact forms anymore.

The math, redone

This morning I ran the same GitHub search I ran on that Friday night. Same query. Same repos. I filtered out anything from before FormTo shipped.

Six projects shipped after I started using my own tool. Total time spent on form handling across those six projects: about forty minutes. Most of that was pasting the action URL and writing the autoresponder template.

Forty hours over six years, replaced with forty minutes over one year. That ratio is the entire reason this tool exists.

How many hours have you spent writing the same form handler? I am genuinely curious. Mine was forty. I have a feeling yours is higher than you want to admit.

I got tired of paying for form backends, so I built my own

Łukasz Blania — Wed, 08 Apr 2026 09:57:47 +0000

A buddy of mine does freelance web dev. Mostly small business sites -- restaurants, dentists, that kind of thing. Every single client needs a contact form. And every single time it's the same conversation: "Why am I paying $20 a month just to get emails from my website?"

Fair question honestly.

His solution was to rig up an n8n workflow that catches form submissions via webhook and dumps them into a Google Sheet. It works. Technically. Until a column shifts, or the webhook URL expires, or the client wants to see their submissions somewhere that isn't a spreadsheet.

I kept thinking about this. A form backend is such a basic thing. You receive a POST request. You save it. You send a notification. Maybe you show it in a dashboard. That's it. That's literally the whole product. And yet Formspree wants $20/mo for it. Basin, Formcarry -- same ballpark.

So around December last year I decided to just build the thing myself.

The building process

I should mention -- this was always a side project. I run a small automation agency during the day, so FormTo got evenings and weekends. Some weeks I'd grind on it for hours, other weeks I barely touched it. That's just how side projects go I guess.

The backend came together pretty fast. Fastify, PostgreSQL, standard stuff. I used Claude Code a lot during development and honestly it was a game changer for velocity. Stuff that would normally take me a full evening to figure out -- like getting JWT auth right, or writing all the database migrations, or setting up the Caddy reverse proxy config -- I could knock out in an hour or two. Not saying AI wrote the whole thing, but it definitely cut the timeline by half, maybe more. For a solo dev working on nights and weekends that matters a lot.

The frontend though. That's where things got interesting.

The Upwork disaster

I'm primarily a backend guy. I can hack together a React app but I'm not going to pretend I'm a frontend specialist. So I thought OK, let me hire someone on Upwork to build a clean dashboard UI. Found a guy, decent portfolio, good reviews. Gave him the designs, explained the API, set up the repo.

What a disaster.

The first delivery was basically a template he found somewhere with my API calls shoved in. Half the components didn't work. State management was all over the place. I spent more time reviewing and fixing his code than it would have taken me to write it from scratch. After two rounds of revisions that somehow made things worse, I just paid him for the hours and moved on.

Ended up building the frontend myself with Claude Code again. Took me about two weeks to get something I was actually happy with. React 19, Tailwind v4, Radix UI for the component primitives. Is it the most beautiful dashboard ever? No. But it works, it's consistent, and I understand every line of code in it. That Upwork detour cost me about a month of progress and a few hundred dollars for code I threw away entirely.

Lesson learned: if your project is small enough and you're technical enough, just build it yourself. Hiring makes sense when you're scaling, not when you're prototyping.

So what is FormTo actually?

FormTo is a self-hosted form backend. You take any HTML form, point the action attribute at your FormTo instance, and submissions start showing up in a dashboard. No JavaScript SDK, no API keys, no build step.

<form action="https://forms.yourdomain.com/f/contact-abc123" method="POST">
  <input name="name" required />
  <input name="email" type="email" required />
  <textarea name="message"></textarea>
  <button type="submit">Send</button>
</form>

I only built stuff I actually needed or my friend kept asking for. Notifications go to email (any SMTP), Telegram, Slack, or a generic webhook -- so you can still pipe it to n8n or Make if that's your thing, but you don't have to anymore. There's spam handling with honeypot fields and rate limiting instead of CAPTCHAs because nobody likes CAPTCHAs. Auto-close after X submissions or a date, which turned out to be really handy for RSVPs and waitlists. CSV export because someone will always ask for a spreadsheet, it's like a law of nature at this point. And hosted form pages if you don't even want to write HTML -- just share a link and you're done.

Running it

The whole thing runs on Docker Compose. One command and you've got a working form backend with automatic HTTPS via Caddy. There's a first-run wizard so you don't need to mess with config files beyond setting a domain and database password. It runs fine on a $5 VPS.

git clone https://github.com/lumizone/formto
cd formto
cp formto.env.example formto.env
docker compose up -d

One thing I want to be clear about -- this is not a form builder. No drag-and-drop, no visual editor, no templates. You write your form however you want and point it at FormTo. That's intentional. There are a million form builders out there already. I just wanted the backend part done well.

Open source + cloud

It's open source under AGPL-3.0. The full feature set is right there, nothing held back behind a paywall or a pro tier. I'm also working on a cloud version at formto.dev for people who don't want to deal with servers, but the self-hosted version will always be the complete product. No artificial limits to nudge you toward paying.

GitHub: github.com/lumizone/formto

It's still early and I'm the only one working on it. If something breaks, if you want a feature, or if you just want to tell me the UI is ugly -- open an issue. I read all of them.

How AI Can Finally Write B2B Outreach Emails That Actually Work

Łukasz Blania — Sun, 07 Sep 2025 17:40:30 +0000

Cold emailing has always been a strange mix of art and science. On one hand, it’s about persuasion, psychology, and human connection. On the other, it’s a numbers game — you need enough volume to cut through the noise and land in front of the right people.

For years, founders, marketers, and sales reps have been caught in the same dilemma: personalize every email manually and burn endless hours, or send generic templates at scale and watch reply rates crash to zero.

When AI burst onto the scene, many people thought the problem was solved. “Just let ChatGPT write your emails!” But anyone who tried quickly discovered the ugly truth: most AI-generated emails sound painfully robotic, overloaded with buzzwords, or so vague they could apply to any business on the planet.

So why does AI stumble so badly at something as simple as writing a cold email? And more importantly, how do we fix it?

Why AI Struggles With Email Outreach

AI’s weakness comes down to context. Large language models are designed to be general-purpose — they can write code, explain history, summarize legal documents, and yes, write emails. But that flexibility comes at a cost.

Think of it like buying a single machine that tries to function as a fridge, oven, washing machine, coffee maker, and television all at once. Technically, it can do all of those things. But if you want the perfect sourdough baked at 230°C? Or a rich espresso brewed at 8 bars of pressure? That multi-tool monster won’t cut it.

Email outreach requires precision. You need the right tone, the right length, the right level of personalization, and a clear value proposition. It’s not enough for the text to “look okay” — it has to feel like it came from a human who understands the recipient’s problems.

When you ask AI:
“Write me a cold email to a marketing agency.”

It fills in the blanks with generic business language. You get lines like:
“We offer innovative solutions to help your business thrive in today’s competitive landscape.”

It looks polished. But it’s the kind of sentence that 10,000 other emails also contain. And in the real world, that means instant delete.

Structure: Giving AI a Map to Follow

Here’s the first key: AI performs best when you don’t just give it a vague request, but a map. Structure is the difference between usable output and robotic nonsense.

Think of sending instructions to AI like shipping a package:
If you throw your product, address, and label separately into the sky, maybe — by pure chance — it lands in the right place.
But if you pack it carefully, seal the box, and give it to a courier with clear delivery instructions, you know it will arrive exactly where it should.

AI is the same. If you tell it “write me a cold email,” it’s guessing. But if you hand it a proven structure and specific guidelines — suddenly, it becomes a precision tool.

Here’s an example skeleton I use in real campaigns:
{{name}},

{{icebreaker}}
Everyone in [[niche]] is leaking cash, slow intake, lost follow-up, clunky admin., all bottlenecks AI actually kills. No fancy buzzwords. This is about running tighter, faster, and never missing a chance to win deals or lock in repeat buyers.
{{name}}, spotted gaps you can close for good. Most never even spot the leaks. Want the straight playbook or staying stuck? Reply yes or no, nothing else.
[[YourName]]

This structure forces clarity. It starts with a hook (the icebreaker), names specific problems the recipient actually feels, and ends with a simple binary CTA. No long-winded pitch, no corporate jargon, no desperate begging for attention.

When you feed AI this structure and add rules like “do not use the word synergy” or “keep it under 120 words,” the difference is dramatic. Instead of generic fluff, you get concise, sharp outreach that feels human.

Personalization: The Real Game-Changer

Templates are useful, but they’re just the skeleton. The muscle of a great outreach campaign is personalization. Without it, even the best structure falls flat.

Think about your own inbox. If you get a message that clearly went to 500 other people, you delete it without reading. But if someone references your company, your latest LinkedIn post, or a pain point you actually deal with, you pause. You might even reply.

AI can do personalization at scale — but only if you feed it the right inputs. That means giving it data such as:

Who the recipient is: job title, role, decision-making power.
What the company does: industry, recent projects, unique positioning.
What’s happening now: case studies, blog posts, product launches, LinkedIn updates.
Your specific angle: how your offer relates directly to their situation.

Here’s the key: AI doesn’t guess well. If you don’t give it this information, it will invent generic filler. But if you provide real context, it can weave it into your email in ways that feel personal and authentic.

Yes, you could technically research and write this by hand. For five prospects, sure. For fifty, it starts getting painful. For five hundred? It’s impossible without burning out. And that’s where automation becomes essential.

Automating the Grind With AI + n8n

This is where outreach stops being a chore and becomes a system. By combining AI with automation platforms like n8n, you can run campaigns that are personalized, scalable, and efficient.

Here’s how it looks in practice:

Google Sheets — load in your prospect list. Maybe it’s 1,000 contacts pulled from LinkedIn Sales Navigator.
Anymail Finder — automatically fetches and verifies the correct email addresses. You only pay for valid ones, so there’s no wasted budget.
Perplexity — pulls in live web data for each prospect, so you have current, relevant details to use for personalization.
OpenAI — writes the emails using your structure, style rules, and the personalized data you collected.
n8n — stitches everything together, runs it in sequence, and outputs emails that are ready to send.

The best part? Once you set this up, you’re no longer chained to your laptop, spending nights crafting line after line. The system runs in the background. You wake up the next morning, and your outreach campaign is already written and queued.

Instead of drowning in repetitive work, you focus on what actually matters: conversations with prospects who are ready to buy.

Results From the Field

When I tested this system, here’s what happened over a 3-week campaign:

Delivery rate: 99%
Bounce rate: 1%
Open rate: 54%
Click-through rate (CTR): 18%
Prospects amount: 300
Emails per person: 5 (4 follow-up)

And the craziest part? I spent maybe 4 hours total. That time was used for setup: preparing the email footer, creating the prospect list, and configuring the workflow. The rest ran automatically.

Normally, you’d need a full sales development team for those results. With AI and automation, one person can achieve the same — without sacrificing evenings, weekends, or sanity.

Why This Matters More Than Ever

It’s tempting to dismiss all this and say: “I’ll just write emails myself.”

And for small-scale outreach, you’re right. If you’re sending 5 emails to potential partners, don’t overthink it. But scale changes the equation.

Cold email is fundamentally about volume. The law of large numbers applies — you need to reach enough people for opportunities to materialize. But pure volume without personalization is spam. And pure personalization without automation is impossible to sustain.

AI gives you the middle ground: volume with personalization. Instead of choosing between quality and quantity, you finally get both.

This isn’t just a productivity hack. It’s a competitive edge. Companies that figure out how to combine AI with outreach workflows will simply outpace those who don’t. They’ll send more messages, book more calls, and close more deals, all while spending less time in the weeds.

Final Thoughts

AI isn’t magic. If you just open ChatGPT and type “write me a cold email,” you’ll get the same robotic junk everyone else is sending. That’s why so many people conclude that AI “doesn’t work for outreach.”

But the truth is different. AI works brilliantly when you give it structure, feed it personalization, and connect it to automation tools that handle the heavy lifting.

Think of it like this:

On its own, AI is a brilliant but unfocused intern. It has potential but doesn’t know what you want.
With guidance (structure), it becomes a competent writer.
With resources (personalized data), it becomes persuasive.
And with automation, it becomes a full-scale outbound team that never sleeps.

That’s the power shift. You stop being limited by hours in the day and start running outreach at a scale that would normally require a small army.

I’ve packaged my exact workflow so you don’t have to reinvent the wheel. You can grab it here:

My n8n Workflow

AI isn’t about replacing human skill. It’s about multiplying it. And in B2B outreach, that multiplier can be the difference between sending a handful of emails that get ignored — and running a campaign that actually drives deals.

PS: “I sent” over 600 emails walking on the Mountains, for a whole week, found 4 clients, and spent a great time ;)

ChatGPT-5 Is Amazing. You don’t know how to use this properly. I show you why.

Łukasz Blania — Sun, 07 Sep 2025 10:11:00 +0000

Let’s talk like humans for a second. You typed a vague thought into a text box, hit Enter, and expected cinematic genius to roll out of the machine like a red carpet. Instead, you got something… meh. You sighed. “ChatGPT-5 is worse than 4o!” you posted, shaking your fist at the cloud.

I’ve got news that will both empower you and mildly annoy you: GPT-5 is better than GPT-4o for most real work — agents, tool use, coding, long context, instruction following — but it punishes sloppy prompts more than its predecessors. The model is more steerable, more systematic, and far more literal. If you tell it where to go, it’ll drive. If you say “take me somewhere nice,” don’t be surprised when you end up in a parking lot with decent lighting.

This article is a friendly deep-dive into how to get consistently great results with GPT-5. We’ll quickly cover what changed from the GPT-4o era, why your results might feel bland, how the new modes (Instant, Auto, Thinking, and Pro) actually work, and a handful of practical snippets — straight from the playbook of people who use GPT-5 all day — to help you write prompts that don’t waste tokens or time.

Grab a coffee. I’ll keep it conversational, a little dry-humored, and very practical.

What Changed: From a Zoo of Models to One Agentic System

In the GPT-4o days, you often had to choose your fighter — a model for speed, another for multimodal, another for reasoning, and so on. GPT-5 simplifies that mental overhead. Think of it less like “a model” and more like an agentic engine with multiple gears:

A unified core (one flagship model) that routes internally.
Modes that change how hard it thinks and how verbose it speaks.
Agent-first behavior: better at calling tools, following rules, and persisting plans across steps.
Stronger instruction adherence: if your instructions conflict or are vague, GPT-5 will spend effort reconciling that mess instead of producing gold from chaos.

The practical effect is: less menu anxiety, more steering power. But you have to actually steer.

“My Results Are Terrible” — Why That Happens with GPT-5

Let’s get the uncomfortable bit out of the way: GPT-5 is allergic to ambiguity. GPT-4o was often forgiving. You could toss a fuzzy prompt at it and it would do a decent job guessing your intent. GPT-5 can still guess — but it’s trained to respect your constraints and follow your process when you give it one. When you don’t, it can over-invest in clarification or under-deliver because the target was never pinned down.

Here are the three most common causes of “bad answers” with GPT-5:

Vague goals
- “Write a plan” is not a goal.
- “Draft a 7-step launch plan for a two-person SaaS, each step ≤120 words, with a simple checklist and a 14-day timeline” is a goal.
Contradictory rules
- “Never ask the user to confirm anything” vs. “Always obtain explicit consent before booking” is the kind of conflict that sends GPT-5 into polite paralysis. It tries to satisfy both. Resolve conflicts yourself.
Missing stop conditions
- Agents need to know when to stop. If you don’t define finish lines, they’ll keep circling the track — or stop too early. You decide the lap count.

The fix: be explicit about what you want, how you want it, how far the model should explore, and when it’s allowed to proceed despite uncertainty.

The Modes: Instant, Auto, Thinking, Pro — What They Actually Do

GPT-5 exposes four working styles. These aren’t just “speed settings”; they’re behavior contracts. Use the right one for the job, and your life gets easier.

1) Instant — “Answer fast, don’t overthink it”

Instant mode is the one that answers as quickly as possible, often sacrificing depth and nuance to give you something fast and usable. It shines when the task is simple — like rewriting a sentence, summarizing a short passage, or giving a factual answer — but it won’t bother with complex reasoning or edge cases. If you ask it to solve a real problem, it will simply hand you the quickest version of an answer and move on.

When to use:

Quick summaries, short emails, simple rewrites, straightforward Q&A.
Latency-sensitive interfaces (chat widgets, quick drafts).
You already know what you want; you just need it formatted or rephrased.

Strengths:

Low latency, low cost.
Great when the task is clear and bounded.

Pitfalls:

Doesn’t wander far. If the task is fuzzy, Instant will give you a tidy version of your fuzziness.
Minimal context gathering; it won’t go spelunking unless told.

How to prompt for Instant:
Why this works: you’ve set a tiny budget, a clear finish line, and a crisp format. Instant thrives on constraints.

Search depth: very low
Absolute max tool calls: 2
Proceed with the best available answer even if not fully certain.
Stop when output meets the format and constraints below.

Audience: startup founders, non-technical
Length: ≤ 180 words
Format: 3 bullets + 1-sentence CTA
Tone: concise, friendly, no fluff

2) Auto — “Pick the right depth for me”

Auto mode is the balanced choice. It adapts to the difficulty of the task, behaving like Instant when things are straightforward, but taking more time and reasoning when the problem requires it. This makes it the most practical mode for everyday use, because you don’t have to decide how much thinking the model should do — it figures it out on its own. The catch is that if your instructions are vague, Auto might overanalyze and spend too much time gathering context before giving you what you want.

When to use:

Most day-to-day tasks where you don’t want to micromanage.
The model can decide whether to think shallow or deep.
You’re okay with it calling tools and making a plan if needed.

Strengths:

Balanced. Often the best default.
Can switch gears mid-task: skim where trivial, dig where tricky.

Pitfalls:

If your instructions are vague, Auto might “gather context” longer than you expected.
If your rules conflict, Auto burns cycles reconciling them.

How to prompt for Auto (calibrated):

Goal: get just enough context to act.
Method:

Start broad, then one focused batch of subqueries.
Deduplicate; cache; avoid repeated searches. Early stop:
You can name exact items to change or produce. Escalate once:
If signals conflict, do one refined batch, then act. Keep going until all subtasks in the plan are done. Do not hand back on uncertainty—proceed with the most reasonable assumption, and document it in the summary.

3) Thinking — “Take your time, reason deeply, chain steps”

Thinking mode is where GPT-5 goes deep. Instead of rushing, it breaks the problem apart, makes a plan, and follows through step by step. This mode is built for accuracy, analysis, and complex reasoning. It’s slower and more expensive, but if you want a model that can handle multi-step research, write thorough strategies, or work inside large codebases, this is the gear you want. Without clear instructions, however, it can end up overthinking and generating more than you bargained for.

When to use:

Complex multi-step problems, long-horizon tasks, architecture, tricky analysis, non-trivial refactors, research synthesis.
Anywhere accuracy, edge cases, and planning matter more than speed.

Strengths:

The highest quality reasoning and decomposition.
Excellent at following multi-stage processes and double-checking work.

Pitfalls:

Slower and more expensive.
If you don’t set stop conditions, it may over-invest in “thoroughness.”

How to prompt for Thinking (with guardrails):

Decompose the request into a numbered plan (max 7 steps).
Before executing, validate the plan against constraints and risks.
After each step, self-check: does this meet the acceptance criteria?
Output passes all format checks.
No TODOs or placeholders remain.
Edge cases addressed: [list your edge cases].
Total tool calls: ≤ 6 unless a blocker is detected.
If a blocker is detected, explain briefly, then request explicit permission to exceed. Pro move: pair Thinking with the Responses API and reuse previous_response_id across turns. This preserves the model’s plan/context without re-paying for it each time.

4) Pro — “All-in performance with ”

Pro mode is the perfectionist. It doesn’t just think deeply like the Thinking mode, it also packages the result neatly, with polish, structure, and presentation. This makes it the mode for high-stakes tasks: executive memos, legal drafts, detailed proposals, or anything where you want the output to look like it came from a professional rather than an assistant. It is the slowest and most resource-intensive option, and sometimes it’s simply overkill, but when the final product matters, this is the mode that delivers.(Only available in pro plan(200$/month))

When to use:

High-stakes deliverables where both the thinking and the final writing must be excellent: investor memos, legal policy drafts, system designs pitched to executives, production-grade code proposals.
Scenarios where tone, formatting, and completeness are part of the spec.

Strengths:

Combines depth with editorial quality and strong instruction adherence.
Great at keeping the big picture while nailing the details.

Pitfalls:

Overkill for quick tasks.
If your prompt is vague, you’ll pay more to get a beautifully formatted shrug.

How to prompt for Pro (quality spec):

Structure: executive summary → details → risks → next steps.
Evidence: cite sources or assumptions inline; mark assumptions clearly.
Style: plain English, active voice, short paragraphs.
Review pass: do a final contradiction scan; align with acceptance criteria.
Provide a clean deliverable plus a 5-line TL;DR.
Include a checklist the reader can act on immediately.

Prompt Patterns That Work in GPT-5 (And Why)

1) Contracts beat vibes

Define output contracts, budgets, stop conditions, and escape hatches (“Proceed even if not fully certain”). GPT-5 respects contracts.

2) Remove contradictions at the source

If your process has a real exception (“In emergencies, skip patient lookup and give 911 guidance”), write that exception explicitly. The model is obedient; don’t make it choose between rule parents.

3) Use “tool preambles” to keep humans oriented

If your agent will run multiple steps or edit files, have it front-load the plan and narrate progress succinctly.

Rephrase the user goal briefly.
Outline a step-by-step plan.
Announce each tool call and why.
Summarize: planned vs. completed. 4) Control eagerness, don’t just complain about it Too much “research”? Tighten <context_gathering>. Too many clarifying questions? Add <persistence> and tell it to assume and proceed.

5) Verbosity is a dial

There’s a verbosity parameter (final answer length) and your prompt can override it locally. For instance: global verbosity: low, but inside code tools ask for “high verbosity” diffs and comments. You’ll get tight narration, but richly explained code edits.

Practical Snippets You Can Paste Today

A. The “Atomic Task” Skeleton (great for Instant/Auto)
Task: Rewrite the following draft into a 120–150 word LinkedIn post for non-technical founders.
Include: a hook (1 sentence), 3 value bullets, 1 CTA sentence.
Constraints: avoid buzzwords; no hashtags; plain English.
Stop when: length and structure are satisfied.
If uncertain: proceed with best-effort and leave a one-line note of assumptions at the end.
Draft:
[PASTE]

B. The “One-Batch Research” Guardrail (Auto)
<context_gathering>

Run exactly one parallel batch of searches.
Read top 3 hits per query; deduplicate.
Early stop when ~70% of sources converge on the same answer.
No second batch unless a contradiction blocks action. </context_gathering>

C. The “Thinking Pass” for Complex Work
<planning>
1) Draft a mini-rubric (hidden) with 5–7 criteria for excellence.
2) Produce a numbered plan (≤7 steps) to satisfy the rubric.
3) Execute step-by-step; after each, self-check against the rubric.
4) At the end, summarize residual risks or uncertainties.
</planning>

D. The “Code Edit Rules” (Frontend example)
<code_editing_rules>

Clarity first: descriptive names, small components, minimal props.
Consistency: Tailwind spacing multiples of 4; 1 neutral + ≤2 accents.
Stack defaults: Next.js (TS), Tailwind, shadcn/ui, Lucide, Zustand.
Directory: /src/app, /components, /hooks, /stores, /lib, /types.
Deliverables: a focused diff + short rationale + test notes. </code_editing_rules>

E. The “Finish Line” Contract (for any mode)
<acceptance_criteria>

Format exactly as specified below.
No placeholders or TODOs.
Edge cases addressed: [list].
Final: a 5-line TL;DR the reader can act on. </acceptance_criteria>

Cookbook-Style Moves (Lifted from Real Usage)

1) Persist reasoning between steps (Responses API)

When your agent must call tools across turns, reuse previous_response_id. You’ll avoid “re-planning tax” and keep latency sane on long tasks.

2) Minimal Reasoning ≠ Minimal Guidance

If you choose minimal/low reasoning for speed, compensate with more explicit planning in the prompt. Example: ask the model to output a 4-bullet “what I’m about to do” before it does it. Your bullets become its scaffolding.

3) Calibrate questions vs. assumptions

If you hate clarifying questions mid-flow, say so:
“Do not hand back to the user for confirmation; make the most reasonable assumption and proceed. Document assumptions at the end.”

4) Prefer local verbosity overrides

Short final answers, verbose code diffs. Or vice versa. Tell it where to spend words.

5) Use metaprompting to improve your prompt

Stuck? Ask GPT-5: “Given this prompt and this undesired behavior, what minimal edits would you make to elicit [desired behavior]?” You’ll get direct, actionable nips and tucks instead of a full rewrite.

A Guided Tour: Matching Tasks to Modes

Task	Mode	Why	Prompt Tip
Rephrase email, fix tone	Instant	Clear target, low risk	Define length, audience, tone, and stop condition
Draft landing page copy	Auto	Some thinking, some speed	Provide section outline + word budgets per section
Compare 3 vendor APIs, decide	Thinking	Research + synthesis + decision	One-batch research + acceptance criteria + TL;DR
Large refactor (multi-file)	Thinking/Pro	Planning, code quality, diffs	Code rules + plan + test notes + finish line
Exec memo with risks & next steps	Pro	Quality + polish + structure	Quality bar + handoff checklist
Bug triage in a repo	Auto → Thinking if complex	Start lean, deepen if needed	Plan first; escalate only once

Fixing the Five Classic Anti-Patterns

“Write me a strategy”
- Better: “Write a 7-step GTM strategy for a 2-person SaaS selling a $29/mo analytics add-on to Shopify stores. Each step ≤120 words; include risks and a day-by-day 14-day plan.”
“Be creative but concise but also very detailed”
- Pick a lane. If you must blend: “Use crisp, concrete language; short paragraphs; examples over adjectives. Max 500 words. Include 2 concrete examples.”
“Summarize this PDF” (no audience)
- Better: “Summarize for CFO who needs to decide by Friday. Extract 3 numbers, 3 risks, 3 upside factors. Max 200 words + 5-line TL;DR.”
“Improve the code” (no definition of “improve”)
- Better: “Refactor for readability and testability: extract components, remove dead code, add 3 unit tests. Keep behavior identical. Explain diff in 5 bullets.”
“Research everything about X”
- Better: “Run one batch of searches; read top 3 results; stop when sources converge. Produce a 10-bullet executive summary + links + open questions.”

Tiny Prompts That Save Hours

“Assume don’t ask” switch:
- “Do not ask for clarifications mid-task. When uncertain, choose the most reasonable assumption, proceed, and log assumptions in the final summary.”
“Don’t wander” leash:
- “Limit context gathering to one batch; no second batch unless contradictions block progress.”
“No fluff” pressure:
- “Plain English. No metaphors. No analogies unless requested. Replace adjectives with numbers or examples.”
“Rubric-first build” for greenfield:
- “Before building, silently create a 6-point rubric for a world-class [deliverable]. Use it to self-check each step; do not show the rubric.”
“Finish line” clarity:
- “Stop only when the deliverable meets the acceptance criteria; otherwise continue iterating.”

A Word on Tone, Humor, and Human-ness

You’ll notice GPT-5 can feel a little… serious. If your audience expects warmth or punch, ask for it:

“Friendly, lightly humorous tone.”
“Speak directly to the reader (‘you’), like a helpful colleague.”
“Short paragraphs. Occasional one-liner for levity.”

And if you want zero fluff: say “No jokes, no rhetorical questions.” The model will comply. It’s obedient, not psychic.

Putting It All Together: A Mini Playbook

Choose the model:
- Instant: quick, bounded tasks.
- Auto: default for most.
- Thinking: complex, multi-step, accuracy-critical.
- Pro: high-stakes, polished deliverables.
Define the deliverable:
- Audience, length, structure, constraints, finish line.
Steer eagerness:
- <context_gathering> for budgets and early stops.
- <persistence> for autonomy and fewer clarifying questions.
Specify quality:
- <quality_bar> and <acceptance_criteria>.
- Verbosity rules (where to be terse vs. detailed).
Use tool preambles:
- Plan → narrate → summarize. Humans love to see the map.
Persist reasoning across turns:
- Responses API + previous_response_id. Pay once, reuse the plan.
Keep prompts contradiction-free:
- Resolve rule conflicts up front. Explicit exceptions beat implicit hope.
Iterate:
- When results disappoint, ask GPT-5 to propose minimal prompt edits to reach your desired behavior. Ship the improved version.

The Punchline Without the Punch

If GPT-4o was your friendly generalist who tried to read your mind, GPT-5 is your meticulous colleague who will do exactly what you asked — and look at you expectantly if what you asked was unclear. It’s smarter, more persistent, and wildly capable. But it is not a magician. Vague in, vague out.

Write contracts, not vibes. Choose the right mode. Set budgets and finish lines. Give it a quality bar to clear and an escape hatch when uncertainty isn’t worth the wait. Do that, and GPT-5 stops feeling “worse than before” and starts feeling like the teammate you brag about.

If you still want “somewhere nice” without directions, I hear the parking lot has great lighting.