Launched: pSEO Engine - programmatic SEO where the AI tokens run on your own key
The problem I kept hitting doing agency SEO: pSEO tools each cover one third of the job. Research here, generation there, publishing by hand. The handoffs are where the work stops being reproducible.
So I built the whole pipeline as one product:
- Research run: mines and qualifies the query space against live search data, rejects the queries that would produce a thin page. 50 metered actions, flat.
- Generation: 2 actions per page, from your template, nothing live until you approve it.
- Publishing: straight to the client's own domain, sitemaps generated.
- Tracking: rank checks on a schedule, weekly client report sent automatically.
- AEO/GEO: every page audited for whether answer engines can parse, quote and credit it — fixes applied where it fails.
The decision I keep getting asked about: BYOK. The AI tokens run on your own connected key - a free Gemini key works. I take zero margin on tokens. When tokens route through the tool, your per-page cost becomes someone else's markup; agencies did that math and walked away.
Pricing: $49 / $129 / $299 monthly tiers, quarterly cheaper, no annual contract. 75 free actions for 7 days covers one research run plus about 12 pages - enough to judge the writing before paying.
There's also a prepaid MCP track for AI agents (Pilot $499 / Scale $1,499 / Fleet $3,999): no card to sign up, read tools free, per-key daily spend cap, itemized ledger.
Live on a real client site: services.muabishalmakeup.in.
Site: https://quantumcx.net - ask me anything, that's what the comments are for.
Keeping approval separate from publishing is sensible. I reckon the more interesting challenge appears at 500 pages, where checking every page equally becomes the next bottleneck, while removing review creates the exact risk you’re trying to avoid.
Are you ranking pages by review risk: unsupported claims, unusual template deviations or duplicate sections, so the reviewer knows where to spend their time? If you can make human review selective without making publishing blind, that may end up being the real moat.
Great question — and an update: we just built exactly what you described. The Rows tab now has a "Risk first" sort: every unreviewed page gets a 0–100 risk score from signals that already exist — near-duplicates (dominant weight, they pin to the top), QA findings weighted by severity, answerability deficit, and generation errors. Each row shows its reasons in plain language, plus an "approve all low-risk" bulk action with a hard guardrail: visibly broken pages can never land in low band. Duplicates stay physically blocked at publish regardless.
We didn't pretend one score is the whole answer — the weighting lives in one documented file precisely because we want input from someone like you on how it should balance. If you want to poke at it: discovery is free, and the MCP surface exposes the same risk sort (seo_rows_list with sort:'risk') so your agents can triage a queue themselves. Founder here — tell me what the weighting gets wrong.
That is a strong direction. The bit I would watch is whether “low-risk” stays explainable enough that a reviewer trusts the shortcut, not just the score.
For weighting, I’d probably be harsher on anything that can damage trust publicly: unsupported factual claims, copied-looking sections, broken internal logic, or pages where the search intent and generated answer drift apart. Minor template deviations feel lower risk unless they affect meaning or conversion.
The plain-language reasons are the right move, though. A reviewer should be able to say “yep, I agree with why this is risky” in a few seconds. That’s where the score becomes useful instead of just another metric to babysit.
You just wrote our weighting spec — thank you.
Agreed on all four, and here's honestly where each stands: Copied-looking sections — we currently catch whole-page near-duplicates with shingle similarity; section-level similarity is the upgrade you're describing, and it's going on the list. Unsupported factual claims — we don't have a check for this today, and you're right that it's the worst offender for public trust. We'll add it as an AI-review code (we already run one for broken copy) so it surfaces as a reason line, not a mystery deduction. Intent drift — we store the search intent per row, so comparing the generated answer against it is straightforward; that check is going in. Broken internal logic — an extension of the existing QA pass.
And you're right about the inverse: template deviations that don't touch meaning should barely move the score. Our two cheapest weights (missing images, long meta) already sit at 3 and 2 out of 100 — so that part of the model agrees with you already.
The few-seconds test is now the acceptance bar: if a reviewer can't read a reason line and immediately agree or disagree with it, the reason line gets rewritten, not the reviewer blamed.
This thread is quietly becoming our QA charter. Mind if I quote you in the changelog when these land?
Of course, happy for you to quote me.
And honestly, this is a good sign: the fact you’re willing to turn a public comment thread into product input says a lot about how you’re building. The section-level similarity and intent-drift checks feel especially worth doing early, because they catch the kind of pages that look fine at a glance but damage trust later.
I’d be keen to see the changelog when it lands. This is the sort of boring QA layer that quietly matters a lot at scale.
That means a lot from someone who's actually reviewed pages at scale — thank you.
Both noted: section-level similarity and intent-drift go in as the next two risk signals. They extend to the subtle failure modes what whole-page duplicate blocking already does mechanically at publish — catching the "looks fine at a glance" class of page is exactly the right early priority.
And yes — the changelog lands in this thread, so you can hold me to it. (Or reach me directly via quantumcx.net/contact if that's easier.) When it ships, I'd genuinely value you hammering it: this QA layer is being built for reviewers exactly like you, and discovery is free whenever you want to kick the tires.
Deal — tag me here when it lands and I’ll give it a proper test. I’m especially curious to see how the intent-drift check handles pages that are technically relevant but answer the wrong stage of the buyer journey.
Stefan — it just went live. The Rows tab on any project now has a "Risk first" sort: every unreviewed page scored 0–100 with plain-language reasons, plus "approve all low-risk" for the mechanically-safe pages. Duplicates pin to the top, and the first version of the intent-drift check is in: a ready-to-buy query answered with an essay and no CTA weighs 20, a boilerplate-CTA undersell weighs 4, and "technically relevant, wrong stage" is exactly the failure mode it names in its reason line.
Same sort:'risk' is exposed over MCP (seo_rows_list) if you'd rather have your agents triage the queue. Discovery is free — hammer it. The changelog promise stands in this thread; section-level similarity is the next check in.
Deal. The risk-first queue is already merged on our side and deploys today — I'll tag you here the moment it's live so you can put it through a proper test.
And your buyer-journey framing is exactly the spec we'll build intent-drift against: "technically relevant, wrong stage" is a harder and more useful check than plain topic-matching. You'll see it in the changelog.
That was quick. Nice one.
The “ready-to-buy query answered with an essay and no CTA” example is exactly the kind of intent drift I was thinking about. It is not wrong content, it is wrong usefulness for that moment.
I’ll give the risk-first queue a look and focus on three things: whether the reason lines are obvious in a few seconds, whether low-risk really feels safe to bulk approve, and whether the buyer-stage mismatch gets caught without over-penalising genuinely educational pages.
Section-level similarity as the next check also makes sense. That should catch the sneaky “every page is technically unique but reads the same” problem.
That was quick because the thread was already the spec — thank you for reviewing it like a reviewer, not a prospect.
All three of your test criteria are answerable today, and the third check shipped with this deploy:
Reason lines — every finding is one sentence built to be agreed or disagreed with in seconds: "Ready-to-buy query 'emergency roof repair…' answered with an essay and only a boilerplate CTA — the body never asks for the sale." The standing rule from earlier in this thread applies: if a reviewer can't tell why a page is flagged, the reason line gets rewritten, not the reviewer blamed.
Low-risk bulk approve — "low" only ever means mechanical safety: no whole-page or section-level duplication, no truncation, no funnel-stage failure, no trust-damaging signal. Any single real signal tips a page out of low, so risky pages can't hide inside a bulk approval.
Educational pages — intent-drift penalizes only the wrong-stage-plus-nothing-to-act-on combination. A genuinely educational page on an informational query is the success case and scores zero; the heavy 20-point verdict needs a ready-to-buy keyword and no conversion path anywhere. The boilerplate-CTA undersell is 4 points — a nudge, not a verdict.
And section-level similarity is live as of today: an inverted shingle index across every page in a project, so the "technically unique but reads the same" failure gets caught at the section level — a borrowed intro or a recycled FAQ body weighs 25 and pins the pair to the top of the queue. Shared template furniture (nav, footers, CTA blocks) is exempted so templates don't false-positive.
Both surfaces are up: the Rows tab "Risk first" sort, and sort:'risk' over MCP (seo_rows_list). Discovery is free — put the queue through the proper test you promised. The changelog will name-check you; you did write the spec.
Fair enough, you shipped the actual thing, so I’ll do the proper test.
The section-level similarity detail is the part I’m most curious about now. Exempting template furniture is the right call, because otherwise every scalable content system gets punished for having a consistent layout. The real test is whether it catches reused substance without flagging reused structure.
I’ll look at the queue through that lens: false positives on shared page furniture, false negatives on recycled sections, and whether “low-risk” still feels safe when several small signals stack up across a project.
If the reason lines hold up under that, you’ve got something reviewers can actually trust.
This is the right lens, and it maps one-to-one onto how the check is built.
Substance vs structure: structure is exempted by footprint, not by guessing — any phrase appearing across a large share of the project's pages is furniture by definition (that's how shared nav, footers, and CTA blocks stay silent), and cross-section matches don't count. Substance is what remains: verbatim 8-word runs in the intro/body/FAQ prose, and ≥50% coverage of a section is the verdict. The test suite pins the exact pair you're describing — a borrowed intro that whole-page dedupe waves through and the section check catches.
False negatives: the honest one is paraphrase. The check matches verbatim runs, so a heavily rewritten recycled section slips past it — which is why it sits a tier below whole-page dedupe rather than replacing it. If your testing finds recycled substance getting through, that's the dial to name.
Stacked small signals: each weak category caps at its own weight (intent undersell, unsourced stats, cosmetics), so several small signals together currently top out inside "low" by design — no single category can pile up into a fake emergency. If real-world stacking changes where that ceiling belongs, it's one constant to move, and I'd rather calibrate it against your review session than guess.
Also: the fourth signal from your original review — unsupported factual claims ("studies show 73%…") — is built and goes out with the next deploy. And the standing rule holds: if a reason line doesn't survive your test, tell me which one — it gets rewritten, not you blamed.