DEV Community: Teamvoy

The WordPress PHP Vulnerability Is Three CVEs With Three Owners

Teamvoy — Wed, 04 Nov 2026 21:02:03 +0000

The WordPress PHP vulnerability going round this week is actually three separate remote-code-execution risks, reaching WordPress operators through three different components with three different owners and three different release channels. A "WordPress is updated" screenshot answers roughly a third of the question.

Layer	Issue	Affected	Fixed in
PHP runtime	CVE-2026-109618 and CVE-2026-109619 (php2shell)	8.2 < 8.2.35, 8.3 < 8.3.36, 8.4 < 8.4.27, 8.5 < 8.5.12	PHP releases of 21 October
WordPress Core	CVE-2026-119977	4.7.0 through 7.1.3	7.1.4, released 28 October, plus branch backports to 4.7.39
Plugin	CVE-2026-120534 in ACF Extended PRO	through 0.9.2.6	0.9.2.7 — but see below

Start with Core, because the clock is real

CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalogue on 3 November, with a federal remediation deadline of 6 November. It is being exploited now.

The mechanics are worth understanding, because they're unusual: it's a time-of-check-to-time-of-use race in the full-package core upgrade process. The staging directory had a predictable, web-accessible name derived from the version string, so an unauthenticated attacker who hits the window during an upgrade can execute code. The update itself was the exposed moment.

7.1.4 fixes it by randomising the staging directory with a cryptographically unpredictable suffix, keeping and recreating an index.php guard, and preventing unsafe promotion of staged configuration data.

On the speed of exploitation: Wordfence deployed a blocking rule roughly three hours after the release announcement, and the first request matching it arrived nine minutes later. Recent telemetry has it blocking over 13,000 attacks against this CVE in a 24-hour window.

Every branch from 4.7 up got a backport. 4.6 and earlier get nothing — those sites need an upgrade, not a patch.

The PHP layer is a different owner

php2shell sits in the PHP engine, below the application. WordPress Core and every plugin can be fully current and the site is still exploitable on a vulnerable runtime. CVE-2026-109618 concerns request-memory handling after out-of-memory errors; CVE-2026-109619 concerns stale global state surviving into later requests.

Two practical notes:

php -v reports the CLI binary, which can differ from the build your web SAPI serves. Check the served version, and ask your host to map its package build to both CVE numbers — a branch label doesn't settle patch status when distributions backport.
PHP's advisory names session upload progress as an attack path for CVE-2026-109619 and suggests turning it off, and keeping it off if you don't use it. WordPress Core doesn't use the feature. For anything still on 8.1 or older, where there's no official release at all, that setting blocks the confirmed session paths without being a complete fix. ## The plugin layer, and a correction worth making

CVE-2026-120534 is an unrestricted upload of a file with a dangerous type (CWE-434), CVSS 9.8, affecting ACF Extended PRO through 0.9.2.6.

Patchstack lists 0.9.2.7 as the patched version for that CVE. But Patchstack separately records two further issues in the 0.9.2.4–0.9.2.7 range — an unauthenticated arbitrary shortcode execution and a contributor-level XSS — both patched in 0.9.2.8. If you're touching this plugin anyway, go to 0.9.2.8 or later rather than stopping at the version one CVE record names.

Check whether the plugin is installed, active, or present-but-disabled. Deactivated plugin files still sit on disk.

Patch sequence that doesn't become an outage

Urgency should shorten decision time, not remove recovery controls.

Freeze unrelated changes. Keep the security release small enough to diagnose and reverse.
Inventory all three layers across every environment — PHP build, Core version, plugins, themes, custom code, hosting model.
Preserve evidence first if compromise is plausible. Save logs and deployment records before retention windows or routine updates overwrite them. This step is irreversible if you skip it.
Take a restorable backup — database, uploads, configuration, deployment artifacts — and test the restore path.
Rehearse in staging matching production PHP settings, extensions, and web server behaviour.
Test the business paths: login, forms, publishing, scheduled jobs, email, payments, API integrations, admin workflows.
Patch each exposed layer, then run production smoke tests.
Retain the change evidence — versions, timestamps, approvals, test results, rollback decisions. Order depends on exposure and control. If your host can patch PHP without application changes, take that reduction early and document it. An exposed plugin may need isolating before a wider upgrade.

Patching is not proof of a clean site

A patch closes a known path. It doesn't demonstrate nobody used it earlier, and with Core under active exploitation since 28 October, "we updated" and "we were never compromised" are different claims.

Post-patch triage, compared against a known-good baseline:

Web, PHP, application, WAF/CDN, authentication, and hosting control-plane logs.
Unexpected administrator accounts, API credentials, scheduled tasks, configuration changes.
Modified PHP files, unfamiliar plugins or themes, files added to writable directories.
Outbound connections, process activity, redirects, traffic that differs from baseline.
Deployment history and file-integrity results against a known-good release.
Whether your logs even cover the vulnerable period, and whether clocks align across systems. Absence of indicators isn't absence of compromise. Scanners miss deleted artefacts and anything outside their visibility.

The useful mental model for all of this: the fastest response isn't one blanket update, it's accurate ownership. Someone owns the runtime, someone owns Core, someone owns the plugin inventory, and until all three have answered, the response is incomplete.

Full write-up with the version tables, evidence checklist, and sources: teamvoy.com/blog/wordpress-php-vulnerability-2026

More engineering writing from the Teamvoy team at teamvoy.com/blog.

Claude Code 2.0 Was a Release, Not a Capability Set

Teamvoy — Fri, 30 Oct 2026 13:37:37 +0000

Claude Code 2.0 was version 2.0 of Anthropic's terminal interface for its coding agent, announced on 29 September 2025. It is not a model, and it is not the product you'd install today.

That distinction matters more than it sounds, because search results blend three things: the historical launch, later 2.0.x package releases, and current behaviour. Teams end up writing rollout policy against a frozen feature list from over a year ago. Use the release for context, then check the current changelog before anything goes into a control document.

Same goes for naming. "Claude Skills 2.0" isn't an Anthropic product name — it's search shorthand. The official terms are Agent Skills (the open standard) and Claude Code skills (the implementation). Useful phrasing for discovery, bad phrasing for an architecture diagram or a procurement record.

What actually shipped in the 2.0 bundle

A refreshed terminal interface with better status visibility and searchable prompt history on Ctrl+R.
A native VS Code extension, in beta at the time. "Beta at launch" is not a current support statement.
Checkpoints, for automatic code-state recovery.
Agent SDK support for subagents and hooks, under the renamed Claude Agent SDK. The durable idea in there is controlled delegation. Everything else has moved.

Checkpoints are local undo, not history

This is the part worth knowing precisely, because it looks like a full undo and isn't. Per the current checkpointing docs:

A checkpoint is created at each prompt that starts a turn, with no configuration.
Claude Code keeps file snapshots for the 100 most recent checkpoints in a session, cleaned up around 30 days after the session's last snapshot (configurable via cleanupPeriodDays).
/rewind, or double-Esc on an empty prompt, opens the menu. You can restore code, conversation, or both.
What it does not cover:
Files modified by bash commands. rm, mv, cp — the docs are explicit. If Claude runs a script that rewrites 300 files, rewind won't bring them back.
External changes. Edits you made outside the session, or from a concurrent session.
Subagent edits, symlinked and hard-linked files. A restore will tell you it skipped them.
Anthropic's own docs put it plainly: treat checkpoints as local undo and Git as permanent history. The practical consequence is a routine rather than a preference — commit before you delegate anything wide-scale, because the more shell autonomy you grant, the more of the work happens outside the checkpoint's reach.

Keep facts in CLAUDE.md, procedures in skills

A skill is a directory built around SKILL.md. Claude loads it when the description matches the task, or you invoke it as /skill-name. The useful split:

CLAUDE.md — persistent project facts that should be available broadly.
Skills — procedures. A code-review checklist, a release-note workflow, a migration playbook. The full body only loads when used, which keeps irrelevant context out and gives you a versioned artifact to review.
Hooks — deterministic actions at defined events, like running tests.
Subagents — isolation or parallelism for specialized work. Checkpoints manage session state. Skills define a procedure. Those are different layers and conflating them is how teams end up with neither.

A skill is code plus policy

Skills don't make a process deterministic. The model still interprets the instructions, the tools still change state, and a third-party skill can carry scripts and references nobody on your team has read. A catalog listing is not a security review.

Six things before one gets installed:

Inspect SKILL.md and every bundled script.
Pin the repository revision or package version.
Limit permissions to the files, commands, networks, and tools the task actually needs.
Test in an isolated repository with representative failure cases.
Record the owner, approved use, review date, and rollback path.
Require a human merge decision for production code. Anything that can run commands, call MCP tools, or fetch network content expands the same attack surface as any other automation dependency — because that's what it is.

Store project skills with the repository when the procedure belongs to one codebase. Use centrally governed distribution when the same approved procedure spans several. Either way it needs a named owner and a review cadence.

Where the gates are worth it, and where they aren't

Sandboxing, managed settings, deny rules, and monitoring reduce risk rather than remove it. Prompt injection, broad tool access, and weak review can still produce a supply-chain or production problem.

But a governed skill takes longer to approve than a private prompt, and that overhead is only justified where it buys something. Strong gates belong on workflows touching production, customer data, authentication, payments, or regulated records. Apply the same gates to every low-risk local task and you get review theatre plus usage quietly migrating to personal accounts — which is worse than where you started, because you've lost the visibility too.

The controls that carry the load are the boring ones: permissions enforced outside the prompt, provenance on the commit, a human signing every merge, Git as the durable source of truth, and a quarterly pass over the changelog to check your controls still match the product.

Cursor or Claude Code

Briefly, because this isn't the comparison article: Cursor is editor-first and keeps the agent inside an interactive coding session. Claude Code started terminal-led and now spans terminal, IDE, desktop, and browser. Cursor usually fits teams who want minimal workflow change; Claude Code fits terminal-heavy and platform work and larger delegated tasks.

Neither product's checkpoints replace Git. Both need ownership and version control on their reusable instructions. Most organizations will end up splitting by task rather than picking a winner.

Full write-up — the release table, the governance control matrix, and where to source skills: teamvoy.com/blog/claude-code-2-0

Written by BYLINE_TO_CONFIRM, Teamvoy. More engineering writing at teamvoy.com/blog.

Pick an LLM Gateway by Who Runs It, Not by Feature Count

Teamvoy — Tue, 27 Oct 2026 14:20:01 +0000

An LLM gateway is a reverse proxy between your applications and model providers. It exposes one API, usually OpenAI-compatible, and applies policy to every request: which model answers, what happens on failure, whether a cached answer gets reused, who may spend how much, and what gets logged.

Every comparison of them ends in a ranked list, and the ranking is useless, because a self-hosted MIT proxy and a credit-funded model marketplace solve different procurement problems. The question that actually narrows the field is who operates the thing.

Four roles:

Self-hosted open-source proxies — LiteLLM, Portkey Gateway, Bifrost, llmgateway.io, Helicone AI Gateway. You own the keys, the logs, and the patching.
Managed gateways — Cloudflare, Vercel, OpenRouter, Portkey Cloud, TrueFoundry. Live this week; you inherit a billing model instead of an ops burden.
API-management platforms with LLM policies — Kong, Azure API Management, Apigee. Cheapest to adopt if your platform team already runs one, hardest to leave.
Cloud patterns — AWS publishes a reference architecture that runs LiteLLM in your own account. No gateway license, just infrastructure.

What makes it an LLM gateway

A classic API gateway terminates TLS, authenticates callers, rate-limits by request count, and routes by path. The LLM layer adds token quotas, semantic caching, provider-format translation, fallback on 429 and 5xx, prompt guardrails, and per-token cost attribution.

One test separates the two: can it reject a request because a team spent its token budget, and can it tell you which key, model, and prompt consumed it? A classic gateway answers neither without custom plugins.

The request path, in order: client → virtual-key auth → policy checks → cache lookup → router → provider adapter → provider API → response guardrail → logging and cost attribution → client. Each stage can short-circuit. An over-budget key stops at policy. A cache hit stops before routing. A provider failure loops back for a fallback.

Read the license before the feature list

This is where the open-source category gets interesting, and where a lot of shortlists go wrong. As documented on 22 October 2026:

LiteLLM is MIT outside its enterprise/ directory. Virtual keys, budgets, spend tracking, the admin UI, load balancing, guardrails, and an MCP gateway are in open source. The license key gates SSO and SCIM beyond 5 users, audit logs, org and team admins, and secret-manager integrations.
Portkey Gateway is MIT, with a 2.0 pre-release that merges the enterprise gateway into open source. Last repository push was May 2026, so check which branch you're deploying.
Bifrost is Apache-2.0 and ships as a single Go binary. Clustering, guardrails, and the MCP gateway are commercial with no published price.
llmgateway.io is AGPLv3 for the core with a commercial ee/ directory. If you modify the gateway and expose it as a service, have legal read the license before the pilot, not after.
Helicone AI Gateway is Apache-2.0 and still carried a public beta badge, with its last push in November 2025. Verify maintenance before shortlisting.

The pattern worth internalizing: a LICENSE file that points to a second file for an entire directory means the feature you're evaluating may not be under the license you think it is.

The billing models split four ways

Managed gateways remove the patching duty and replace it with a bill whose shape matters more than its size.

Free core, paid logs. Cloudflare keeps analytics, caching, and rate limiting free; log retention follows your Workers plan. Observability depth and spend move together.
Pass-through. Vercel charges no markup and no platform fee on tokens, with payment processing fees unless you invoice as enterprise.
A cut of credits. OpenRouter takes a percentage on credit purchases, with provider pricing passed through. Painless at $2,000 a month, very visible at $200,000.
Per recorded log. Portkey Cloud prices by logs recorded, with a free developer tier the vendor itself labels not production-suitable.

And the fifth, for self-hosting: infrastructure only, which looks free until you cost the engineer who runs it and answers the 3 a.m. page.

Eight questions for a one-hour vendor call

Four ways gateways fail

Each is manageable. Each costs engineering time the pricing page doesn't show.

The extra hop. Every gateway adds a round trip and a translation step. Vendors publish their own overhead figures; the only number worth anything is the one measured on your path. Compare p50 and p99 with and without the gateway on identical prompts.

A new tier-one dependency. A gateway everything depends on is a single point of failure. Self-hosted needs HA and a runbook. Managed moves the risk to a vendor's status page, which is a different risk rather than a smaller one. Keep a documented bypass for apps that can't tolerate gateway downtime.

Cache staleness. A cached answer about a price, a policy, or an account balance is wrong the moment the source changes. Scope caching to prompts whose correct answer holds for the TTL, exclude anything personalized, set the similarity threshold per endpoint, and log cache hits separately so support can trace a stale response.

Lock-in through config. Routing rules, guardrail configs and virtual-key hierarchies in one vendor's format are the migration cost you pay later. Prefer plain YAML or JSON in your repo, and treat the OpenAI-compatible interface as the contract your apps depend on.

A two-week pilot

Shortlist two gateways from different operating roles — one self-hosted, one managed — so you're comparing cost models rather than feature lists.
Mirror production traffic. Send a copy of real requests through each and discard the responses. Shadow traffic surfaces translation bugs that synthetic prompts never hit.
Write SLOs before measuring. A p99 ceiling, an availability target, a fallback success rate. A pilot without SLOs produces opinions.
Measure cost per accepted request — total spend including engineer-hours, divided by requests that produced a response your application actually used. Cache hits and fallbacks move this more than token prices do.
Exercise failure. Revoke a provider key, force a 429, fill a budget. Record what the gateway did and what your application saw.
Test the exit. Export the routing config, the logs, the virtual-key hierarchy. If the export needs a vendor ticket, the lock-in surface is bigger than the docs suggest.
Decide and document rollback. Write the bypass procedure for direct provider calls, and date the decision so pricing gets rechecked next quarter. One caveat on fallbacks, since it bites people in step 5: every fallback needs its own cost ceiling, or an outage at your cheap provider turns into a bill from your expensive one.

Most teams should adopt rather than build, and that includes teams who could pay someone to build it. LiteLLM, Cloudflare, or Vercel can run on shadow traffic within days from documentation alone. A bespoke gateway is justified when policy requirements exceed every license tier you can afford — data residency that rules out SaaS, air-gapped deployment, MCP governance across dozens of teams. Otherwise the interesting work isn't the gateway, it's the evaluation set behind the routing rules and the observability pipeline into your SIEM.

Full breakdown — per-vendor tables with sources and retrieval dates, pricing comparison, and the full criteria list: see the full guide

Written by Zhanna Yuskevych, CPO at Teamvoy. More engineering writing at teamvoy.com/blog.

What Is Grok Bot? Separate Bots Are Not a Security Boundary

Teamvoy — Mon, 26 Oct 2026 11:56:48 +0000

The short answer to what is Grok Bot: named, persistent AI agents from xAI that run on a cloud computer with a browser, filesystem and terminal, sign into your existing tools, and finish multi-step work while you're away. It launched in beta on 11 August 2026, and it's a separate product from Grok, the chat assistant.

The longer answer is a contradiction in xAI's own material. The launch page says Bots have their own computer. The documentation, published the same day, says all of your Bots share one persistent cloud computer — and that separate Bots should not be used as a security boundary.

Both statements are from xAI. Only one survives a security review. If you're evaluating Grok Bot for ops work, that gap is the evaluation; everything else is a pricing conversation.

What the shared computer actually means

Each Bot gets a screen. The account gets a machine. So:

A browser session one Bot opened is available to every other Bot on that account. Sign a Bot into your CRM and every Bot you run can reach it.
Files written by one Bot sit on the same filesystem as the next.
Deleting a Bot does not remove its files or its logins from the computer.

Isolation between users is strict — each user gets a dedicated microVM with its own kernel, memory, and virtual devices. Isolation between Bots doesn't exist, by design. The product itself has described the arrangement as a real blast radius.

The practical consequence for a mid-market team: "can we point it at our ERP?" resolves to "only with an account scoped to what you'd let every Bot on that account touch." That's a different question from the one most people think they're asking.

The credential handoff is the part to watch

When a Bot hits a login, a 2FA prompt, or a CAPTCHA, it hands the computer back to you. You type the credential, hand control back, and the session persists — for every Bot on the account, from then on.

This is also the genuine differentiator. API-first agents can only reach systems someone instrumented. A browser-driven agent reaches the legacy SaaS and admin panels nobody ever built a connector for. That's real capability, and it comes with the obvious cost: the agent is only as reliable as a browser session on a site that may block automation, expire, or demand a human step at 3am.

There's a review layer — an independent model evaluates shell commands, plugin calls, and automation writes before they run, and can allow, require approval, or deny. Treat it as a control on actions, not as isolation between agents. It doesn't change the shared-machine fact above.

What it is not

Taken from the vendor's own documentation rather than from critics:

Not on-prem. No deployment inside your own perimeter, no bring-your-own-image.
Not a model you pick. Model selection is vendor-managed with no customer-facing picker, and the serving mix can change. An enterprise allowlist exists, with enforcement the docs themselves don't guarantee.
Not a data-residency commitment. Computers run in the US today; the US-only residency program doesn't cover Grok Bot by default.
Not auditable on self-serve plans. Audit logs, action recording, telemetry export, and network allowlists sit behind the enterprise contract. Self-serve defaults to allow-all.

The trade, stated plainly

Speed to value comes from zero setup: one message, one shared cloud computer, vendor-managed models, five minutes. The price is zero perimeter control. You can't run it in your network, can't pin the model, can't isolate one Bot's credentials from another's.

That's a reasonable trade for low-sensitivity ops, sales, and support work. It's the wrong trade when the workload needs its own perimeter — data that can't leave your region or VPC, a model you must pin for audit or cost reasons, credentials isolated per process rather than per user, or a system that only exists behind your VPN.

Build in that case, and accept the other side of the trade: design and integration cost up front, you own operations, and a first version takes weeks rather than minutes.

The alternatives split along the same axis. Ecosystem agents from the big model vendors get you admin controls at a lower tier. Hosted agent platforms get you bring-your-own-model keys. Open-source agents run on your own hardware with your own keys, and you own patching and security forever. None of them match the sign-into-anything-with-a-browser reach. Each wins on one axis Grok Bot gives up deliberately.

Pick the axis that matches the workload, and check the current pricing page yourself — the plan structure moved once between the August launch and October, and it'll move again.

Full breakdown — plan-by-plan access, the security control list, and alternatives compared: see the full guide https://teamvoy.com/blog/what-is-grok-bot/

Written by Zhanna Yuskevych, CPO at Teamvoy. More engineering writing at https://teamvoy.com/blog

PHP Vulnerability 2026: Critical Security Alert for CVE-2026-109618 and CVE-2026-109619

Teamvoy — Thu, 22 Oct 2026 13:52:25 +0000

Your hosting provider says the servers are patched. Your agency says the sites are current. Somewhere in the estate there's a Docker image, a vendor appliance, or a PHP 7.4 app nobody has opened since 2022.

Two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, were fixed on 21 October 2026. Both allow unauthenticated remote code execution before your application code runs. Updating a CMS or a plugin changes nothing.

Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. The PHP project states there are no complete mitigations and that updating is the only safe choice.

Why the CMS update doesn't help

The bugs sit in memory management and error handling — code paths nearly every request touches. PHP parses the request before WordPress, Drupal, or Magento sees it.

Two consequences people are getting wrong right now:

A fully current CMS on an unpatched runtime is fully exploitable. Unauthenticated code execution has been demonstrated against current releases of all the major PHP applications.
Maintenance mode doesn't count. PHP parses the request before the CMS checks its maintenance flag. A "down for maintenance" page on an unpatched runtime is a live target.

A WAF rule buys time against known request shapes and nothing more. Cloudflare's CTO called its own mitigations a stopgap and told people to patch.

Five steps

Inventory every PHP runtime — hosts, containers, build images, control panels, and vendor products that bundle PHP without advertising it.
Apply the update from your distribution, LTS vendor, or source.
Restart or redeploy. PHP-FPM pools, Apache, LiteSpeed, containers. A patched package with a running old worker is still exploitable.
Verify the SAPI version, not the CLI version.
Review logs for pre-patch activity and record what changed, when, and who verified it.

Step 4 is the one that catches people. php -v reports the CLI binary, which can be a different build from the PHP-FPM pool or mod_php module serving traffic. Put a one-line phpinfo() behind an allowlist, load it over HTTP, read the version and the Server API line, then delete the file.

Where PHP hides

Four places, in order of how often they're missed:

Managed hosting and control panels. cPanel and Plesk let each site pick its own PHP version. Check per site, and get the patched package version from your provider in writing.
Containers. The image tag (php:8.3-fpm) tells you the branch, not the patch level. Pull the latest digest, run php -v inside it, redeploy.
Appliances and bundled PHP. Monitoring dashboards, VoIP admin panels, vendor products that never mention PHP anywhere in their docs.
Your build pipeline. A CI runner on an old base image can quietly rebuild a patched image back to an unpatched one.

Sophos made the point to the BBC that the hard part isn't installing the patch — it's finding every PHP instance. If nobody on your team can say which version production serves, that gap is itself the finding.

If you can't patch today

Isolate. Several agencies advised taking internet-facing systems offline until the fix is applied and verified, and large operators took that advice: government platforms in Finland, the Netherlands, Australia, and the UK went dark as a precaution rather than because of a breach.

The pattern that worked was read-only behind a CDN. Australia's GovCMS disconnected its origin and served cached pages via Akamai overnight. Visitors kept getting pages, the exposed surface dropped to zero, and the cost was a night without content editing. Cheap caution.

The partial mitigations in PHP's advisory (memory_limit=-1, a low post_max_size, session.upload_progress.enabled=0) reduce exposure to specific paths. They do not make an installation safe.

Checking whether you were already hit

Three detection signals worth grepping for:

Unusual multipart requests followed by memory-limit errors or repeated HTTP 500s.
Oversized or malformed PHPSESSID response cookies — the first bug can leak process memory into the session cookie, Heartbleed-style.
Unexplained PHP worker crashes or restarts.

Their absence doesn't prove you're clean. Patch regardless, then look for web shells, new cron entries, and unexpected outbound connections.

On exploitation: attempts are confirmed at scale and automated, with Cloudflare reporting millions by the evening of the 21st. Publicly confirmed successful breaches are a different question and, as of 22 October, a thinner one. Nobody can tell you your server wasn't one of the successes.

The decision that outlasts the week

Branches 8.1, 8.0, and 7.4 got minimal source backports and no binary releases. Researchers trace the affected code back as far as PHP 5.4.

So most of your fleet needs a package update and a restart. That's not a project, and anyone telling you otherwise during a 48-hour incident is selling something. The exception is the app on 8.1 or older with no vendor binary. Building PHP from patched source once is a day's work. Doing it for every future PHP CVE, across a fleet, with an extension stack that may not compile, is an ongoing tax.

Patch first. Verify the served version. File the compromise assessment. Then look at the list of runtimes that have no binary fix coming — that list, not the CVE, is what tells you whether you have a patch or a project.

Fuller write-up with the version table, UTC timeline, and what to keep for auditors: teamvoy.com/blog/php-vulnerability-2026

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.

What Happens When This Fails at 2 a.m.?\" and Five Other Questions That Beat a Coding Test"

Teamvoy — Tue, 20 Oct 2026 22:46:02 +0000

A country name is not hiring evidence. Neither is a university, a framework list, or a logo slide. If you are evaluating an engineering team — in Ukraine, Poland, Brazil, or three miles from your office — the only thing that predicts delivery is evidence from the specific people who will do the work.

That sounds obvious and almost nobody runs their process that way. The usual version compares hourly rates, checks a few references, and discovers in month four that nobody owns production.

Six areas, and what to actually ask

The architecture question is the one that separates seniority fastest. An engineer who names the option they rejected, and why, is reasoning about trade-offs. An engineer with one recommendation and no alternatives is reciting.

Replace the coding test with a paid slice of your actual system

Generic coding exercises test whether someone can do a generic coding exercise. Use a bounded paid engagement instead — an audit, a prototype, a migration slice, a production hardening task — with real acceptance criteria.

Six steps, in order:

Define the owned outcome. What must be running, who uses it, what production responsibility the supplier carries.
Test architecture judgment against a real constraint from your system. Ask for options, risks, a recommended path.
Inspect delivery mechanics. Planning, code review, QA, release controls, observability, incident response, decision records.
Interview the actual team — the people doing the work, not sales or leadership.
Validate security and continuity. Access controls, backups, staffing coverage, escalation. Test the plan with a scenario rather than accepting "we've never had an issue."
Run the bounded paid engagement.

A pilot that costs money and touches your real code tells you more in two weeks than a reference call tells you ever.

Match the model to the work

Worth saying plainly: an internal hire or a specialist freelancer is often the better call. Stable, narrow, long-lived work belongs in-house. A partner earns its cost when the problem crosses architecture, delivery, operations, and product decisions at once.

Why rate comparison misleads

A lower hourly rate is a real number attached to the wrong question. The savings disappear when designs change repeatedly, questions wait days for answers, or production has no owner. Compare the cost of a stable release and its operation, not one engineering hour.

Time zones work the same way. Overlap between Europe and North America supports a clean handoff and also delays decisions when teams depend on synchronous meetings. Define core overlap hours, asynchronous approval rules, and which incidents justify after-hours escalation — before signing, not after the first missed deadline.

On the market data

For context, since buyers ask: Ukraine's IT Association reported $3.343 billion in computer-services exports for the first half of 2026, up 4.1% year over year, with the US accounting for $1.234 billion or 36.9%. The National Bank reported $6.8 billion in IT-services exports for 2025, 12.6% of total goods and services exports, while the Association's own 2025 figure is $6.6 billion across more than 305,000 tech professionals.

Those numbers don't agree, because the definitions and time windows differ. Check the terms before comparing them, and treat all of it as context rather than as evidence about any vendor. Sector size tells you a market exists. It tells you nothing about whether a specific team has mature operations.

Contract terms worth a lawyer's time

Ukraine's Diia City regime sets rules for qualifying tech companies and includes employment and gig-contract models, under Law No. 1667-IX. A vendor's tax status doesn't change your rights. Confirm whether the supplier is a resident and which entity signs.

Then have counsel cover: IP assignment for code, models, prompts, documentation and designs; data-processing roles, transfers, retention, deletion and incident notice; subcontractor use and approval rights for sensitive systems; security requirements, audit evidence and access removal; sanctions and export controls; and continuity, termination assistance, repository access and knowledge transfer.

That last cluster is the one skipped most often, and it's the one that matters when an engagement ends badly.

For AI work specifically, add: evals, grounding, logging, cost control, human review, and who carries production support.

Keep narrow work narrow. When the work spans AI, legacy systems, data integration, security and production, judge partners by the result they can own — and make them prove it on a paid slice of your real system first.

Full guide — the evidence table, the six-step process, and the engagement models in detail: see the full guide

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.

What Does LLMOps Cover That MLOps Does Not?

Teamvoy — Mon, 21 Sep 2026 16:25:11 +0000

What the operations layer around a production language model actually contains, and what it costs to skip it.

Picture the failure. Support deflection has sat at 61% for six weeks. On a Tuesday it reads 48%. Your repo has no new commits. Latency is flat, the error rate is zero, every HTTP response is a 200. The provider rolled a point release behind the model identifier you pinned loosely, and the summarization step now writes three sentences where it wrote one, so the routing logic downstream stopped matching.

You find out from a customer.

That gap between “the service is up” and “the answers are right” is the entire subject of LLMOps. It is the engineering between a model endpoint and the people depending on it, and in 2026 it is the part of the stack most teams shipped without.

The thing you are operating is a configuration, not a model

Here is the distinction that makes LLMOps its own discipline rather than MLOps with new vocabulary.

In MLOps you version training data, features and weights. You own the artifact. When it degrades, the cause is data drift or a broken feature pipeline, and the fix is a retrain on your schedule.

In LLMOps the artifact belongs to a vendor. What you own is everything wrapped around it: prompt versions, a retrieval corpus, tool contracts, a routing config, a provider and model version. A regression comes from a version bump you did not schedule, a corpus update someone ran at 4pm, or a one-word prompt edit that passed review because nobody had a way to test it.

Rollback means restoring a previous combination of prompt, corpus and provider. There is no artifact to roll back to. That difference cascades into five components, and most engagements start with whichever one is missing.

Evaluation suites. A versioned case set covering the paths users take, run in CI against every prompt edit, corpus change and provider bump, with a pass threshold gating release.
Tracing. Every model call, retrieval and tool invocation, captured at the request level.
Versioning. Prompts, corpora and tool contracts under change control, the same way code is.
Cost telemetry. Spend attributed per request across a multi-step path.
Release control. A documented rollback path someone has actually used.

Evaluation is the control plane, and logging is not

The industry spent two years buying tracing tools and calling it observability. Tracing tells you what happened after it happened. An evaluation suite stops the bad change from shipping.

A working suite is a versioned case set with graded expectations, run in the same pipeline as your unit tests. Four kinds of case earn their place:

Golden cases with known-correct answers.
Adversarial cases covering ambiguous and out-of-scope input.
Multi-step cases that exercise the tool path, including the loop that runs twice.
Regressions pulled from real traces, added the week each one broke.

The pass threshold blocks the merge. That single mechanic turns a prompt edit from a judgment call into a diff someone reviews on evidence, and it turns a provider release from an incident into a report: the suite runs against the new version, the delta comes back case by case, and the routing config either moves or stays.
Now the honest part. Real evaluation adds weeks to a first release and returns nothing on that release. It pays back on the first model change and every one after. A team shipping one prompt into a low-volume internal tool should skip it and spend the time elsewhere.

What a trace has to carry before it is useful

Most LLM tracing captures the model call and stops. That covers maybe a third of your failure modes. A trace that answers real questions has four layers.

Retrieval. Which documents came back, what they scored, and whether the answer actually cited them. Most quality complaints resolve here, and they resolve fast when the retrieved chunks sit next to the output.
The model call. Provider, model identifier, prompt version, tokens in and out, time to first token, total latency.
Tool calls. Which tool the model picked, the arguments it passed, what came back, and how many times the loop ran before it stopped.
Outcome. Whether the request resolved, escalated to a person, or got retried.

Join that last layer to cost and the number changes meaning. Spend per million tokens is an accounting figure. Spend per resolved request is an operating one, and it is the only version of the metric that tells you whether a cheaper model is actually cheaper once it escalates twice as often.

In a regulated deployment, the ops layer is the evidence layer

If you run in fintech, insurance or health, the auditor will ask for records rather than architecture. Four artifacts carry that weight, and each is a design decision taken before launch rather than a report generated after one.

Version lineage per decision. For any output that affected a customer: the prompt version, model identifier, retrieval snapshot and tool responses behind it. Under SR 11–7 model risk guidance, this is what makes a language model component reviewable in the same terms as a credit scorecard.
Human review records. Which outputs a person approved, changed or rejected, timestamped and attributable. Where a fully automated decision would sit in scope under the EU AI Act, this is the control teams most often rely on to stay outside it.
Retention and residency. Traces hold customer text. Retention windows, redaction and inference region are GDPR questions rather than infrastructure preferences, and DORA adds concentration risk where one provider serves every route.
Change control. SOC 2 change management applied to prompts and corpora, not only to code, because both move model behavior.

Teams that treat these as a compliance workstream separate from engineering build the system twice.

Where the classical model still wins

One more thing worth saying out loud, because vendors rarely say it.

On a stable, high-volume classification step, a small trained classifier or a deterministic rule beats a model call on cost, latency and predictability. Every time. If the step is “route this ticket to one of nine queues” and you have labeled history, the language model is the expensive option with the worse audit story.

Teams already running classical models are in the best position here anyway. The registry, the deployment pipeline, the monitoring backbone and the incident rota serve both disciplines. Splitting them doubles the operational surface for no return. What diverges is the clock: a classical model gets retrained on your data, a model route gets reconfigured on a vendor’s release schedule.

Four questions for whoever you hire

Apply these to us as readily as to anyone else.

Who writes the evaluation suite, and when? If the answer is “after the first release,” evaluation is an add-on rather than part of the engineering.
Where does inference run and who holds the keys? Your cloud account, a vendor platform, or a mix, and the data path in each case.
What is the handover artifact? A running system with traces, a documented case set and an on-call rota is a different deliverable from an architecture diagram.
What did the team do the week a provider last deprecated a model?

This one is hard to fake.
We wrote up how we run this work, including a 3–5 day readiness audit that leaves you with a written gap list you can act on with any partner: LLMOps consulting services.

Or take the shorter path. A 15-minute call with our CTO about where your model runs, what your traces show today, and what breaks the next time a provider ships a version bump.

If Reviewers Accept 95% of Drafts Unchanged, They Stopped Reading

Teamvoy — Tue, 15 Sep 2026 15:44:02 +0000

Track one number when you put a generative model into a review workflow: how often reviewers accept the draft unchanged.

Above roughly 95% and they've stopped reading. That's automation bias, and it looks exactly like success on every dashboard you have. The person's job changed from doing the work to approving it, which is a different job with different failure modes, and the main one is approving what they should have caught.

This is the shape of the whole problem. A prototype proves the model can produce the artifact. Production asks whether you can show a regulator, six months later, why a particular output was produced — and whether a customer can challenge it. Those are design problems long before they're engineering problems.

The integration work is roughly 20% model and 80% everything else: data pipelines, evals, audit logging, human review paths, and the interface showing a user what the model did.

Three things change when the output is probabilistic
The same input can produce a different artifact tomorrow. Interfaces built on deterministic assumptions break quietly. Pin temperature and seed or you cannot reproduce a decision.
The audit surface grows. Every inference becomes a record you may need to reconstruct.
The human role moves from producing to approving, with the acceptance-rate problem above.
Generative and predictive are different products wearing one name

A credit model returning a default probability is predictive. An assistant drafting the adverse-action notice that follows is generative. Vendors blur this and buyers inherit the blur — one platform sells "AI for lending" and you've bought two unrelated risk profiles under one contract.

Predictive  Generative

Output Score, class, ranking Text, document, summary
Evaluation Precision, recall, AUC vs labels Faithfulness, groundedness, human preference
Failure mode Systematic bias against a group Confident fabrication, one output at a time
Found by Aggregate analysis Per-instance review
Reproducibility Deterministic given version Varies unless parameters pinned
Cost profile Training-heavy, inference-cheap Training-light, inference-expensive

A generative feature needs a review path. A predictive feature needs a challenger model. Building one and governing it as the other is the most expensive mistake in the category, because it's usually found during an examination rather than during a sprint.

RAG sits between them and confuses things further. Govern the retrieval as a data-access control and the generation as a content control. Treating it as one component makes both halves harder to defend.

Four prerequisites, each with a pass/fail test

Run these in week one, on paper, before anyone writes a prompt:

Data — can you pull 200 real cases with labeled correct outcomes without a manual export? If that takes more than two days, the data problem is your project.
Team — is a compliance reviewer named in the sprint, not on the distribution list?
Baseline — is there a current metric with today's number written next to it?
Sponsor — does one executive own the outcome and the budget, in writing?

The data test fails most often, and it fails in week five, after the model work is already scheduled. That moves the launch by a quarter.

Write the eval suite before picking the model

The sequence teams actually run: pick the model in week one because it's the interesting decision, design the interface around whatever it produces, hand the whole thing to compliance in week ten. Reversing that is most of what separates a six-week build from a six-month one.

The dependency order that can't move:

You cannot validate a model against evals you haven't written.
You cannot write evals without knowing what a correct output looks like in the workflow.
So the domain expert who does this work today has to be in the room before model selection, scoring 100 to 300 real cases.

Cost, latency, data residency, and vendor retention policy narrow the field faster than benchmark scores do. And test for disparate outcomes on protected characteristics even when the output is a draft rather than a decision — a drafting assistant that writes warmer letters to one group is a fair-lending problem wearing a different hat.

Design the reviewer's screen before the customer's

The review interface decides whether reviewers catch errors or rubber-stamp them, and that single behaviour sets the feature's real error rate more than model quality does. It's the part of the work that never shows up in a portfolio.

Beyond acceptance rate, two things help: put the retrieved records next to the generated draft so the grounding is visible, and seed known-bad cases into the queue to check people are still catching them.

On the customer side, three patterns carry the trust load:

Confidence disclosure that states the basis, not a number. "Drafted from your March statement and two prior disputes" tells a user more than "87% confidence" and is much harder to misread.
Reversible action. Anything the model initiates gets an undo with a stated window. Where reversal is impossible — a sent payment — require confirmation before rather than explanation after.
A visible human path. One click, with expected response time on the button.

When a fraud hold lands on a legitimate transaction, the customer doesn't want an explanation of the model. They want the hold lifted and they want to know how long that takes. Trust in financial products is mostly a function of recoverability. Users trust what they can undo more than what they can read.

Two anti-patterns: acting without confirmation on anything material, and decorative explainability — a "why did I see this" link returning generic text. A weak explanation is worse than none, because it signals the team knew the answer mattered and chose not to give one.

Audit log before prompt

The artifact people underbuild. It has to store the prompt, the retrieved context, the model version, the parameters, the output, and the reviewer's decision — keyed so one case can be reconstructed on request.

The examiner's first question is rarely about the model. It's who signed off, what they saw when they did, and whether you can produce that record now. Teams that treat compliance as a document written after the build find the document has to describe decisions nobody wrote down.

Cheap to build in week one. Expensive to retrofit, and the feature sits idle while it happens.

What it costs, and where

A first production feature in a regulated fintech workflow: roughly $110,000 to $220,000 for a customer-support-style assistant, $320,000 to $1.1M for transaction monitoring, over three to six months. Run costs $2,000 to $25,000 a month depending on volume.

The model is the cheap part — inference on a well-scoped workflow is often under $2,000 a month at pilot volume. The spread comes from data readiness and regulatory tier, not model choice. Rough split: data prep 25–35%, model integration and evals 15–20%, interface and review design 20–25%, audit logging 10–15%, validation and documentation 10–20%.

What pushes a build past the top of the range is nearly always the same thing: the workflow wasn't scoped to one queue, and it grew a second and third use case before the first one shipped.

One trade-off this approach doesn't solve. Running compliance in parallel from step one makes your first feature slower than a team that skips it — measurably, often four to six weeks. The payback lands on features two and three, when the control framework is reusable. If your organization judges the first project on speed alone, negotiate the measure before the project starts rather than cutting the governance work.

Scope to one workflow with a number attached. Write the kill criteria before the code.

Full guide — the seven-step process, the regulatory table, and build vs buy: see the full guide

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.

Ten Things to Wire Up Before an Agent Touches Production

Teamvoy — Tue, 08 Sep 2026 18:53:46 +0000

A developer deployed a customer-support agent that got stuck in a retry loop with a CRM tool. No hard circuit breaker. It spent six hours overnight repeating the same broken call while he slept, and he woke up to roughly a $4,200 OpenAI bill for doing nothing useful.

That's the failure mode. Not a dramatic hack — a boring loop with no external stop.

Roughly 95% of enterprise generative-AI pilots in 2025 delivered no measurable return, and almost none of those were model failures. Teams optimized the brain and skipped the nervous system. A read-only chatbot is a wiki with better search. A deployed agent does things — writes to a database, calls an API, refunds a customer. That shift from reading to doing is where pilots die.

The useful mental model: treat the LLM as a fallible kernel, not a magic box. You don't trust a kernel blindly. You wrap it in checks, limits, and a way to roll back.

Agents break three assumptions your ops playbook depends on

Non-determinism. The same input can produce different actions on different days. An agent succeeds Monday and fails on the identical request Tuesday. Call it ghost debugging — the bug won't sit still long enough to catch. Design for a 3% to 15% tool-call failure rate as a normal state, not an exception.

Cost grows with loop length, not request count. This is the mechanism most guides skip. The agent loops: think, call a tool, read the result, think again. Frameworks append every step and every tool error to the running history, then resend the whole cumulative log on the next call. Token use grows quadratically. A 20-step loop is not twice a 10-step loop — each step re-pays for everything before it. Related trap: past roughly the 40% context-fill mark, answers get worse. Load the window with tool definitions and raw JSON and you're doing your real work in the dumb zone.

Every tool you connect widens the blast radius. Which brings us to the controls.

Four controls the agent cannot touch

Wire these before you touch agent logic, not after. The principle is determinism of enforcement: limits live outside the model, in code it cannot rewrite. An agent told to stay under budget will, often enough, talk itself into one more call.

Circuit breaker. Hard cap on retries and loop iterations. Hit it and the agent stops, full stop.
Deny-by-default allowlist. The agent calls only tools you explicitly permit. Everything else is blocked, not warned.
Confirmation gate. Anything destructive or irreversible — delete, refund, send — waits for a human yes.
Cost ceiling. Spend limit per run and per day, enforced by infrastructure rather than by asking the model nicely.

Research on action-level privilege control found enforcement cut attack success from 70.3% to 7.3%, and to zero with manual policies. The control plane protects you, not the prompt.

Worth being honest about the limit: external controls stop catastrophes. They don't make a weak agent good. They buy you the safety to improve it in production instead of gambling with it.

Three identities, not one

Most teams give an agent one set of credentials. That's how a single prompt injection becomes a full breach. Split it:

The user — who asked for the action.
The agent — its own machine identity, separate from any human.
The tool token — a scoped, on-behalf-of credential per tool call.

In a DORA- or PCI-DSS-bound system, "the AI did it" is not an answer an auditor accepts.

There's a quieter risk in the tool descriptors themselves. A study of 1,899 live MCP servers found 7.2% carried general vulnerabilities and 5.5% were open to tool poisoning, where a malicious description hijacks the agent. Pin and version your descriptors. Treat them as supply-chain code, not config.

And assume prompt injection — direct, where a user types it, and indirect, where the agent reads a poisoned page or document and follows hidden orders. You cannot prompt your way out of this. Checks run outside the model, in deterministic code. One scan of 5,000 AI-built apps found 60% vulnerable.

Ship it in five stages

Never all at once. Each stage answers one question before the next earns traffic.

Offline eval suite — proves broadly correct on known cases, before any real traffic.
Shadow mode — the agent decides, nothing executes. Proves it behaves sanely on live data at zero risk.
Canary — a small slice of low-risk real traffic. Proves it survives messy production input.
Graduated rollout — widen in steps, confirmation gates on anything destructive.
Post-deploy validation — behaviour drifts as inputs and model versions change. Proves it stays correct.

The rollback detail teams get wrong: an agent's behaviour is set by four things together — code, prompts, tool catalog, model version. Reverting code while keeping yesterday's prompt is not a rollback. It's a new configuration you have never run. Revert all four as one atomic bundle.

Monitor the trajectory, not the endpoint

Uptime dashboards tell you the agent returned a 200. They don't tell you the answer was confidently wrong. Three surfaces:

Operational — is it running? p95 latency, error rates, cost per run.
Cognitive — what did it decide, and why? Full reasoning trace and every tool call, in order.
Contextual — what did it see? Exact inputs, retrieved documents, tool outputs.

Track task-completion rate, tool-call success rate, tokens per run, and latency. Drift in any of them is the early warning.

Almost-right output passes every uptime check. It's the expensive failure mode precisely because completely wrong gets caught — tests fail, the build breaks — while almost right ships and compounds for months. AI-generated pull requests average 10.8 issues against 6.4 in human code, and the tell is often suppression rather than error: one review turned up a file carrying eleven eslint-disable comments where the agent had silenced the type errors instead of fixing them.

Three questions before any agent-written change merges: does it reuse what exists or reinvent it badly, does it follow your conventions or invent its own, and can a developer explain it without reading the AI's comments?

What it actually costs

Inference is rarely the big number. Integration and compliance run 40% to 60% of total deployment spend. Get the data layer wrong and everything else inflates.

Pick hosting by workload shape rather than by which is "cheaper": serverless for spiky or unpredictable volume, containers for steady high volume, hybrid if you genuinely have both and can afford to run two systems. Cloud is rented elasticity — if your load is steady, you're paying a premium for flexibility you aren't using.

Then cap the variable part: token budgets per run and per day enforced in infrastructure, semantic caching so repeated questions don't re-pay the model, and model tiering so the expensive model only runs on the steps that need it.

The ten-line go/no-go

Empty box means you're shipping a demo:

Eval suite passes.
Staged rollout ready — shadow, canary, graduated, with gates.
Circuit breaker live, enforced outside the model.
Cost ceiling set in infrastructure.
Tool allowlist is deny-by-default.
Three-identity auth.
Trajectory logging on.
Atomic rollback bundle — code, prompts, tools, model version.
Spec-first verification with the three-question test.
Named incident owner — a specific human, not a team alias.

If you went quiet on three or four of those, you're in the same place as most teams shipping their first production agent. Writing the agent is the cheap part. The gap between a working demo and something you trust at 2 a.m. is everything above.

Full guide — architecture patterns, identity delegation, cost modelling, and deploying onto a legacy core: teamvoy.com/blog/ai-agent-deployment-best-practices

Written by Taras Voytovych, Founder & CEO at Teamvoy. More engineering writing at teamvoy.com/blog.

The Systems That Need Modernizing Most Aren't the Broken Ones

Teamvoy — Thu, 03 Sep 2026 11:54:36 +0000

The applications that most need modernizing are usually not the ones that are obviously broken.

They're the stable ones. Running for years, rarely paging anyone, and increasingly impossible to change. Nothing on a dashboard flags that, because "hard to change" isn't an outage — it's a slow tax paid in every estimate that comes back three times longer than the feature deserves.

Which is why the first question shouldn't be what technology replaces the current stack. It should be: what does the current architecture prevent the product and engineering teams from doing? That question has a concrete answer. "Should we move to microservices" does not.

Modernization is not a synonym for rewrite

This is the assumption that turns a scoped project into a two-year program. The real decision is what stays, what changes, and where the investment actually removes a constraint on the business.

The 7 R's are useful precisely because two of the seven are "don't touch it":

Retire — it no longer provides value. Delete it.
Retain — still useful, still cost-effective, leave it alone.
Rehost — move it, minimal changes. Fastest path to a new environment, solves the least.
Replatform — new platform, minor changes to optimize.
Refactor — improve the code's structure without changing external behaviour.
Rearchitect — redesign for new capability or scale.
Replace — retire it and adopt something else, often SaaS.

Run every application in the portfolio through that list before picking a strategy for any of them. Teams that skip this step tend to apply one R uniformly, usually rearchitect, because it's the most interesting one.

Worth being blunt about the trade at each level: rehosting is the fastest way to the cloud and will carry every legacy problem with it. Rearchitecting and rebuilding are where the real capability change happens, and where the schedule risk lives.

What actually goes wrong

Three challenges, and each has one thing that contains it:

Technical debt. Legacy code makes every update slower than it should be. Contained by structured assessment first — you cannot sequence work you haven't inventoried.
Integration complexity. Connecting modern components to legacy systems is where the unknown work hides. Contained by phased rollout, so an integration surprise costs one phase instead of the program.
Security risk. Changing infrastructure exposes new surface. Contained by continuous monitoring through the migration, not a review at the end.

None of those three are technology problems. They're sequencing problems, which is why the assessment phase is the one worth over-investing in.

Tie it to a number or it drifts

Modernization without a defined outcome becomes an infrastructure project that nobody can defend at budget time. Three things keep it honest:

Named KPIs. Cost per deploy, time to ship a feature, incident rate — whatever the constraint actually was. Define it before the work starts.
Cross-functional ownership. IT, business, and operations working from the same target. Modernization that only engineering can explain the value of gets cut.
Prioritized workloads. Start with the applications where the constraint costs the business the most, not the ones easiest to migrate.

For context on scale: 83% of C-suite executives see app and data modernization as central to business strategy, and worldwide public cloud end-user spending was forecast at $723.4 billion for 2025, growing 21.5% year over year. The money is moving. Whether your slice of it removes a constraint or just relocates one depends on the sequencing above.

Where AI helps, and where the data layer stops it

Two things worth separating. AI in the modernized system — automation, forecasting, analytics — needs clean, governed data to be worth anything. If the data layer is the actual blocker, that's the modernization project, and no amount of application refactoring routes around it.

AI in the migration is a different claim. It compresses the mechanical parts: reading unfamiliar code, generating tests for untested paths, drafting the boring half of a refactor. It doesn't compress the assessment or the integration work, because those are constrained by other people's systems and by decisions someone has to own.

The sprint framing is the one part of the process worth copying regardless of scale: short iterative cycles against one measurable constraint, so you find out early whether the approach works. A modernization program that shows nothing for six months isn't lower risk than a rewrite. It's a rewrite with better branding.

Start with what the architecture prevents, not with what would replace it.

Full guide — all seven R's, the sprint model, and partner selection criteria: see the full guide

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.

Every AI Readiness Score Skips the Part That Actually Blocks You

Teamvoy — Tue, 01 Sep 2026 17:42:44 +0000

Over 85% of AI projects fail to reach their full potential, and the reason is almost never that the model didn't work. It's infrastructure, data hygiene, governance, or missing skills.

Which is what readiness assessments are supposed to catch. Except most of them stop exactly where the blocking problems start. They score strategy, data, infrastructure, governance, and culture — all at the level a survey can reach, filled in by one executive, without an engineer in the room.

So you get a "governance: strong" rating that means a policy document exists. It does not mean a model-risk committee, a SOC 2 auditor, or an enterprise security team will accept that policy as evidence. Those are different questions, and you find out which one you were answering months later.

Score yourself before paying anyone

Eight questions. More than two "no" answers means a formal assessment will find real gaps — useful information, not a reason to skip it.

Strategy — Is there a named AI initiative with a defined business outcome, or is "we're exploring AI" the whole plan?
Data — Can the team point to the specific source an AI feature would read from, and confirm it's clean enough to trust?
Infrastructure — Does the current setup support the latency and scaling the feature needs, or would it need rework first?
Governance — Is there a named owner for AI decisions with a documented approval path, or does responsibility sit nowhere specific?
Culture — Have the engineers who'd build this used the intended tools before, or would it be a first attempt under deadline pressure?
Codebase health — Would a new engineer joining today understand the code well enough to safely add an AI component, or is onboarding already a multi-week process?
Evaluation coverage — Is there any automated way to check whether a model's output is correct, or does a person read it?
Regulatory evidence (regulated industries) — Can you produce model risk documentation, an audit trail, and a data residency answer today, or would all three be built from scratch?

Six or more "yes" and you're closer to production-ready than most tools assume by default. Fewer than four points at a real assessment before committing engineering time.

The two questions nobody's scorecard asks

Codebase health. This is the one that actually decides whether a pilot ships. 88% of organizations use AI in some form, but fewer than 20% track results for generative AI specifically — a measurement failure that starts in engineering, not strategy. Pilots stall for three repeating reasons: the codebase is too tangled to hold a new component safely, test coverage is thin enough that every change risks something else, and the team is overloaded or missing the specific skills the project assumed. None of those show up on a strategy survey.

Eval coverage. If correctness is checked by a person reading output, you don't have evaluation, you have review. That works until volume arrives.

If you're regulated, "governance" is six separate things

A generic assessment treats governance as one pillar. For a bank, lender, payments company, or insurer it has to produce evidence someone external will accept:

Model risk management — SR 11-7-style validation. Who approved the model, what it was tested against, how drift is monitored after deployment.
Audit trail — every model decision that touched a real transaction, retained and retrievable, not logged and forgotten.
Data residency — where training and inference data physically sits, and whether a provider outside the EU ever touches EU customer data.
EU AI Act classification — whether the feature is high-risk, which changes the documentation burden before deployment.
SOC 2 and PCI DSS — proof the AI layer didn't open a gap in controls that were already passing.
FFIEC and NYDFS Part 500 — examiner expectations for third-party risk now extend to AI vendors and AI-generated decisions.

Pass a generic assessment on governance, then stall in compliance review months later. Same failure the assessment was meant to prevent, just moved downstream.

If you're AI-native, the question is inverted

You're not asking "can we deploy AI safely." You're asking "will our product survive an enterprise buyer's security review." Five things get asked, in roughly this order:

Multi-tenancy isolation — can one customer's data, prompts, or fine-tuning artifacts reach another's session? This is the first question, every time.
Eval harness maturity — automated evaluation covering multi-step paths, not a spot check before release.
RAG infrastructure — document versioning, access control at the chunk level, stale-index detection.
Production monitoring — observability on every model and tool call, so a bad output traces back to the input that caused it instead of being reported by a customer.
SOC 2 readiness — whether the posture needed to close the deal exists or is aspirational in a deck.

Score well on a generic readiness tool and still lose the deal, because the tool never asked any of these.

The mistakes that turn a diagnostic into shelfware

Treating the score as pass/fail. A 60% isn't a verdict, it's an ordered list of what to fix. Waiting for a perfect score delays a project that could have shipped after three specific fixes.
Running it without the engineers who'd build the feature.
Never re-running it. Readiness changes as gaps close, and you have no way to confirm the fixes worked.
Choosing by brand recognition rather than scope. A strategy tool answers whether leadership is aligned. An engineering tool answers whether the codebase can carry what's planned. They aren't substitutes.

The useful thing about a readiness assessment isn't the number. It's finding out, before the budget moves, which of these questions you can't currently answer.

Full comparison of ten tools — what each scores, who it fits, what it costs: teamvoy.com/blog/best-ai-readiness-assessment-tools-in-2026

Written by Zhanna Yuskevych, CPO at Teamvoy. More engineering writing at teamvoy.com/blog.

Most of You Should Not Be Custom-Building an Ecommerce Store

Teamvoy — Mon, 31 Aug 2026 12:08:25 +0000

Ecommerce projects rarely get hard because of the storefront. They get hard when the storefront has to meet the needs of the rest of the business.

Inventory already lives somewhere. Orders land somewhere else. Finance has its own systems. Payments drag security and compliance into scope. And the platform picked in month one defines what's easy, expensive, or impossible two years later.

Which is why the first question shouldn't be Shopify vs Magento vs WooCommerce vs custom. Starting there means arguing about features before anyone understands the constraints. The better opening question: what are we actually building, and which parts genuinely need to be custom?

For most people reading this, the honest answer is buy a platform and move on.

The phase ordering that costs the most

Seven phases: discovery, architecture and platform selection, design, build and integration, data migration, compliance and security review, launch and first optimization. Four to seven months for a mid-market build.

The sequence matters more than the labels, and one inversion is expensive above all others: choosing a platform before you've scoped compliance. Do it in that order and a compliance finding can force a re-architecture eight weeks into the build.

Two phases account for most overruns:

Build slips because discovery missed a system. The integration nobody scoped in phase 1 surfaces two months late, when the schedule has no slack left. Discovery in commerce isn't about pages — it's about finding every system holding a number the store needs, and finding who can grant access to it. That list is always longer than the brief.
Compliance review slips because it was treated as a formality. Remediation lands on a team that has already released its engineers.

Both are schedule problems created long before they appear.

Staffing note worth agreeing in writing before kickoff: phases 1, 2, and 6 need someone on the client side — a person who can get you into the ERP, whoever signs the contract, and named owners for the payment page and accessibility. Phases 3, 4, and 5 can sit almost entirely with the build team. The three phases you have to staff are the three that stall when nobody's free.

Three dates that already passed

These are no longer planning questions. They're evidence questions.

PCI DSS v4.0.1 req 6.4.3 and 11.6.1, in force since 2025-03-31. Inventory every script on the payment page, authorize each one, justify why it's there, and detect unauthorized changes to page headers and content. The catch: the scripts in question are usually marketing tags nobody in engineering added. PCI now has an owner problem — the tag manager on checkout needs a named owner and an approval step.
European Accessibility Act, Art. 2(2)(f), applying after 2025-06-28 to ecommerce services sold to EU consumers. Measured against EN 301 549, which points at WCAG. "We'll do accessibility after launch" is now a statement about legal exposure, not backlog priority.
GDPR / CCPA / CPRA, unchanged but load-bearing. Consent, access, and deletion paths wired into the customer data model rather than bolted on. If a deletion request can't be executed against the customer record without an engineer, it doesn't scale past the first hundred.

Accessibility written as an acceptance criterion in phase 3 costs days. Discovered in phase 6, it costs weeks. Same work, different bill.

Checkout: the causes are business decisions, not design problems

The average documented cart abandonment rate is 70.22% (Baymard, across 50 studies, updated 2025-09-22). Among shoppers who intended to buy, the top causes:

Extra costs shown too late — shipping, tax, fees — at 40%.
Slow delivery, 20%.
Distrust of the payment form, 19%.
Forced account creation, 18%.

Three of those four are decisions no redesign can make on your behalf. In order of what actually abandons carts: show the full total on the cart page, offer guest checkout, give a real delivery date rather than a shipping-method name, make the payment step look like a payment step, and cut every optional field.

Run A/B tests only after those five are in place. Below a few thousand checkouts a month you don't have the traffic to detect a one-point conversion change without weeks per variant, and teams routinely call the result on day four because the chart looks decided. Testing earns its place above the checkout — category layouts, product page structure, price and delivery presentation — where there's more traffic per decision.

Where AI actually earns its place

The test: does the model's output change a decision somebody was already making on worse information?

Demand forecasting and replenishment. Output is a purchase order quantity. Error is countable against what sold.
Fraud and chargeback scoring. Output is a score with a threshold. Both false positives and false negatives show up in the finance report — which means the review interface is in scope, not a follow-up.
Search and merchandising, but above roughly ten thousand SKUs, where manual merchandising already stopped covering the tail.

Where it doesn't: personalization on a 200-SKU catalog has too little behaviour to learn from and the engineering cost lands anyway. Dynamic pricing on consumer goods invites a customer to screenshot two prices and post them. Generated product copy at scale reads like generated product copy at scale, on exactly the pages you wanted indexed.

Separately — AI in the build is a different question from AI in the store. Coding assistants compress phases 3 and 4. They don't touch 1, 5, or 6, which is where the schedule risk lives, because those are constrained by other people's systems and by evidence someone has to sign.

Composable, honestly

Headless decouples the front end and is a configuration option on several hosted platforms. Composable replaces the engine with separate services. Headless is a weekend of architecture; composable is a program of work. The terms get used interchangeably and shouldn't be.

On a composable build, expect the first feature to take four to six weeks longer than on a coupled platform, and expect payback to start around the third. If your roadmap has three changes in it, the arithmetic doesn't work.

You also inherit a service layer somebody maintains, and six services that fail in more ways than one platform does. "Wanting to be modern" is not a reason. Multi-channel selling from one inventory, or business rules no vendor has productized, are.

If the reason is real, migrate incrementally: routing layer in front of the existing store, move one capability behind it, run both, move the next. Search and product content first — read-heavy, low-risk. Checkout near the end, because it handles the money and the compliance scope. Teams that move checkout first take the program's largest risk before learning anything.

The three-year number

Build cost is the number in the quote and the smaller half of the decision. A $70,000 build with $12,000 annual maintenance and $1,500 a month in platform fees is a $160,000 commitment before a single new feature ships.

Price every platform over three years, because the fee structures behave differently: revenue-percentage platforms get more expensive as you succeed, self-hosted charges you in engineering hours whether you grow or not, licence-plus-build front-loads and holds steady. Ask each vendor what the bill looks like at three times current volume, and get it in writing. That belongs in phase 2, not the post-launch review.

And then the question underneath all of it. Under roughly $5M in annual online revenue, with a standard catalog and standard checkout, buying wins on price, time, and risk. Custom development is the answer to a named business rule you can attach a cost to living without — never to a general preference for control.

Full breakdown — all seven phases, the platform comparison table, and the build-vs-buy signals: see the full guide

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.