DEV Community: Mahmut Gündüzalp

Building Newsroom AI Modules in PHP: 50+ Specialized Workflows

Mahmut Gündüzalp — Fri, 26 Jun 2026 08:50:23 +0000

When people picture "AI in a newsroom," they usually imagine one big chat box bolted onto the editor. That's the wrong mental model, and it's the reason most of those features get used twice and then ignored.

A newsroom doesn't have one AI need. It has dozens of small, specific, repetitive ones: write three headline options, pull a 280-character social blurb, suggest a category, tag entities, generate alt text for the lead image, flag a defamation risk, translate the dek into English, propose an SEO title under 60 characters. Each is a tiny job with its own input shape, its own output contract, and its own tolerance for being wrong.

After running this across 200+ news sites, the architecture that actually stuck was not "an AI feature." It was a registry of small, specialized workflows behind a uniform interface. This article is how that's built in PHP, and the handful of decisions that matter more than which model you pick.

The unit of work: a task, not a prompt

The first thing to get right is the boundary. The reusable unit is a task — a named workflow with a fixed contract — not a free-floating prompt string. A task knows three things: what it needs, what it promises to return, and how expensive it's allowed to be.

interface AiTask
{
    public function name(): string;          // 'headline.suggest'
    public function tier(): string;          // 'cheap' | 'standard' | 'premium'
    public function build(array $input): array;   // -> messages for the model
    public function parse(string $raw): array;    // -> validated structured output
}

That parse() method is the part teams skip and regret. A model that returns prose when you expected JSON is not an edge case — it's Tuesday. If every task is responsible for validating its own output, a bad response fails inside the task where you can retry or fall back, instead of leaking malformed data into the editor.

A concrete task looks like this:

final class HeadlineSuggestTask implements AiTask
{
    public function name(): string { return 'headline.suggest'; }
    public function tier(): string { return 'cheap'; }

    public function build(array $input): array
    {
        return [
            ['role' => 'system', 'content' =>
                'You are a Turkish news copy editor. Return exactly 3 headline '
                . 'options as a JSON array of strings. Max 70 characters each. '
                . 'No clickbait, no ALL CAPS.'],
            ['role' => 'user', 'content' => mb_substr($input['body'], 0, 4000)],
        ];
    }

    public function parse(string $raw): array
    {
        $data = json_decode($this->stripFences($raw), true);
        if (!is_array($data) || count($data) < 1) {
            throw new BadOutputException('headline.suggest: not a list');
        }
        return array_slice(array_map('strval', $data), 0, 3);
    }
}

Once you have one of these, you have the shape for fifty. The interesting work isn't writing the fiftieth task — it's the machinery around them.

Why "50+" is an architecture choice, not a brag

The number isn't the point; the granularity is. You could collapse "suggest headline," "suggest SEO title," and "suggest social blurb" into one mega-prompt that returns all three. Don't. Three reasons:

Different cost tiers. A category suggestion can run on a fast, cheap model. A legal-risk flag should not.
Different failure handling. If headline generation fails, you shrug and the editor types one. If entity tagging fails silently, your archive search quietly rots.
Different UX surfaces. The blurb belongs to the social scheduler; the alt text belongs to the image picker. Coupling them in one call couples two unrelated screens.

Small tasks compose. Big prompts calcify.

Here's the rough taxonomy that emerged — grouped, because grouping is how editors actually find them:

Group	Example tasks
Headlines & framing	headline options, SEO title, social blurb, push-notification text
Structure	summary/dek, key-points list, "read more" suggestions
Classification	category suggest, tag/entity extraction, topic clustering
Media	image alt text, caption draft, thumbnail crop hint
Quality & risk	tone check, defamation/risk flag, fact-claim highlighter, profanity filter
SEO & distribution	meta description, schema keywords, related-article linking
Language	translate dek, simplify, localize idiom

That's already 25+ before you count per-language and per-section variants. The registry is what keeps it from becoming chaos.

The registry and the router

The registry is boring on purpose: a name-to-task map. The router is where the one genuinely valuable idea lives — routing by tier, not by vibes.

final class AiRouter
{
    /** @param array<string, AiTask> $tasks */
    public function __construct(
        private array $tasks,
        private ModelGateway $gateway,
        private AiCache $cache,
    ) {}

    public function run(string $taskName, array $input): array
    {
        $task = $this->tasks[$taskName]
            ?? throw new UnknownTaskException($taskName);

        $key = $this->cacheKey($taskName, $input);
        if ($hit = $this->cache->get($key)) {
            return $hit;
        }

        $messages = $task->build($input);
        $raw      = $this->gateway->complete($task->tier(), $messages);

        try {
            $out = $task->parse($raw);
        } catch (BadOutputException $e) {
            // one retry on the next tier up before giving up
            $raw = $this->gateway->complete($this->escalate($task->tier()), $messages);
            $out = $task->parse($raw);
        }

        $this->cache->put($key, $out, $task->ttl());
        return $out;
    }
}

Three things are doing real work here and each earns its place:

Caching by (task, input) hash. The same article body gets a headline suggestion once. Editors click these buttons repeatedly; without a cache you pay for every nervous re-click. This single layer was the biggest cost reduction we measured.
Tier-based escalation on bad output. Cheap model first. If it returns garbage that fails parse(), retry once on a stronger tier. Most cheap-model failures are formatting failures, and they don't repeat on the better model. You get cheap-model economics with premium-model reliability on the tail.
The gateway hides the provider. complete(tier, messages) is the entire surface the task sees. Whether 'cheap' maps to one provider this month and another next month is an ops decision, not a code change in 50 tasks.

The gateway: one seam for every provider

The gateway is what makes provider diversity survivable. News work is bursty and rate limits are real, so you want the freedom to move a tier between providers without touching task code.

final class ModelGateway
{
    public function __construct(private array $tierConfig) {}

    public function complete(string $tier, array $messages): string
    {
        $cfg = $this->tierConfig[$tier];          // provider + model + limits
        $provider = ProviderFactory::make($cfg['provider']);

        return $provider->chat(
            model:    $cfg['model'],
            messages: $messages,
            maxTokens: $cfg['max_tokens'],
        );
    }
}

The payoff is operational, not architectural elegance for its own sake. When a provider degrades at 9 a.m. on an election morning — and it will — you change a config map, not a deployment. Keeping the model identity out of the task and in the tier config is the difference between a five-minute mitigation and a panic.

Quality gates: cheap models lie confidently

A specialized-task design tempts you toward cheap models everywhere, because each job is small. The trap is that small jobs still produce confidently wrong output. The defense is deterministic gates around non-deterministic output — code, not another model, checks the boring constraints.

function validateHeadlines(array $headlines): array
{
    return array_values(array_filter($headlines, function (string $h): bool {
        $len = mb_strlen($h);
        if ($len < 15 || $len > 70)           return false; // length contract
        if ($h === mb_strtoupper($h))          return false; // no ALL CAPS
        if (preg_match('/!{2,}|\?{2,}/', $h))  return false; // no "!!!"
        return true;
    }));
}

Notice there's no model in that function. The expensive judgment ("is this a good headline?") stays with the human editor. The cheap, mechanical judgment ("is this even a valid headline-shaped string?") is plain PHP that runs in microseconds and never hallucinates. Push every constraint you can express as code out of the prompt and into a gate. Prompts are for taste; code is for rules.

The one place to spend a premium model deliberately is risk — defamation, sensitive claims, anything where a wrong call has legal weight. That task should run on your strongest tier, never cache its "looks fine" verdict for long, and always present as advisory to a human. AI flags; people decide.

Asynchronous by default

Editors will not wait four seconds for a button. Anything slower than roughly a second belongs in the background, with the result arriving when it's ready rather than blocking the save.

// On save: enqueue, don't block.
$queue->push('ai.enrich', [
    'article_id' => $id,
    'tasks'      => ['summary.make', 'tag.extract', 'category.suggest', 'seo.meta'],
]);

// A worker drains the queue and writes suggestions back as drafts
// the editor can accept or ignore — never auto-published.

Two rules that saved us real pain:

Suggestions are drafts, never silent writes. AI output lands in a "suggested" state. A human accepts it. The day you let a model write directly to the published field is the day you explain a hallucinated dateline to your editor-in-chief.
Idempotent jobs. Queues retry. If summary.make runs twice, the second run should overwrite the same suggestion slot, not create a duplicate. Key the write by (article_id, task_name).

What I'd tell my past self

Model the task contract first, the prompt second. The interface outlives any specific model.
Validate output inside the task. Malformed responses are normal; treat them as control flow, not exceptions to your worldview.
Route by tier, cache by input. These two together did more for cost and reliability than any prompt-engineering cleverness.
Keep rules in code, taste in prompts. Every constraint you can check deterministically is one the model can't violate.
Async, advisory, idempotent. The newsroom trusts a tool that suggests and never surprises.

The "50+" isn't a feature count to put on a slide. It's what falls out naturally once each AI job is small enough to have a single clear contract. Build the seam — task, registry, router, gateway, gate — and adding the fifty-first workflow is an afternoon, not a project.

We've been refining this pattern in production news software at Alesta WEB, across publishers of very different sizes, and the lesson keeps repeating: the architecture, not the model, is what makes newsroom AI feel reliable instead of gimmicky.

KVKK, İYS, BİK: Turkish Software Compliance for Engineers (with PHP examples)

Mahmut Gündüzalp — Sun, 21 Jun 2026 12:45:03 +0000

If you build software that serves Turkish users, three acronyms will eventually land on your desk: KVKK, İYS, and BİK. They are not optional "nice to have" features — they are legal obligations with real fines attached. Yet most engineering write-ups about them are written by lawyers, for lawyers, and stop exactly where the interesting part begins: the code.

This is the article I wish I had when we first had to make 200+ production sites compliant. It's the engineer's view — what each rule actually requires from your application, and how to implement it cleanly in PHP. The examples are intentionally generic; adapt the storage and framework details to your own stack.

The three you'll meet

Acronym	Full name	What it governs	Who enforces it
KVKK	Kişisel Verilerin Korunması Kanunu	Personal data protection (Turkey's GDPR analogue)	KVKK Authority (KVKK Kurumu)
İYS	İleti Yönetim Sistemi	Commercial electronic messages (SMS/email/calls)	Managed via a central national registry
BİK	Basın İlan Kurumu	Press/news site requirements & official announcements	Basın İlan Kurumu (for news publishers)

KVKK touches almost every app. İYS hits you the moment you send a marketing message. BİK is specific to news publishers. Let's take them in order.

1. KVKK — personal data protection

KVKK shares its DNA with GDPR, so if you've done GDPR work the concepts will feel familiar: lawful basis, explicit consent, data minimization, the right to erasure, breach notification, and registration with a central inventory (VERBİS) once you cross certain thresholds.

The mistakes I see most often are not legal misreadings — they're engineering shortcuts. Three of them matter.

Separate consent from the action

A checkbox that says "I accept the terms and consent to marketing" bundles two different lawful bases. KVKK wants explicit, specific, unbundled consent. In practice that means storing each consent as its own record with enough metadata to prove it later.

// Each consent is its own row — never a single boolean on the user.
function recordConsent(int $userId, string $purpose, bool $granted): void
{
    $stmt = $pdo->prepare(
        'INSERT INTO consent_log
            (user_id, purpose, granted, ip, user_agent, created_at)
         VALUES (:uid, :purpose, :granted, :ip, :ua, :now)'
    );
    $stmt->execute([
        'uid'     => $userId,
        'purpose' => $purpose,                 // e.g. 'marketing_email', 'analytics'
        'granted' => $granted ? 1 : 0,
        'ip'      => $_SERVER['REMOTE_ADDR'] ?? '',
        'ua'      => substr($_SERVER['HTTP_USER_AGENT'] ?? '', 0, 255),
        'now'     => date('Y-m-d H:i:s'),
    ]);
}

The point of the ip, user_agent, and timestamp is not surveillance — it's that when someone asks "did this user actually consent, and when?", you can answer with evidence instead of a shrug. Consent is also revocable, so you append a new granted = 0 row rather than mutating the old one. The history is the proof.

The cookie banner has to actually block scripts

A banner that loads Google Analytics and the Meta pixel before the user clicks "accept" is theatre. Under KVKK (as under GDPR) non-essential trackers must not fire until consent exists. The cleanest implementation is to gate the script tags server-side:

function trackingScripts(int $userId): string
{
    if (!hasConsent($userId, 'analytics')) {
        return ''; // nothing loads, no third-party calls
    }
    return '<script src="/js/analytics.js" defer></script>';
}

If your analytics is purely first-party and aggregated (no cross-site identifiers, no PII), you have a much easier compliance story — which is one practical reason a lot of Turkish products lean toward self-hosted, first-party analytics.

Erasure means erasure (but keep the legal minimum)

The right to be forgotten collides with other obligations: you may be legally required to keep invoice and transaction records for years. The resolution is anonymization, not blind deletion. Strip the identifying fields, keep the financially/legally required skeleton.

function eraseUser(int $userId): void
{
    // Anonymize, don't orphan: invoices must survive for tax law.
    $pdo->prepare(
        "UPDATE users SET
            name='[deleted]', email=CONCAT('deleted_', id, '@invalid'),
            phone=NULL, address=NULL, anonymized_at=:now
         WHERE id=:id"
    )->execute(['now' => date('Y-m-d H:i:s'), 'id' => $userId]);

    // Hard-delete things with no retention requirement.
    $pdo->prepare('DELETE FROM consent_log WHERE user_id=:id')
        ->execute(['id' => $userId]);
}

Decide your retention periods deliberately, document them, and make them queryable. "We delete logs after N days" is a sentence you want to back with a cron job, not a hope.

2. İYS — the commercial message registry

İYS is the part that surprises foreign engineers. In Turkey there is a central national registry for commercial electronic message consent. Before you send a marketing SMS, email, or call to someone, their consent must exist in that registry — and your own database agreeing isn't enough on its own.

The engineering consequence: never send marketing straight from your app's consent table. You check İYS first. Transactional messages (order confirmations, password resets, shipping updates) are exempt — but the line between "transactional" and "marketing" is exactly where people get fined, so be conservative.

function canSendMarketing(string $recipient, string $channel): bool
{
    // 'channel' is one of: MESAJ (SMS), EPOSTA (email), ARAMA (call)
    $status = iysLookup($recipient, $channel); // calls the registry/integrator API

    // Only an explicit, active opt-in counts.
    return $status === 'ONAY';   // vs 'RET' (rejected) or 'ALICI_YOK' (unknown)
}

function sendCampaign(array $recipients, string $channel, string $message): void
{
    foreach ($recipients as $r) {
        if (!canSendMarketing($r, $channel)) {
            logSkipped($r, 'no_iys_consent');
            continue;            // skipping is cheaper than a fine
        }
        dispatch($channel, $r, $message);
    }
}

Two practical notes from running this at scale:

Sync both directions. When a user opts in or out in your UI, push that change up to the registry. When the registry changes (a user opts out there), pull it down. A nightly reconciliation job catches drift.
Cache lookups, but not forever. Hammering the lookup API per-recipient on a large campaign is slow and rude. A short-TTL cache (hours, not weeks) keeps you fast without letting stale "ONAY" values send messages to someone who opted out this morning.

3. BİK — for news publishers

If you don't run a news site, skip this section. If you do, BİK compliance is what stands between you and being eligible for official announcements (resmî ilan) and the credibility that comes with it.

BİK's requirements are more editorial than algorithmic, but several do translate into application features:

Mandatory imprint (künye): publisher identity, responsible editor, contact, and address must be present and reachable. This is a structured page, not a footer afterthought.
Source attribution (mahreç): agency-sourced content must be labelled with its origin. If you ingest from news agencies, carry the source field through your pipeline to the rendered article.
Content cadence & originality: a minimum flow of original editorial content, which in practice means your CMS needs solid authorship, scheduling, and audit metadata.
Archive integrity: published pieces should remain accessible and stable at their URLs.

The imprint and source-attribution pieces are the ones that bite teams late, because they're easy to bolt on at the end and easy to get subtly wrong. Model them as first-class fields from the start:

// Carry the source through to render — don't lose it in the import step.
function renderArticleMeta(array $article): string
{
    $out = '<div class="article-meta">';
    $out .= '<span class="author">' . e($article['author_name']) . '</span>';
    if (!empty($article['source_agency'])) {
        $out .= '<span class="source">Kaynak: '
              . e($article['source_agency']) . '</span>'; // mahreç
    }
    $out .= '<time datetime="' . e($article['published_at']) . '">'
          . e(formatTr($article['published_at'])) . '</time>';
    return $out . '</div>';
}

This is the kind of requirement that pushed our news CMS work toward treating source, author, and publish metadata as non-negotiable columns rather than optional extras — it's far cheaper than retrofitting attribution across an archive later.

A checklist you can paste into a ticket

[ ] KVKK: consent stored per-purpose, with timestamp + evidence, revocable as an append
[ ] KVKK: non-essential trackers gated server-side, fire only after consent
[ ] KVKK: erasure = anonymize-and-retain-legal-minimum, with documented retention periods
[ ] KVKK: VERBİS registration checked against your data-controller thresholds
[ ] İYS: registry lookup before every marketing send; transactional messages clearly separated
[ ] İYS: two-way sync (UI ⇄ registry) + nightly reconciliation + short-TTL cache
[ ] BİK: structured imprint (künye) page, reachable
[ ] BİK: source attribution (mahreç) carried end-to-end from import to render
[ ] BİK: stable article URLs and accessible archive

Closing thought

None of this is exotic engineering. It's mostly the discipline of modeling consent and provenance as data you can prove, not state you assume. Do it at the schema level on day one and compliance becomes a property of the system. Bolt it on at the end and it becomes a migration you'll dread.

We've shipped this pattern across 200+ Turkish production sites at Alesta WEB, and the single biggest lesson is the boring one: make consent and source first-class data, and the legal requirements mostly take care of themselves.

This is general engineering guidance, not legal advice — confirm specifics for your situation with a qualified professional.

How We Reduced LLM Costs by 95%: Cache + Batch + Cascade in PHP

Mahmut Gündüzalp — Sat, 13 Jun 2026 11:10:36 +0000

How We Reduced LLM Costs by 95%: Cache + Batch + Cascade in PHP

We build news software — a content platform used by more than 200 publishers at Alesta WEB. Once we wired language models into the newsroom workflow (headline suggestions, summaries, SEO fields, tag extraction, draft scaffolding), something predictable happened: the AI bill started growing faster than the feature list.

The naive version of "add AI" is a thin wrapper around one expensive frontier model, called fresh on every request. It works in a demo. In production, across thousands of articles a day, it's a slow way to set money on fire.

This is the architecture we settled on after eighteen months of running it. Three layers — cache, batch, cascade — plus the quality gates that make the cheap layers safe to rely on. The result was roughly a 95% reduction in per-task cost versus the naive "frontier-model-only, no cache" baseline, with no measurable drop in editorial quality.

The code is PHP, because the platform is PHP. The ideas are language-agnostic.

1. The Naive Approach (and What It Costs)

Here's the version almost everyone ships first:

function generateHeadline(string $articleBody): string
{
    $response = $client->chat([
        'model'    => 'gpt-4o',
        'messages' => [
            ['role' => 'system', 'content' => 'You write concise news headlines.'],
            ['role' => 'user',   'content' => $articleBody],
        ],
    ]);

    return $response['choices'][0]['message']['content'];
}

Nothing is wrong with this code. The problem is the usage pattern around it:

The same wire-service story gets posted by dozens of sites, so we generate near-identical headlines over and over.
Editors regenerate three or four times to compare options.
A frontier model is doing work — extracting tags, normalizing a category — that a model costing a fraction as much would do just as well.
Every call is synchronous and real-time, even when nothing about the task is urgent.

When you multiply "fresh frontier call every time" by real newsroom volume, the per-article AI cost lands somewhere that makes the CFO ask uncomfortable questions. Each of the three layers below attacks one of those waste sources.

2. Layer 1 — Cache: What to Cache, and What Not To

The single biggest win is the most boring one: don't ask the same question twice.

A large share of LLM calls in a news system are functionally identical. The key insight is that the cache key should be derived from the meaningful inputs — the task type, the model, the prompt template version, and a normalized hash of the content — not from the raw request object.

function cachedComplete(string $task, string $content, callable $compute): string
{
    $key = sprintf(
        'llm:%s:%s:%s',
        $task,
        PROMPT_VERSION[$task],          // bump to invalidate on prompt change
        hash('xxh128', normalize($content))
    );

    $hit = $cache->get($key);
    if ($hit !== null) {
        return $hit;                    // ~0 cost, sub-millisecond
    }

    $result = $compute($content);       // the actual API call
    $cache->set($key, $result, ttlFor($task));
    return $result;
}

function normalize(string $s): string
{
    // collapse whitespace, strip volatile boilerplate so trivially
    // different inputs map to the same key
    return trim(preg_replace('/\s+/u', ' ', $s));
}

Two details matter more than the cache engine you pick (we use Redis, but a database table works):

Version the prompt in the key. When you change a prompt template, you want every cached answer for that task to become a miss. Putting a PROMPT_VERSION constant into the key turns prompt edits into a clean, instant invalidation instead of a stale-output bug you chase for a week.

Know what not to cache. Anything personalized, anything real-time, anything where two identical inputs should legitimately produce different outputs (a "give me a fresh alternative" button) must bypass the cache. We mark those tasks explicitly rather than relying on TTL alone.

In our workload the cache hit rate sits around 60–70%, mostly because syndicated content repeats across sites. That one layer alone removes well over half the spend.

3. Layer 2 — Batch APIs: Trade Latency for Money

A surprising amount of LLM work in a newsroom is not time-sensitive. Nightly re-tagging of the archive. Generating summaries for the previous day's articles. Backfilling SEO descriptions on older content. None of it needs an answer in 800 milliseconds.

The major providers offer batch endpoints that run asynchronously — you submit a file of requests, and within a window (typically up to 24 hours) you get the results back, at roughly half the price of the synchronous API.

// Collect non-urgent jobs into a single batch submission
$lines = [];
foreach ($pendingJobs as $job) {
    $lines[] = json_encode([
        'custom_id' => $job->id,
        'method'    => 'POST',
        'url'       => '/v1/chat/completions',
        'body'      => [
            'model'    => $job->model,
            'messages' => $job->messages(),
        ],
    ]);
}

$batchFile = uploadJsonl(implode("\n", $lines));
$batch     = $client->batches()->create([
    'input_file_id'     => $batchFile['id'],
    'endpoint'          => '/v1/chat/completions',
    'completion_window' => '24h',
]);

// A worker polls for completion and writes results back by custom_id
$queue->later('poll_batch', ['batch_id' => $batch['id']], minutes: 15);

The discipline this forces is healthy: you have to classify each task as interactive (editor is waiting) or deferred (a cron job can handle it tonight). Once we did that audit, far more work turned out to be deferrable than we expected. Roughly a quarter of our remaining spend — after caching — moved onto batch pricing for a flat ~50% discount on that slice.

A caveat: batch pricing differs by provider, and so does the completion window and the failure behavior. Build your batch layer behind an interface so the provider is swappable, and always handle partial failures — a batch of 5,000 requests will occasionally return 4,997.

4. Layer 3 — Cascade Routing: Match the Model to the Task

The last layer is the one people resist, because it feels like cutting corners. It isn't — it's refusing to pay frontier prices for kindergarten work.

Not every task needs the smartest model. Extracting tags from a story, mapping a category, cleaning up whitespace, classifying sentiment — small, cheap models handle these perfectly. Reserve the expensive model for genuinely hard generation: nuanced summaries, editorial rewriting, anything where a mistake is visible to readers.

const TASK_TIER = [
    'tag_extraction'   => 'cheap',
    'category_map'     => 'cheap',
    'sentiment'        => 'cheap',
    'summary'          => 'mid',
    'headline'         => 'mid',
    'editorial_rewrite'=> 'frontier',
];

const TIER_MODEL = [
    'cheap'    => 'gpt-4o-mini',
    'mid'      => 'gpt-4o',
    'frontier' => 'the-strongest-model-you-trust',
];

function modelFor(string $task): string
{
    return TIER_MODEL[TASK_TIER[$task] ?? 'mid'];
}

We run six providers behind one interface (the editorial team never sees which one answered), which means cascade routing can also fail over: if a cheap model's output fails a quality gate, the task is automatically re-run one tier up. That gives you the cost of the cheap tier on the 90%+ of cases it handles well, and the safety of the expensive tier on the cases it doesn't.

Cascade routing is what takes you from "big savings" to "almost free for the easy majority."

5. Quality Gates: Keeping Cheap Models Honest

Cascade routing only works if you can detect when a cheap model got it wrong — otherwise you're trading money for garbage. Quality gates are cheap, deterministic checks that run on the output before it's accepted:

function passesGate(string $task, string $output): bool
{
    return match ($task) {
        'headline' => mb_strlen($output) <= 90
                      && !str_contains($output, "\n")
                      && !looksTruncated($output),

        'summary'  => mb_strlen($output) >= 100
                      && sentenceCount($output) >= 2,

        'tag_extraction' => isValidJsonArray($output),

        default    => $output !== '',
    };
}

None of these call an LLM. They're string length, format validity, structure checks — the kind of thing that costs nothing and catches the most common cheap-model failures (truncation, wrong format, empty output). When a gate fails, the cascade re-runs the task one tier up and logs it. If a particular task fails its gate too often, that's your signal to move it up a tier permanently.

This is the piece that makes the whole architecture trustworthy. Without gates, "use a cheaper model" is a gamble. With gates, it's a measured decision with an automatic safety net.

6. A Cost Dashboard You Actually Look At

You can't optimize what you don't measure. We log every LLM call with four fields: task, tier, whether it was a cache hit, and the token counts. That's enough to answer the only questions that matter:

Which task is costing the most? (Usually the surprise here is a "cheap" task being called a million times.)
What's our real cache hit rate, per task?
How often is the cascade escalating — and which tasks?

A weekly rollup of per-task economics turns cost control from a panic ("the bill doubled!") into a routine ("tag extraction escalation rate crept up, the prompt drifted, fix the template"). The dashboard is boring on purpose. Boring means in control.

7. The Numbers, After Eighteen Months

Against the naive baseline (one frontier model, every call fresh and synchronous), the layers compound:

Cache removes ~60–70% of calls outright.
Batch takes ~50% off a meaningful slice of what remains.
Cascade routes the easy majority of the rest to models costing a fraction of frontier prices.

Stacked, that lands at roughly 95% lower per-task cost for the same workload — and, because cache hits are instant and cheap models are fast, the median latency for AI features actually improved. Cheaper and faster, which is not the trade-off people expect when they hear "we cut the AI budget."

The editorial quality held because the expensive model still does all the work that's actually hard; we just stopped paying it to do the easy work.

8. What's Next: Prompt Caching

The newest lever we're rolling out is provider-side prompt caching — where a long, stable system prompt (style guide, formatting rules, examples) is cached on the provider's side and billed at a steep discount on repeat calls. For a news system with a large, rarely-changing editorial style prompt prepended to thousands of calls, that's a natural fit on top of the three layers above.

The throughline across all of it is the same: a language model is a power tool, not a default. Cache the repeats, defer what isn't urgent, route easy work to cheap models, and verify cheap output with checks that cost nothing. Do that, and AI features stop being a line item that scares the finance team and go back to being what they should be — a feature.

We build news software used by 200+ publishers — agency integration, AI-assisted editorial workflows, native mobile apps, and subscription infrastructure. More on the platform at alestaweb.com.

Schema.org NewsArticle: A Complete Implementation Guide for Google News in 2026

Mahmut Gündüzalp — Sun, 31 May 2026 23:00:47 +0000

Schema.org NewsArticle: A Complete Implementation Guide for Google News in 2026

Most news sites that fail to get into Google News don't fail because of their content. They fail because their structured data is wrong, incomplete, or missing — and nobody told them, because the failure is silent. No error, no email, just no traffic.

This is a field guide to getting NewsArticle structured data right. It comes from running it across 200+ production news portals over the last 18 months at Alesta WEB, where a single malformed datePublished field can quietly drop a story out of the news index for a publisher who has no idea why.

I'll cover every field that matters, the publisher markup that ties it together, the news sitemap's brutal 48-hour window, how AMP and canonical interact in 2026, IndexNow for instant Bing/Yandex pickup, and the validation pipeline we run before anything ships.

1. Why Structured Data Matters Beyond Google

It's tempting to think of NewsArticle JSON-LD as "the thing Google wants." It is, but that framing undersells it.

Structured data is now the machine-readable contract for your content across the entire discovery layer: Google News and Top Stories, Bing News, the knowledge graphs that feed voice assistants, and — increasingly — the LLMs that summarize current events. When a model is asked "what happened in city X today," it leans on sources whose articles are cleanly typed, dated, and attributed. Ambiguous HTML doesn't get parsed reliably. Clean JSON-LD does.

So the payoff isn't one channel. Getting NewsArticle right is the cheapest single thing you can do to make a story legible to every automated consumer at once.

2. NewsArticle: Every Field That Matters

Here is a complete, valid NewsArticle block. I'll annotate the fields that people get wrong.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/news/city-council-approves-budget"
  },
  "headline": "City Council Approves 2026 Budget After Three-Hour Debate",
  "image": [
    "https://example.com/img/budget-16x9.jpg",
    "https://example.com/img/budget-4x3.jpg",
    "https://example.com/img/budget-1x1.jpg"
  ],
  "datePublished": "2026-06-01T08:30:00+03:00",
  "dateModified": "2026-06-01T09:15:00+03:00",
  "author": {
    "@type": "Person",
    "name": "Ayşe Yılmaz",
    "url": "https://example.com/author/ayse-yilmaz"
  },
  "publisher": {
    "@type": "NewsMediaOrganization",
    "name": "Example Daily",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo-600x60.png",
      "width": 600,
      "height": 60
    }
  },
  "description": "The council passed the budget 7-4 after debate over transit funding.",
  "articleSection": "Local",
  "inLanguage": "en"
}
</script>

The fields people break, in order of how often I see them broken:

datePublished without a timezone. This is the number one cause of silent failure. "2026-06-01T08:30:00" is ambiguous. Google may interpret it as UTC, your server may mean local time, and the gap can push a story outside the freshness window or make it look hours old at publication. Always include the offset: +03:00, Z, whatever is correct — but never omit it.

dateModified going backwards or matching publish exactly forever. If you genuinely edit an article, update dateModified. But don't fake it by bumping it on every page load — Google notices articles whose modification date changes without content changing, and it erodes trust. Set it when the content actually changes.

headline over 110 characters. Google truncates and may ignore long headlines for Top Stories. Keep it under 110 characters. This is a hard, documented limit, not a suggestion.

image with a single small image. Provide multiple aspect ratios (16x9, 4x3, 1x1) at a minimum width of 1200px. A 600px-wide thumbnail disqualifies you from large image treatment in Top Stories.

author.url missing. An author object with just a name is weak. Give every author a real, crawlable profile page and link it via url. This is also an E-E-A-T signal — the author needs to be a verifiable entity, not a string.

3. NewsMediaOrganization: The Publisher Half

The publisher inside each article should be a NewsMediaOrganization, and that organization should also exist as a standalone entity on your home page or a dedicated /about page. The two reinforce each other.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsMediaOrganization",
  "name": "Example Daily",
  "url": "https://example.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://example.com/logo-600x60.png",
    "width": 600,
    "height": 60
  },
  "sameAs": [
    "https://twitter.com/exampledaily",
    "https://www.facebook.com/exampledaily"
  ],
  "diversityPolicy": "https://example.com/diversity-policy",
  "ethicsPolicy": "https://example.com/ethics-policy",
  "masthead": "https://example.com/masthead"
}
</script>

The logo constraints trip people up: it must be a raster format (PNG/JPG, not SVG), no wider than 600px, and no taller than 60px. The ethicsPolicy, diversityPolicy, and masthead properties are optional but they are genuine trust signals for news specifically — having real pages behind them helps with Google News eligibility reviews.

One rule we enforce in production: the publisher name and logo must be byte-identical across every article and the organization entity. Inconsistency here — "Example Daily" in one place, "ExampleDaily" in another — is read as two different publishers.

4. Sitemap-news.xml: The 48-Hour Window

A news sitemap is not a regular sitemap. It only lists articles published in the last 48 hours, and it carries extra <news:news> metadata.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:news="http://www.google.com/schemas/sitemap-news/0.9">
  <url>
    <loc>https://example.com/news/city-council-approves-budget</loc>
    <news:news>
      <news:publication>
        <news:name>Example Daily</news:name>
        <news:language>en</news:language>
      </news:publication>
      <news:publication_date>2026-06-01T08:30:00+03:00</news:publication_date>
      <news:title>City Council Approves 2026 Budget After Three-Hour Debate</news:title>
    </news:news>
  </url>
</urlset>

Two things make or break this:

Drop articles older than 48 hours. Leaving stale URLs in the news sitemap is a quality signal against you. The sitemap must be generated dynamically and prune itself. We regenerate ours on publish and on a short cron, never as a static file.

news:publication_date must match datePublished. Same timezone, same value. If your JSON-LD says one time and your sitemap says another, you've told Google two contradictory things about the same article.

5. AMP vs Canonical in 2026

This used to be a real decision. In 2026 it mostly isn't.

Google dropped the AMP requirement for Top Stories back in 2021, and Core Web Vitals became the actual gate. If your canonical pages are fast — good LCP, low CLS, responsive — you do not need AMP to appear in Top Stories. We removed AMP from most sites and saw no ranking loss, plus we deleted an entire parallel rendering path and its bugs.

The honest guidance:

Default: ship fast canonical HTML, no AMP. One source of truth, less to maintain.
Keep AMP only if you have a specific downstream consumer that still requires it, or your canonical pages genuinely can't hit good Core Web Vitals and you can't fix the root cause.

If you do serve both, the canonical page must point to itself with rel="canonical", and the AMP page must point back to the canonical with rel="canonical". Getting that backwards is a common way to deindex your real pages.

6. IndexNow: Instant Pickup on Bing and Yandex

Google still crawls on its own schedule. Bing and Yandex, however, accept a push: IndexNow lets you notify them the instant an article goes live, instead of waiting for a crawl.

The setup is trivial. Host a key file at your root, then POST URLs on publish:

# 1. Host the key at https://example.com/<key>.txt containing just the key
# 2. On every publish, ping:
curl "https://api.indexnow.org/indexnow?url=https://example.com/news/city-council-approves-budget&key=<key>"

Or submit a batch as JSON:

{
  "host": "example.com",
  "key": "your-key-here",
  "urlList": [
    "https://example.com/news/article-1",
    "https://example.com/news/article-2"
  ]
}

For a news site where being first matters, the minutes you save on Bing/Yandex indexing are real. We wire IndexNow into the same publish hook that regenerates the news sitemap — one event, both actions.

7. A Validation Pipeline That Catches Errors Before Deploy

Hand-checking structured data doesn't scale past a few articles. Across hundreds of sites it has to be automated, and it has to run before content reaches users.

What our pipeline checks on every article render in staging:

JSON-LD parses. A trailing comma silently disables the whole block. Parse it as JSON; fail the build if it throws.
Required fields present. headline, image, datePublished, author, publisher — assert each exists and is non-empty.
datePublished has a timezone offset. Regex-reject any ISO timestamp without Z or ±HH:MM.
headline ≤ 110 characters.
image width ≥ 1200px (check the actual asset, not just the URL).
Publisher name/logo match the canonical organization entity.
Sitemap date == JSON-LD date for the same URL.

A minimal version of check 3, the highest-value one:

function assertHasTimezone(string $iso): void
{
    if (!preg_match('/(Z|[+\-]\d{2}:\d{2})$/', $iso)) {
        throw new RuntimeException("datePublished missing timezone: $iso");
    }
}

Beyond the build, use Google's Rich Results Test and the schema.org validator on a sample of live URLs weekly. The build catches structural errors; the external validators catch the rules Google changes without announcing.

8. Passing vs Failing: A Side-by-Side

Failing markup — and why:

{
  "@type": "NewsArticle",
  "headline": "City Council Approves The 2026 Municipal Budget After A Long And Contentious Three-Hour Public Debate Session",
  "datePublished": "2026-06-01 08:30:00",
  "author": "Ayşe Yılmaz",
  "image": "https://example.com/thumb.jpg"
}

Four problems: headline over 110 chars, datePublished with no timezone and a space instead of T, author as a bare string instead of a Person object with a URL, and a single thumbnail-sized image. Each one individually can keep this out of Top Stories.

Passing markup is the full block from section 2: typed author with a profile URL, ISO-8601 date with offset, headline under the limit, and multiple large images. The difference between these two blocks is the difference between being indexed and being invisible.

Wrapping Up

NewsArticle structured data isn't glamorous, but for a news publisher it's the highest-leverage SEO work there is. The content is yours to write; the markup is what makes machines trust it.

Get the five required fields right, give every date a timezone, keep your news sitemap pruned to 48 hours, push to IndexNow on publish, and validate before you deploy. Do that consistently and the silent failures stop being silent — they stop happening.

If you run a single site, do this by hand once and template it. If you run many, build the validation pipeline first. We learned the hard way that across 200+ portals, the cost of one wrong datePublished format multiplied by every article is a traffic problem you'll spend weeks tracing back to one missing +03:00.

Haber yazilimi, haber scripti, haber sistemi: ayni urun, uc ayri arama niyeti

Mahmut Gündüzalp — Tue, 26 May 2026 00:50:55 +0000

TL;DR

Turkce yazilim pazarinda haber yazilimi, haber scripti ve haber sistemi terimleri cogunlukla ayni urunu tanimlar: bir haber portalini yoneten icerik yonetim sistemi. Vurgu farklidir, paket icerik ayni olabilir. Bu yazi uc terim arasindaki ince farki, yayincilarin hangisini ne zaman aradigini ve modern bir haber CMS'inde olmasi gereken ozellikleri anlatir.

Neden bu kadar cok terim?

Turkce arama davranisi yabanci dillerden farklidir. Ingilizcede "news CMS" veya "news publishing platform" dominanttir. Turkcede ayni urun icin uc ayri Google sorgusu yapilir:

Sorgu	Aylik Trafik (kabaca)	Niyet
haber scripti	~2.000	Kod tabanli paket arayan
haber yazilimi	~1.500	Butuncul cozumu arayan
haber sistemi	~700	Kurumsal yayin sistemi arayan

Uc terim de pratikte ayni tedarikciye yonelir, ama yayincilar urunu farkli adlandirir.

Uc terim arasindaki ince fark

Haber scripti

Mevcut bir altyapidan baska bir altyapiya gecmek isteyen yayincilarin terimidir. "X haber scripti satin aldim, ozellestirdim, sunucuya yukledim" tarzi kullanim. PHP/MySQL ile yazilmis, kod tabanini gormek, ozellestirmek isteyen IT departmanlarinin/teknik sahiplerin tercihi.

Haber yazilimi

Yeni bir haber portali kurmak isteyen yayincilarin terimidir. Sadece kod degil, paket (mobil uygulama, sunucu, kurulum, destek, egitim) dahil. Genelde son musteri (yayinci) terminolojisi.

Haber sistemi

Cok yazarli, cok rolu, surec yonetimi gerektiren kurumsal yayinlarin terimidir. Editor onayi, yetkilendirme matrisi, raporlama, istatistik bekleyen yayinlar "haber sistemi" der. Buyuk yayin kuruluslari ve kurumsal sirketler bu terimi tercih eder.

Hangisini ne zaman aramaliyiz?

Yeni bir yayin acacaksam        -> haber yazilimi (butuncul paket)
Mevcut yayinda kod degistirecegim -> haber scripti (kod tabani)
Kurumsal yayin yonetecegim      -> haber sistemi (operasyonel iskelet)

Uc senaryoda da musterinin aradigi ozelliklerin %90'i ayni tedarikci tarafindan ayni paketle saglanir.

Modern bir haber CMS'inde olmasi beklenen ozellikler

Yayincilarin 2026 sonrasinda bekledigi temel modullerin listesi:

Icerik

Cok tipli icerik: haber, video, galeri, makale, etkinlik, podcast, biyografi, vefat ilani
Ajans entegrasyonu: AA, DHA, IHA, ANKA, THA, HIBYA, IGFA, BHA gibi haber ajanslarindan otomatik haber cekme
AI ile icerik uretimi: GPT, Gemini, Claude, DeepSeek, Groq gibi modeller ile haber yazma, baslik onerme, ozetleme

SEO ve gorunurluk

Google News uyumu: sitemap-news.xml, NewsArticle Schema
AMP destegi: Hizli mobil gorunum
AI Overview optimizasyonu: FAQPage Schema, llms.txt, ai-sitemap.xml
IndexNow API: Anlik indeksleme (Bing + Yandex)

Mobil

Native uygulama: iOS + Android (kurulum + uygulama magazasi yayini dahil)
PWA destegi: Offline okuma
Push bildirim: OneSignal veya benzeri

Operasyonel

Cok yazarli panel: Editor, yazar, yonetici rolleri
Abonelik / Paywall: Premium icerik kapatma (iyzico, PayTR vb. odeme)
Reklam yonetimi: AdSense, banner pozisyonlari
Newsletter / E-bulten

Performans ve guvenlik

Cache katmanli: Redis + dosya cache + CDN
Gorsel optimizasyon: WebP otomatik donusum, lazy loading
Guvenlik: CSRF, XSS, IP banlama, rate limiting
SSL/TLS: Let's Encrypt veya benzeri

Karar matrisi

Yayinciliga baslayacak biri tedarikci sectiginde bakmasi gerekenler:

Ihtiyac	Bakilacak ozellik
Yerel haber portali	Haber ajansi entegrasyonu + reklam
Kurumsal yayin	Cok yazar yonetimi + raporlama
Yuksek trafik	Cache + CDN + mobil
Premium icerik	Abonelik / Paywall modulu
Google News basvurusu	NewsArticle Schema + sitemap-news
AI ile icerik uretimi	Coklu AI saglayici destegi

Lisans modelleri

Pazarda iki ana lisans modeli vardir:

Tek seferlik lisans: Bir kerelik odeme, kaynak kod erisimi, surekli kullanim hakki. Uzun vadede daha ekonomik.
Aylik abonelik (SaaS): Sunucu + yazilim + destek paket halinde aylik odeme. Daha az baslangic maliyeti.

Buyuk yayinlar genelde tek seferlik lisansi tercih eder cunku ozellestirme ve kontrol istemektedir. Kucuk/orta yayinlar baslangic maliyeti dusuk oldugu icin SaaS modellerini secebilir.

Sik sorulan sorular

S: Ucretsiz haber scripti var mi?
C: Acik kaynak haber scriptleri vardir ama kurumsal yayinlar lisansli paketi tercih eder cunku haber ajansi entegrasyonu, AI modulleri ve uzun vadeli destek gerekir.

S: Hangi sirket en iyi haber yazilimini sunar?
C: Yayinin buyuklugune ve ozelliklerine gore degisir. Onemli olan tedarikcinin ozellestirme yapabilmesi, ajans entegrasyonuna sahip olmasi ve uzun vadeli destek vermesidir. Alesta WEB 2005ten beri bu pazarda hizmet veren bagimsiz tedarikcilerden biridir.

S: Mobil uygulama haber yaziliminin parcasi mi?
C: Modern haber yazilimlari iOS/Android native uygulama veya en az PWA olarak gelir.

S: Haber sitesi acmak icin SEO ne kadar onemli?
C: Hayati. Yayinin %60+ trafigi organik aramadan gelir. NewsArticle Schema, sitemap-news, AMP ve Google News uyumu olmazsa olmaz.

Sonuc

Turkcede "haber yazilimi", "haber scripti" ve "haber sistemi" terimleri ayni urunu uc ayri arama niyetiyle tanimlar. Yayincinin niyeti farkli olsa da tedarikci genelde ayni paketi sunar. Tedarikci secerken paketin sundugu modullerin (haber ajansi entegrasyonu, AI ile icerik, mobil uygulama, SEO, paywall) ihtiyaca uygunluguna bakmak gerekir.

Detayli karsilastirma ve canli demo icin: Alesta WEB Haber Scripti veya Haber Yazilimi Pillar Sayfa

Kaynak: Alesta WEB - 2005ten beri haber yazilimi, e-ticaret yazilimi ve kurumsal web cozumleri.

Turkish E-commerce: Why Local POS Integration Beats Stripe (Most of the Time)

Mahmut Gündüzalp — Sun, 24 May 2026 11:33:36 +0000

Turkish E-commerce: Why Local POS Integration Beats Stripe (Most of the Time)

If you're an English-speaking developer building e-commerce in any market, your default payment integration is Stripe. It's a great default. It's documented, it's fast to integrate, it has SDKs for every language, and the API surface is among the cleanest in the industry.

It's also the wrong default if your customers live in Turkey.

This is a write-up of what we learned running 200+ production e-commerce sites in Turkey over the last 18 months: why Stripe alone doesn't cut it, what the local payment landscape actually looks like, the unified interface pattern we use to manage 15+ bank gateways from a single PHP codebase, and the cost numbers that justify all the extra engineering work.

1. The Stripe Assumption (And Why It Breaks Here)

Stripe operates in Turkey. You can technically take TRY payments through Stripe. So why isn't that the end of the story?

Three reasons, in order of weight:

Reason 1: Transaction fees compound. Stripe charges around 1.4% + ₺1.40 per successful card transaction in TRY, with currency conversion and cross-border markups stacking on top in some flows. A native bank virtual POS gateway typically charges 0% transaction fee — the bank takes its cut from the merchant agreement at the bank level, not per-transaction. For a store doing ₺2M/year in volume, that's roughly ₺28,000/year that doesn't have to leave the merchant.

Reason 2: Installments (taksit) are a feature, not a payment method. Turkish consumers expect to see "3 ay taksit ile ₺X" alongside every product price. Installment plans are negotiated between the merchant and the issuing bank — each bank has its own installment rules, its own commission tiers, and its own "premium" cards that get extended installments. Stripe has no equivalent surface for this. You can simulate installments with a recurring subscription, but that's not what customers see at checkout, and conversion drops accordingly.

Reason 3: TRY-native ledger. Stripe settles internationally; even when collecting in TRY, the reconciliation layer is built around a multi-currency model that assumes you'll eventually want to convert. Most Turkish merchants want a Turkish lira ledger that matches their e-fatura (e-invoice) records line-for-line, with VAT broken out the way GİB (Turkish tax authority) expects it. Native bank POS does this natively.

The combined effect: Stripe works, but it bleeds money on transaction fees, kills your installment funnel, and adds a reconciliation step that your accountant doesn't want.

2. The Local Payment Landscape

Here's the actual list of payment surfaces a serious Turkish e-commerce store needs to support, at minimum:

Tier-1 bank virtual POS (direct integration with the issuing bank):

Garanti BBVA
İş Bankası
Akbank
Ziraat Bankası
Halkbank
VakıfBank
Yapı Kredi
TEB
DenizBank
QNB Finansbank

Tier-2 payment aggregators (one integration, many banks underneath):

iyzico (Visa-owned, biggest player)
PayTR
Param
Moka
Paycell (Turkcell)
Sipay
Hepsipay (Hepsiburada-owned)

Tier-3 alternative methods:

Papara (Turkish digital wallet)
BKM Express (interbank wallet)
Apple Pay / Google Pay (over local processors)
Cash on delivery (still ~15% of orders in some categories)
Bank transfer with auto-matching (havale eşleştirme)

That's 15+ direct gateways and at least 5 alternative payment surfaces. Realistically, a mature Turkish store integrates 5-8 of these — but the engineering problem is that any one of them might be the cheapest path on a given transaction, depending on the buyer's card BIN and the merchant's bank agreement.

3. The Interface That Unifies Them All

The architectural problem looks scary the first time you face it: 15 different APIs, 15 different XML/JSON formats, 15 different 3-D Secure callback patterns, 15 different error code sets, 15 different "test card" lists.

The solution we converged on (and which I'd recommend to anyone hitting this problem) is the classic adapter pattern: one interface, one set of value objects, one error taxonomy. Each gateway gets an adapter class.

interface PaymentGatewayInterface
{
    public function getCode(): string;
    public function getDisplayName(): string;

    public function preparePayment(PaymentRequest $req): PaymentPrepared;

    public function handleThreeDSCallback(array $callback): ThreeDSResult;

    public function captureAuthorized(string $txRef, Money $amount): CaptureResult;

    public function refund(string $txRef, Money $amount, ?string $reason = null): RefundResult;

    public function getInstallmentOptions(string $cardBin, Money $amount): array;
}

The PaymentRequest value object normalizes the input across all gateways: card BIN, amount in TRY minor units, installment count, merchant order reference, return URLs, customer billing address. Same call signature, regardless of which bank is on the other end.

Each adapter implementation translates this normalized request into whatever the bank expects — usually XML over HTTPS for tier-1 banks, JSON for aggregators, sometimes WSDL/SOAP for legacy stacks. The translation layer is the boring part. The interesting part is the next section.

4. 3-D Secure Callback: Handling 15 Different Protocols

3-D Secure is a regulatory requirement on most card transactions in Turkey since 2020. The flow looks the same from the customer side — you redirect to the bank, the customer enters an SMS code, they redirect back — but the integration side varies wildly.

Concrete differences across providers:

Callback method: POST vs GET vs both. iyzico does POST. Some legacy banks do GET. Some do POST but expect you to verify a hash on the next page load.
HMAC verification: SHA1, SHA256, SHA512, sometimes a custom hash with secret prefix. Order of fields in the hash payload matters and isn't always documented.
Status field naming: mdStatus, status, result, tdStatus, auth_result — different vocabulary, sometimes different value sets.
Status semantics: "1" can mean "3-D Secure success, proceed to auth" on one gateway and "fully authorized, capture done" on another. Confusing the two will silently capture funds without finishing 3-D, which is a compliance violation.

The pattern that saved us was a per-gateway ThreeDSValidator class that returns a normalized ThreeDSResult enum:

enum ThreeDSOutcome:
  AUTHORIZED            // captured, money on its way
  AUTHENTICATED_ONLY    // 3-D passed, auth still pending
  CHALLENGE_REQUIRED    // friction beyond 3-D (rare)
  REJECTED              // explicit fail
  TIMEOUT               // no response, treat as fail
  TAMPER_DETECTED       // HMAC failed, log + alert

The order routing layer doesn't care which bank just called us back. It cares only about which of those six outcomes happened. That decoupling is the single most valuable thing in the whole stack — it means adding a new gateway is a 200-line adapter and a test fixture, not a redesign.

5. Real Cost Comparison: Stripe vs Native (3-Year Data)

Numbers from a representative mid-sized merchant in our portfolio. Online fashion, ~₺3.2M annual volume, average basket ₺240, ~13,300 orders/year. Card mix: 78% Turkish-issued credit, 18% Turkish debit, 4% international.

Scenario A — Stripe-only:

Transaction fee: 1.4% + ₺1.40 on Turkish cards (after volume discount). Roughly ₺44,800 + ₺18,620 = ₺63,420/year in transaction fees.
Foreign cards (4%, ~₺128k volume): 2.9% + ₺2 = ₺3,712 + ₺1,064 = ₺4,776
Installment funnel: not available natively. Either skipped (conversion drops ~12-18% on baskets over ₺1,000) or hacked via off-platform subscription (compliance grey area).
Reconciliation: TRY/USD ledger split, manual e-invoice mapping.

Scenario B — iyzico + 4 direct bank gateways (Garanti, İş, Akbank, Ziraat):

Aggregator fee on iyzico-routed transactions (~30% of volume): 2.4% blended ≈ ₺23,040/year
Direct bank fees on routed transactions (~70% of volume): 0% transaction, bank takes monthly fixed fee ≈ ₺18,000/year total across 4 banks
Installment funnel: full native, all banks expose their installment offers
Reconciliation: TRY-native, line-for-line with e-arşiv records
Total: ₺41,040/year

Difference: ₺27,156/year in direct fees, plus the conversion lift from installments — which on this volume mix is worth roughly another ₺180-220k in additional revenue.

The catch is the engineering investment. Building and maintaining the gateway layer is real work — call it 60-80 engineering days for the first build, plus 10-15 days/year of maintenance as banks shuffle their APIs. For merchants under ~₺1M annual volume, Stripe is genuinely the right call: the savings don't outrun the engineering cost. Above that line, native wins, every time.

6. When Stripe Still Wins

Honest take: there are still cases where Stripe is the right answer even in Turkey.

You sell mostly to non-Turkish customers in TRY (export-heavy stores, language schools selling to expats). Stripe's multi-currency surface is genuinely useful, and you don't need installments.
You're pre-product-market-fit. Don't sink 60 days into a payment layer when you're not sure anyone wants to buy. Ship with iyzico (one integration, decent coverage) and migrate later if volume justifies it.
You operate B2B with invoice-based settlement. Card transactions are a tiny fraction of revenue; the payment gateway is not your bottleneck.
You're on a serverless/SaaS PHP-incompatible stack where the maintenance overhead of bank adapters falls on a team that doesn't have Turkish-language docs comprehension. Hiring local engineers for that is more expensive than the fees.

For everyone else — every Turkish-market store with national reach and >₺1M volume — local POS is not optional. It's table stakes.

7. Conclusion: Local Fintech Isn't Optional

The mistake we made early on was treating Turkish payments as "Stripe with a TRY currency code." That mental model produces a working store and a slowly bleeding P&L. The right mental model is: this is a market with its own payment culture, its own regulatory frame, and its own gateway ecosystem, and the engineering effort to plug into it is one of the highest-ROI investments a Turkish e-commerce engineering team can make.

If you're starting fresh, build the adapter layer from day one even if you only ship with one gateway initially. The interface costs almost nothing to write up front. Retrofitting it later — when your order layer has direct calls to iyzico_client->charge() scattered across 40 files — is the part that's painful.

For more on the broader Turkish e-commerce engineering stack (CMS, bot integrations, AI cost optimization), see my earlier post on building a multi-LLM news CMS and the React-to-HTMX migration writeup. Same production stack, different surface.

Working on Turkish e-commerce or news CMS infrastructure? I run Alesta WEB, an Şanlıurfa-based software shop building this kind of platform for the Turkish market since 2005. Happy to compare notes.

Why We Switched from React to HTMX in Production: A 200-Site Case Study

Mahmut Gündüzalp — Sat, 23 May 2026 09:19:58 +0000

We ran a React SPA admin panel for almost three years. It worked. Customers logged in, edited content, published articles. Bundle size kept creeping up. Build times kept creeping up. A new dev needed two weeks to be productive. We started skipping minor features because "the diff is too risky."

In Q3 2025 we migrated that panel to HTMX over six months, route by route. This post is the honest version of how it went — what worked, what we didn't see coming, and the numbers from running both stacks side by side across more than 200 production deployments.

The React tax in 2026

Let me get one thing out of the way: React isn't broken. It's a fine tool for the workloads it was designed for. Our admin panel was not one of those workloads. Most of our screens are forms, lists, and modal dialogs. The fanciest interaction is drag-to-reorder. The actual user count per tenant is small — usually 1 to 5 editors per site.

For that, here's what React was costing us:

Bundle size: ~800 KB gzipped after route-splitting, three vendor bundles, three lazy chunks
First admin login LCP: 3.0s to 3.5s depending on region (we serve from a single Istanbul edge)
Build time: 90 seconds for production, 8 seconds for dev rebuild
Onboarding: new hires needed 10–14 days before they could ship a self-contained feature
Tooling churn: in three years we went through three state management libraries and two router majors

None of these are dealbreakers in isolation. Stacked together, they made every small change expensive. We were paying SPA prices for a CRUD app.

Why HTMX caught our attention

The pitch is one line: HTMX lets any element issue an AJAX request and swap the response into the DOM. There's no client-side router, no virtual DOM, no build step required. You render HTML on the server (we use Smarty 5), the browser swaps fragments, the network does the heavy lifting.

What sold us wasn't the elegance of the demo. It was a 40-minute spike where one engineer rebuilt our "edit article" screen — form, validation, autosave, image upload — in 180 lines of HTML + a thin PHP controller. The React version was 1,400 lines across 9 files.

The interesting part: the HTMX version felt faster, and was. No JS bundle to parse, no hydration step. The TTI was essentially the same as the LCP because there was nothing to hydrate.

Migration strategy: parallel routes, no big bang

We've been burned by big-bang rewrites before. This time we did parallel routes:

Both stacks live in the same admin panel. Old routes (/admin/old/*) keep serving React. New routes (/admin/*) serve server-rendered HTML with HTMX.
A shared session cookie means a user can be in the middle of editing in React, click a sidebar link, and land in the HTMX side without re-authenticating.
We migrated one feature per sprint, easiest first (read-only lists), hardest last (the article editor with WYSIWYG).
After each feature shipped, we deleted the React route and the JS that supported it. Bundle size dropped in steps — that visibility kept morale up.
The cutover wasn't a date on the calendar. It was the moment the React bundle hit zero. That happened in week 22.

The "no big bang" rule matters. If we'd tried to ship the whole panel in one PR, we wouldn't have shipped at all.

Three patterns we use everywhere

Most of the panel is built from three patterns. If you understand these, you understand 80% of an HTMX codebase.

1. Form submit with inline validation

<form hx-post="/admin/articles"
      hx-target="#form-result"
      hx-swap="outerHTML">
  <input type="text" name="title" required>
  <textarea name="body"></textarea>
  <button type="submit">Save</button>
  <div id="form-result"></div>
</form>

Server returns either a success fragment or the same form re-rendered with inline error messages. No client-side validation library. No form library. The server is the single source of truth.

The win: we deleted ~5,000 lines of duplicated client-side validation that was always one schema change away from drifting from the server.

2. Infinite scroll for long lists

<div id="article-list">
  <article>...</article>
  <article>...</article>
  <div hx-get="/admin/articles?page=2"
       hx-trigger="revealed"
       hx-swap="outerHTML">
    Loading...
  </div>
</div>

The sentinel div triggers when scrolled into view, fetches the next page, and replaces itself with the next batch (plus a new sentinel). One pattern, every long list. No virtual scrolling library, no IntersectionObserver setup code in userland.

For lists over ~10,000 items we still reach for virtual scrolling, but those are rare in an admin context.

3. Modal dialogs with hx-target

<button hx-get="/admin/articles/42/edit"
        hx-target="#modal"
        hx-trigger="click">
  Edit
</button>

<div id="modal"></div>

The server returns the modal markup including a <dialog> element with open. To close, the modal posts back and returns an empty fragment that replaces itself. State of the dialog lives on the server.

This one took the longest to internalize. The instinct from React land is to manage modal state in a store. With HTMX, the modal is just a fragment of HTML that the server hands you when you ask for it.

The numbers, after six months

Metric	React (before)	HTMX (after)	Delta
Admin bundle (gzipped)	800 KB	~50 KB	–94%
LCP (Istanbul, p75)	3.2s	1.1s	–66%
TTI (Istanbul, p75)	4.1s	1.2s	–71%
Production build time	90s	6s	–93%
Dev rebuild	8s	<1s	–
Backend response p95	180ms	220ms	+22%
Total admin LOC	~42,000	~28,000	–33%
Dev onboarding (days)	10–14	3–5	–

A few things worth calling out:

The 50 KB on the HTMX side is HTMX itself plus a tiny amount of our own glue code (~600 lines). No build pipeline required, though we keep a Vite step for CSS bundling.

Backend response time went up. That's not free — server rendering moved work from the client to the server. We mitigated with aggressive caching of partials (Smarty + Redis), but the trade is real: you pay in server CPU what you save in client work.

The LOC drop surprised us. We expected maybe 10–15%. The 33% came mostly from deleting client-side mirrors of server state — form models, validation, optimistic update logic.

Where HTMX falls short — real talk

This is the section I wish more "we switched to X" posts included.

Offline support is gone. If you need a panel that works on a flaky connection, HTMX is the wrong tool. Every interaction is a network round-trip.

Complex client interactions get awkward. We have one screen — a drag-and-drop tree editor for category hierarchy — that's still React. HTMX can do drag-and-drop with sortable.js, but the round-trip-per-drop model breaks down for fine-grained interactions. Use the right tool.

Optimistic UI requires effort. In React we'd just update local state and roll back on error. With HTMX you can simulate this with hx-swap-oob and some discipline, but it's more code, not less.

Backend team needs to care about HTML. This sounds obvious, but if your backend devs have been shipping pure JSON for five years, the switch to "you also own the fragment markup" is a real culture change. Some loved it. Some resisted.

Browser DevTools are less helpful. No component tree, no React DevTools. You're back to inspecting the DOM and reading network requests. After a week we stopped missing the component tree, but the first week was rough.

Testing changed. We dropped React Testing Library and most Jest tests. We added more PHP integration tests that fetch endpoints and assert on the returned HTML. Total test count went down ~40% but coverage actually improved — we were testing implementation details before.

Was it worth it?

For a CRUD admin panel with a small concurrent user count, serving server-rendered HTML over the wire and letting the browser do what the browser is already good at — yes, very much.

The cost shifted: we moved complexity from the client to the server, which means we now care more about backend cache hit rates and partial rendering performance than about React render performance. That's a tractable problem for the team we have.

We're not evangelists. The frontend team kept React for our customer-facing storefront editor, where rich interaction and offline-first matter. The right architecture is the one that fits the workload.

If you're sitting on a React-built admin panel that feels heavier than the problem it solves, do a one-week spike on the smallest screen. Measure. If the numbers above look like yours, you might save more by deleting code than by writing it.

This is part of an engineering blog series from Alesta WEB, where we build news CMS and e-commerce platforms used by 200+ production sites in Turkey. Other posts cover our multi-LLM CMS architecture and more.

Building a Multi-LLM News CMS with PHP 8.2: Lessons from 200+ Production Sites

Mahmut Gündüzalp — Sat, 16 May 2026 19:05:17 +0000

Introduction

Over the past 21 years, our team has helped build and maintain a news content management ecosystem that now powers 200+ active news portals across Turkey. In the last 18 months, we've integrated six different LLM providers (OpenAI, Anthropic, Google Gemini, DeepSeek, Groq, and Mistral) into news production workflows.

This article shares the architectural decisions and lessons we've learned — not implementation specifics, but the why-and-when of multi-LLM systems for news publishing. The patterns that let us reduce AI inference costs by ~95% while keeping quality high.

No buzzwords. Just decisions that hold up in production.

Why Multi-LLM Instead of "Just Use GPT-4"?

Three reasons we don't rely on a single AI provider:

1. Cost optimization. GPT-4o costs $2.50/M input tokens. Gemini Flash costs $0.075/M — 33x cheaper. A simple summary task doesn't need GPT-4o's reasoning. Routing tasks to the right model means massive savings.

2. Vendor independence. When OpenAI had outages in 2024-2025, sites that relied solely on GPT broke. Multi-provider setups fell back to Claude or Gemini seamlessly.

3. Specialized strengths. Claude is better at long-context reasoning. Gemini is better at structured output. Groq is fastest for real-time chat. Mistral handles multilingual content well. Each provider has a sweet spot.

The Cascade Routing Strategy

The core idea: try the fastest and cheapest model first; fall back to more capable (and expensive) models only when needed.

For a news CMS, this means categorizing tasks by complexity:

Simple summaries → fast cheap models (Groq Llama, Gemini Flash)
Headline suggestions → mid-tier models (GPT-4o-mini, Claude Haiku)
SEO meta generation → cheap models suffice
Long-form content generation → premium models (Claude Sonnet, GPT-4o)
Fact-checking → highest reliability tier (accuracy critical)
Translation → mid-tier multilingual models

Each task type gets a fallback chain. If the primary model is rate-limited or unavailable, the system tries the next one — no human intervention needed.

The savings come from the realization that most news CMS tasks don't need the smartest model. A two-line summary of a news article doesn't require frontier reasoning. Reserving premium models for the genuinely hard tasks (complex analysis, fact-checking) is where multi-LLM pays off.

Why Abstraction Matters

Each AI provider has different SDKs, request formats, authentication, error handling, and pricing models. Hiding all of this behind a common interface is what makes multi-LLM practical.

The principle is simple: any provider should be swappable without changing the calling code. A workflow that "summarizes an article" shouldn't care if it's OpenAI, Anthropic, or Google under the hood. Today it might be Gemini Flash; next month it might be a new provider that didn't exist when the code was written.

This abstraction also makes A/B testing painless. Want to know if Claude Sonnet produces better summaries than GPT-4o for Turkish news? Route 50% of traffic to each, measure quality and cost, decide. Without abstraction, this experiment would require parallel codebases.

Cost Optimization: 95% Reduction in Practice

The cost reduction comes from three compounding layers:

Layer 1: Caching (~60% of savings)

Many news CMS tasks are deterministic: "summarize this article" with the same article produces the same answer. Cache once, reuse forever (until the source content changes).

Real-world cache hit rate in production: ~70% for common tasks like summaries, SEO meta tags, and headline suggestions.

The trick is knowing what to cache and what not to. Personalized content, real-time chat, and time-sensitive analysis shouldn't be cached. But the bread-and-butter of news editing (summarize, tag, rewrite headline) is highly cacheable.

Layer 2: Batch APIs (~25% additional savings)

OpenAI's Batch API offers 50% discount with a 24-hour SLA. Anthropic offers the same. Many news tasks don't need to happen in real-time:

Overnight SEO meta generation for the day's articles
Bulk product description generation for e-commerce catalogs
Archived content tagging and categorization
Translation backlog processing

Workers collect these into batches and submit them periodically. The savings compound across thousands of operations per day.

Layer 3: Cascade Routing (~10% additional savings)

By the time tasks reach a premium model, they've already been filtered through:

Cache (free)
Cheap model attempt (Groq, Gemini Flash)
Mid-tier model attempt (GPT-4o-mini, Claude Haiku)
Premium model (only when truly needed)

Quality gates between layers reject inadequate outputs from cheap models, but most outputs pass the gate. Premium model usage drops to <10% of total inference calls.

Turkish News Agency Landscape

This is where geographic context matters. Turkey's news ecosystem revolves around 8 major wire services:

Anadolu Ajansı (AA) — state news agency
Demirören Haber Ajansı (DHA) — major commercial wire
İhlas Haber Ajansı (İHA) — conservative-aligned wire
ANKA, THA, HİBYA, İGFA, BHA — regional and specialized agencies

Each has its own content format, distribution protocol, and category taxonomy. Generic global CMS platforms (WordPress, Drupal) don't handle this — there's no "Turkish news agency plugin" that connects all eight.

The implementation pattern here is adapter-style integration: each agency gets its own integration module that conforms to a common interface, so the downstream workflow doesn't care which agency the content came from. Adding a 9th or 10th agency becomes a few days of work, not a months-long rewrite.

A scheduled job runs every few minutes, fetches new articles from all enabled agencies in parallel, normalizes image formats (WebP conversion for web performance), generates responsive thumbnails, deduplicates against existing content, and stores everything in a moderation queue. Editors then review, approve, edit, or reject — never publishing raw wire content blindly.

AI Visibility: SEO's Next Frontier

Traditional SEO targets Google. AI visibility targets ChatGPT, Claude, Gemini, Perplexity, and their successors. The standards are emerging:

llms.txt — a markdown file similar to robots.txt but content-focused. It tells LLM crawlers what your site is about, key sections, and how to navigate it.
ai-sitemap.xml — like sitemap.xml but with article summaries and structured metadata that LLMs can ingest efficiently.
Schema.org JSON-LD — NewsArticle, NewsMediaOrganization, BreadcrumbList, FAQPage markups give crawlers structured access to content semantics.
Bot allow/disallow rules — explicitly permitting GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, CCBot, Bytespider, AppleBot, and Google-Extended.

The bet is that LLM-based search and answer engines will eventually rival Google for content discovery. Sites optimized only for traditional SEO will lose visibility in this new layer. Adding AI visibility to the standard SEO checklist is cheap insurance.

Production Numbers

After 18 months of running multi-LLM stacks across news production:

AI inference cost reduction: approximately 95% vs naive GPT-4o-only approach
Cache hit rate: approximately 70% on common tasks (summaries, headlines, SEO meta)
Provider availability: 99.97% (vs single-provider ~99.5%)
Processing throughput: sub-second cached responses, 1-3 seconds for fresh inference
Agency content ingestion: 8 agencies polled regularly, thousands of articles processed daily

These numbers come from real production environments, not benchmarks. Your mileage will vary depending on traffic patterns, cache TTL strategy, and quality requirements.

Lessons Learned

After 21 years building CMS software and 18 months optimizing for AI:

1. Don't lock into one provider. It's tempting to "just use OpenAI." Don't. The day they have an outage or change pricing, you'll wish you had alternatives ready.

2. Cache aggressively, but thoughtfully. Most AI tasks repeat with deterministic outputs. Cache them. But know which tasks must always be fresh (personalized, real-time, time-sensitive).

3. Route by task complexity, not by hype. Most tasks don't need GPT-4o or Claude Opus. A cheap model gets 90% of the work done at 5% of the cost. Save premium models for genuinely hard tasks.

4. Local regulations are first-class concerns. In Turkey: KVKK (data protection), İYS (marketing consent registry), BİK (Press Advertising Authority) compliance. In EU: GDPR, AI Act. Don't bolt these on later — design for them from day one.

5. Quality gates matter. A cheap model giving wrong answers is more expensive than an expensive model giving right ones (especially when wrong outputs damage brand trust). Add validation between cascade layers.

6. Stable beats shiny. Modern PHP isn't trendy. Smarty isn't trendy. MySQL isn't trendy. They all run reliably for years. The newest framework will be deprecated in three. Pick stable.

Closing Thoughts

The "best" architecture for a news CMS isn't the most novel. It's the one that:

Works reliably for years
Costs less than what you charge clients
Handles local quirks (regulatory, linguistic, cultural)
Survives provider deprecations

Multi-LLM with cascade routing and aggressive caching fits that bill in 2026. It will probably fit it in 2030 too — the providers will change, but the abstraction principle won't.

If you're building or evaluating a multi-provider AI architecture, focus on decision points rather than specific implementations. The provider you start with may not be the one you finish with. The pattern that works today should still work when the entire AI landscape has rotated through three or four hype cycles.

I write about practical software architecture, multi-LLM systems, and lessons from running CMS at scale. Feel free to drop questions in the comments — I read all of them, even when I don't reply quickly.