# Message test — https://spd.tech/ai-studio/ After reading your page, 12 of 15 personas could quickly tell what problem it solves and who it is for. - **Page tested:** https://spd.tech/ai-studio/ - **Audience tested against:** CIOs and transformation leaders who are mass-adopting AI coding agents: output quality varies; procurement & diligence pressure; can’t prove AI ships safely at scale. CTOs & engineering leaders whose AI agents produce inconsistent, unreproducible results; no shared rules file; “it worked yesterday” incidents; a model update nobody dares make. Non-tech founders and CEOs whose Lovable / Cursor / Bolt / Claude prototypes broke under load; just funded; real users, real data, real money now touch the product. - **Personas:** 15 simulated - **Report:** https://grader.wynter.com/r/ai-studio-by-spd-technology-from-first-idea-to-4w-jVwE > These answers are generated by AI, scored on Wynter's B2B Message > Layers framework using behaviorally-diverse simulated personas. The > methodology is real and the critique is directional. What a simulated > persona cannot have is a live budget, a renewal coming up, or a boss > asking about this quarter. --- ## 01 · The scores Every persona answered all four questions. These are four independent proportions of the same panel, not stages of a funnel. | Layer | Question | Cleared the bar | Strength | Of those who passed | | --- | --- | --- | --- | --- | | 1. Clarity | Do they understand what you do? | 15/15 | 88% | 7 without hesitation, 8 with reservations | | 2. Relevance | Can they tell what it solves, and who it's for? | 12/15 | 68% | 1 without hesitation, 11 with reservations | | 3. Value | Do they actually want it? | 14/15 | 74% | all with reservations | | 4. Differentiation | Is there a reason to pick you over the alternatives? | 13/15 | 70% | all with reservations | **Brand alignment** (a side metric, not one of the four layers) — 15/15, 78% strength (all with reservations). Does the page read like the company you actually are? **Fix first: Relevance.** Earliest failing layer, walking the sequence in order — not simply the lowest score. --- ## 02 · What to change, layer by layer Ordered worst-first. Specific edits, not a restatement of the score. ### Relevance **Rewrite the opening line to name the reader's situation instead of "Choose how we work together."** The first screen asks the reader to pick a path before telling them what is being sold or who it is for. Open with the job: shipping, hardening or scaling AI software that has to work in production. *effort medium · impact high · tested against Lead with the use case* **Name AI-prototype failures under the Vibe-to-Scale heading: broken auth, no tests, model updates breaking flows.** A founder whose Lovable or Cursor prototype is falling over cannot tell this page is for them. Replace the abstract "real users, data and production demands" with the actual failures: no auth, no tests, rewrites every time the model changes. *effort low · impact high · tested against Problem before solution* **Add a regulated-industry line under the Release Evidence Package naming finance, health or audit use.** Buyers in regulated sectors cannot tell whether this evidence package has survived a real audit or change-control review. Name the sectors served and what the package satisfies. *effort low · impact high · tested against Name the audience* ### Differentiation **Move the Release Evidence Package contents above the six track cards.** The one thing that separates this from any other dev shop sits at the bottom of the page, after six similar-looking offers. Lead with the inspectable record, named-engineer approval and rollback steps. *effort medium · impact high · tested against Give a reason to choose you* ### Value **Add measurement window, baseline and sample size beside each case study metric.** Readers dismissed the case numbers because nothing says what was measured, over what period, against what starting point. Put the baseline, the window and the scope next to each figure. *effort medium · impact high · tested against Proof next to the claim* ### Clarity **State on the first screen that this is engineering delivery work, not a subscription product.** Readers have to deduce from track names whether they are buying software or a team. Say plainly that you deliver engagements with named engineers and your team keeps the code. *effort low · impact medium · tested against Plain language* --- ## 03 · What is working ### Respondents read the business model correctly as engineering services, not a software… Four respondents stated unprompted that this is a services consultancy rather than a subscription or platform. The page removes that ambiguity without being asked. > The FAQ actually spells it out plainly — "It is SPD Technology's engineering service... not a software subscription you need to adopt" — which is the one line that stuck with me and cut through the jargon. > > — CIO, Technology Services, 1001-5000 > It's an engineering services shop that builds or hardens AI/software systems for you — basically a dev agency that specializes in shipping AI features and agents > > — Chief Technology Officer, SaaS, 5000+ > It is SPD Technology's engineering service... It is not a software subscription you need to adopt. > > — CTO, Financial Services, 51-200 > It's an AI/software engineering consultancy dressed up with a "Studio" label — SPD Technology sells services to either build you something from a business objective ("Define the solution together") or execute against a spec you already have ("Deliver against your direction") > > — Head of Engineering, Software Development, 501-1000 ### The two-path split communicates audience and use case before the page names either Four respondents said the two-track structure and problem statement land fast, letting them infer buyer profile and fit. One matched the Vibe-to-Scale offer to their own prototype hardening problem. > The two-path split up top — "I know the outcome. Help me find the way" vs. "I have a vision or specification. Help me ship" — tells you in about five seconds this is for someone with either a vague AI/software objective or an already-agreed spec > > — Chief Technology Officer, SaaS, 5000+ > the two-path split right at the top ("Define the solution together" / "Deliver against your direction") tells you this is for someone who either has a business objective without a build plan, or has a spec and needs execution > > — CTO, Financial Services, 51-200 > "Vibe-to-Scale: Harden a working AI-built prototype for real users, data and production demands" is close to a direct hit on my actual problem > > — Head of Engineering, Software Development, 501-1000 > the two-path split up top ("Define the solution together" vs "Deliver against your direction") tells you immediately this is for someone either without a spec or with one > > — Transformation Leader, SaaS, 5000+ ### The Release Evidence Package is the one concrete differentiator respondents could name Six respondents singled out the evidence package — scope, verification, named engineer approval, rollback — as the inspectable reason to choose this over Lovable or generic competitors. Two tied it to passing regulated audit and change-control. > I'd get a named senior engineer actually accountable for releases — "architecture, security, payments and personal data stay human-led, a named senior engineer approves every release" — plus that release evidence package (scope, verification, review, rollback) so my team isn't flying blind on model updates and deployment risk > > — CIO, Technology Services, 1001-5000 > "Architecture, security, payments and personal data stay human-led. A named senior engineer approves every release" is a concrete answer to the exact Lovable problem I have, output I can't trust going to prod unsupervised > > — Chief Technology Officer, SaaS, 5000+ > The release evidence package — tests, evals, named sign-off, rollback plan — is the one concrete thing that would change something for me, because it's a layer Lovable doesn't give me today > > — Chief Technology Officer, SaaS, 5000+ > the "Release Evidence Package" (scope/changes, verification results, review & approval, rollback plan) is the one thing that would matter to me as a regulated fintech, because it maps to what our own audit and change-control process already needs > > — CTO, Financial Services, 51-200 > The "release evidence package" — scope & changes, verification results, review & approval, release & rollback — is the one concrete thing that would tip me toward this over a generic AI dev shop > > — VP of Engineering, Enterprise Software, 201-500 > a named senior engineer accountable for release decisions, and an actual evidence package — "tests, AI evaluations, quality checks and security findings" > > — Transformation Leader, SaaS, 5000+ > The thing that would actually move the needle for me is the "Release Evidence Package" concept — scope & changes, verification results, review & approval with a named sign-off, and release & rollback instructions bundled per release > > — Engineering Leader, Technology Services, 1001-5000 ### Tone and vocabulary read as an established engineering firm aimed at mid-market… Five respondents said the vocabulary signals an experienced services firm rather than a startup agency, targeting engineering leaders at mid-market companies with live products and budgets. One noted it anticipates skeptical CTO objections. > the structured tracks ("Zero-to-One," "Platform Foundation," "Vibe-to-Scale," "Harness & Eval Engineering") and a named case-study roster (Blackhawk Network, a US fintech, a French fashion retailer) suggest they've done this enough times to productize the engagement > > — Chief Technology Officer, SaaS, 5000+ > The vocabulary gives it away: "acceptance criteria," "release gates," "named senior engineer approves every release," "TCO assessment" — that's written for someone who sits in change-approval meetings, which is me > > — Head of Engineering, Software Development, 501-1000 > the vocabulary ("acceptance criteria," "release gates," "platform ownership," "handover obligations") reads like people who've actually shipped and been burned, not agency copywriters. > > — CTO, Technology Services, 1001-5000 > I picture a mid-sized, established engineering consultancy — not a two-person agency, not a Big-4 systems integrator either. Probably 100-500 people > > — Engineering Leader, Enterprise Software, 201-500 > The tone does feel aimed at someone like me — "You bring the business objective," "You do not need to buy a transformation program first," the FAQ bluntly answering "is this a subscription or a service" — that's someone who's sat across from a skeptical CTO before > > — Chief Technology Officer, SaaS, 5000+ --- ## 04 · What the personas said ### Track names and brand naming obscure what is actually being bought Two respondents said the track names are jargon that hides the deliverable, and that positioning blurs between the AI Studio brand, the company name and a platform identity. > Mainly the jargon soup — "Zero-to-One," "Platform Foundation," "Vibe-to-Scale," "Harness & Eval Engineering" — none of those names tell you what you're actually buying until you read the bullet points underneath > > — Chief Technology Officer, SaaS, 5000+ > the product is branded "AI Studio" in places but the FAQ calls it "SPD Technology's engineering service," so I wasn't sure if AI Studio is the company, a platform, or just a marketing wrapper > > — Engineering Leader, Technology Services, 1001-5000 ### The page never names the specific AI-builder failures it claims to fix Three respondents said their problem — Lovable-style prototype pain, model update and deployment risk — is only reachable by inference from adjacent offerings, never stated directly. > I'd need it to name my exact situation — something like "already shipped with an AI builder like Lovable or Bolt, now dealing with inconsistent output and no audit trail before prod" — instead of the generic "vision or specification" framing > > — Chief Technology Officer, SaaS, 5000+ > the specific problem I came in with — model update and deployment risk management — is never named as such; I had to infer it might map to "Harness & Eval Engineering" or the release-evidence package, which is a stretch, not a direct hit > > — Engineering Leader, Technology Services, 1001-5000 > nothing maps them explicitly to "model update and deployment risk management," so I had to translate their vocabulary into mine > > — Engineering Leader, Technology Services, 1001-5000 ### Regulated-industry buyers want an unredacted artifact and a live reference before… Two respondents said the page lacks regulated industry language and a verifiable financial services case, and would require seeing an actual evidence package and reference customer first. > I'd want to see the words "regulated industry," "financial services," or "compliance" somewhere near the top, plus a case study from a bank or fintech of comparable size with numbers I can actually check — right now the fintech case is the closest but it's anonymized and missing the reporting period > > — Chief Information Officer, Financial Services, 51-200 ### Case study numbers are treated as unverifiable because measurement windows, samples and… Seven respondents rejected the case study metrics for lacking published test samples, measurement windows, baselines or defect data. One said the hedged numbers actively undermine the rigor positioning the page claims. > What would rule them out, or at least stall me, is that the case study numbers are hedged into meaninglessness ("the test sample and measurement window are not published") > > — CIO, Technology Services, 1001-5000 > the case studies are thin — "the test sample and measurement window are not published," "the reporting period is not published" — so I'd want one reference call with a company my size > > — Chief Technology Officer, SaaS, 5000+ > I was mentally comparing them to just having my internal platform team build a stricter review/eval gate on top of Lovable's output ourselves; to win that comparison they'd need to show the hardening is faster or cheaper than doing it in-house, with real numbers > > — Chief Technology Officer, SaaS, 5000+ > three separate admissions that those aren't published ("the test sample and measurement window are not published") tells me whoever wrote this prioritized narrative over the kind of rigor their own target reader would demand > > — Engineering Leader, Technology Services, 1001-5000 > the test sample and measurement window are not published > > — CTO, Financial Services, 51-200 > the case studies hedge every number ("the test sample and measurement window are not published," "the reporting period is not published"), which is exactly the kind of soft proof that got me burned last time > > — VP of Engineering, Enterprise Software, 201-500 > the three case studies all admit the sample size and measurement window "are not published," so I have no way to judge if 65-70% incident resolution or the conversion uplift generalize to my environment > > — Engineering Leader, Technology Services, 1001-5000 > the fintech and French retailer case studies explicitly say "the reporting period is not published" and "the observation period and pre-project baseline are not published" — so the numbers (65-70% resolved correctly, 99% <10s) are unverifiable as written > > — Head of Engineering, Software Development, 501-1000 --- ## 05 · The hardest read An adversarial pass over the findings. Every claim below was checked against the panel's own answers; unsupported ones were dropped. - **The page's own proof destroys the credibility its tone works to build.** *(high)* Seven respondents rejected the case study metrics for missing samples, windows, baselines and defect data, with one saying the hedged numbers undermine the rigor positioning — the same rigor five read into the vocabulary. - **The only differentiator respondents can name is an artifact they are not allowed to inspect.** *(high)* Six singled out the Release Evidence Package as the inspectable reason to choose this, yet two said they need an unredacted artifact and a live reference before acting; describing evidence is not supplying it. - **Buyers have to do the work of connecting the offer to their own problem because the page never names it.** *(high)* Three said Lovable-style prototype pain and deployment risk are reachable only by inference, and the two-path split works by letting people infer fit — relevance rests entirely on the reader's guesswork. - **Naming choices tax the one thing the page gets right.** *(medium)* Two said track names are jargon hiding the deliverable and that positioning blurs across AI Studio, company and platform identity, directly eroding the services-not-software clarity four others read correctly. - **The page sells to engineering leaders but fails the procurement gate those leaders must clear.** *(medium)* Five read mid-market engineering leadership as the target, yet two found no regulated-industry language and no verifiable financial services case — exactly the audit and change-control evidence two others tied to the evidence package. - **Structure is doing the persuasion that substance should be doing.** *(medium)* Four praised the two-track split and problem statement for landing fast, but seven rejected the numbers behind it — the page is organized well around claims that do not hold up. --- ## 06 · Who answered | # | Role | Industry | Company size | | --- | --- | --- | --- | | 1 | CIO | Technology Services | 1001-5000 | | 2 | Chief Technology Officer | SaaS | 5000+ | | 3 | CTO | Financial Services | 51-200 | | 4 | VP of Engineering | Enterprise Software | 201-500 | | 5 | Head of Engineering | Software Development | 501-1000 | | 6 | Engineering Leader | Technology Services | 1001-5000 | | 7 | Transformation Leader | SaaS | 5000+ | | 8 | Chief Information Officer | Financial Services | 51-200 | | 9 | CIO | Enterprise Software | 201-500 | | 10 | Chief Technology Officer | Software Development | 501-1000 | | 11 | CTO | Technology Services | 1001-5000 | | 12 | VP of Engineering | SaaS | 5000+ | | 13 | Head of Engineering | Financial Services | 51-200 | | 14 | Engineering Leader | Enterprise Software | 201-500 | | 15 | Transformation Leader | Software Development | 501-1000 | --- ## 07 · Before you act on this The methodology is real, and the critique is directional. What a simulated persona cannot have is a live budget, a renewal coming up, or a boss asking about this quarter. **Validate anything you're betting on with real ICPs who are actually in-market.** Being wrong is more expensive than you think. Finding out is cheaper than you'd guess. Wynter runs message testing with verified B2B professionals — trusted by HubSpot, RingCentral, Shopify, Cognism, Paddle, Veeam, Rippling and Miro. This report is kept for 60 days from 2026-10-20, then deleted along with the personas and their answers.