WordPress · AI
AI content scorer for Google E-E-A-T
SEO content tool (WordPress plugin)
WordPressPHPDeepSeekFroala
AI in product
AI features wired into the product you already ship.
You have a working application and a roadmap line that says AI. Integration means wiring the model call into a real feature, then measuring it against a labelled set before it ships.
The brief, honestly
The model call is the easy part.
A product team rarely asks us to build AI. They ask us to make one screen smarter: score this draft, sort this queue, pull the numbers out of this document. That is a feature request with a model inside it, and it gets scoped like a feature.
So the work is mostly not the prompt. It is the output schema the rest of your code can trust, prompt versioning so you can tell which version produced last Tuesday's answer, and an eval harness run against a labelled set your own team scored by hand.
We have shipped this shape of work already: an AI content scorer running inside a WordPress plugin, and the server-side boundary that keeps a provider key out of the browser. Both are named further down this page. Neither was a demo.
Problem 01
The board keeps asking where our AI is.
We start from the screen, not the model. One feature where a model measurably beats what your users do by hand, scoped small enough to kill if it doesn't.
Problem 02
We shipped an AI feature and nobody can tell if it's good.
An eval harness on a labelled set your team scored, run on every prompt change, so 'better' is a diff you can read rather than a feeling in the room.
Problem 03
Our token bill jumped and we don't know which feature did it.
Token cost telemetry per feature and per customer, logged from the first call, so the invoice is attributable before it is alarming.
Problem 04
Legal won't let the model see customer records.
We scope what leaves your servers field by field, redact before the call, and keep human-in-the-loop review on anything that writes back.
What's included
Scope, spelled out.
Use-case and value check
Before anything is built, one honest pass on whether a model beats the rule you could write instead. Sometimes it doesn't.
Scoring and classification
A scoring model or classifier wired into your existing screens, returning a number and a reason your users can act on.
Structured extraction
Pulling fields out of documents, emails and free text into a typed output schema the rest of your application can validate.
Prompt versioning
Prompts in the repo, versioned like code, with the version recorded on every stored output so you can explain last month's answer.
An eval harness
A labelled set, a scoring script and a pass threshold in CI, so a prompt change either clears the bar or fails the build.
Human-in-the-loop review
A review queue for the cases the model should not decide alone, plus the audit trail of who overrode what and why.
Token cost telemetry
Per-feature and per-customer usage logging from day one, so cost per active user is a dashboard line and not a monthly surprise.
How we work
What actually happens, week by week.
01
Value check
A short pass deciding whether a model earns its place in this feature, or whether plain code wins.
02
Schema first
We design the output schema and the prompt together, so your code validates the answer it gets back.
03
Eval harness
Your team labels a real sample. We build the scoring script and set the bar the feature must clear.
04
Flagged rollout
Ships behind a flag to a slice of users, with the fallback path tested before the flag flips.
05
Telemetry
Cost and accuracy on a dashboard from the first day, reviewed monthly against the labelled set.
Tech stack
The tools we actually use here.
A model is a dependency, not the architecture. What matters is the application it sits in and the schema it answers with, so this list is your stack with a provider attached.
LaravelNode.jsReactTypeScriptWordPressMySQLPostgreSQLAnthropic ClaudeOpenAIGoogle GeminiDeepSeekOpenRouterMCP
What you get
Deliverables, outcomes and who this is for.
Deliverables
- Use-case and value assessment
- Versioned prompts in your repo
- Typed output schema and contracts
- Eval harness with a labelled set
- Feature behind a flag, with fallback
- Cost and accuracy telemetry
Outcomes
- An accuracy bar the feature must clear
- Prompt changes reviewed like code
- Token cost attributable per feature
- Humans in the loop where it matters
Ideal client
Product teams with a live application and one screen that would be better if a model looked at it first.
Proof
The AI we've actually shipped.
What the case card leaves out
The plugin scores a draft against Google's E-E-A-T and Helpful Content guidelines, returns category-level insights per section rather than one verdict, and flags recommendations by likely impact — all inside a real-time Froala editor where the author already works. The hard part was the output schema, not the model choice.
The same team ships the boundary
For Froala's AI Assist we built the WordPress side that calls DeepSeek from the server, so the key never reaches the browser. It is a shipped, public product. If your model calls currently leave from client-side JavaScript, closing that gap is work we have already shipped.
Frequently asked
Questions we get on the first call.
We can't quote it, and neither can anyone who hasn't seen your prompts and your traffic. What we can do is instrument it: cost per call, per feature and per customer, visible from the first week. Then you can watch it and cap it. No estimate survives real users.
You label a sample of real cases, scored by the people who know what right looks like — usually your support or content team, not us. That set becomes the answer key for the eval harness, with a pass threshold wired into CI. A prompt change that drops below it fails the build. Same as a broken test.
We've built on Claude, OpenAI, Gemini and DeepSeek, and we hold no badge from any of them, which is the point. The pick follows the task, the latency you can tolerate and the price you can live with. Prompts sit behind one interface in your code, so swapping provider is a config change, not a rewrite.
Then you turn the flag off and the product carries on. That is why the feature ships behind one, and why the model call sits behind an interface instead of being sprayed through your controllers. Removing it should be an afternoon of deletion, not a migration. Build it so it can be killed.
Yes — the feature can only read what you send it. So we decide field by field what goes, redact the rest before the call, and write the list down so your legal team reviews a document rather than a guess. If a field can't leave your servers, we design the feature without it.
Related services
More in AI Development & Integration.
Pick one feature and make it measurably better.
One call, 30 minutes, with the engineer who'd write the prompt and the eval. Bring the screen you want smarter and a sample of good output.