Live Case Study

MessageBlue Week 3 of 13

This is a case study written while it is still happening. MessageBlue is three weeks into a thirteen-week programme, the measurement phase does not start until week nine, and nobody involved yet knows how it ends.

We publish it this way because the alternative is the format every agency uses: written afterwards, by the party being paid, once the failures can be left out. Our own buyer's guide tells people to treat that as a claim rather than evidence — so we could not reasonably produce one.

The week-by-week log What this doesn't claim How it differs from the standard programme
Week 3/13BuildOutcome unknownUpdated weekly

Request an AI Visibility Audit

See where your product sits before committing to anything.

No credit card · We'll never share your details.

What is MessageBlue trying to be found for?

Developers evaluating how to give an AI agent a phone number increasingly ask an assistant before they open a search engine — describing the problem in a sentence and getting two or three tools named back. MessageBlue is a young product in a category that barely has a name yet, which makes the retrieval question sharper than usual: there is no established set of sources for a model to draw on, so what exists gets used.

  • Category is unnamed — buyers describe the problem, not the product
  • Docs are the sales page for this audience, and have to be retrievable
  • Comparison intent dominates — the question is usually “X or Y”
  • Evaluators are technical, so a vague answer is worse than none
  • No local dimension — nothing here depends on geography

MessageBlue — The iMessage API built for AI agents — conversational agents that send and receive messages programmatically.

Where This Differs From the Standard Programme

The Accelerator was built for local businesses, and two of its standard pieces do not apply here. There is no Google Business Profile for a developer API, and no fee intake session when pricing is usage-based and already public.

Those slots carry different work rather than being dropped: documentation retrievability in place of profile optimisation, and comparison and alternatives coverage in place of cost pages. The four phases and their week boundaries are unchanged, because the sequencing is the method — measuring before building is the whole point of it.

The Log

Week by Week

Each week states what was planned before it ran, and what was actually done once it had. The plan stays visible afterwards so the gap between the two is legible rather than quietly edited away.

Week 3 of 13 · Build 3 logged
Weeks 1–2

Baseline and audit

Agree the prompt set, sample the current citation position before anything changes, and audit whether the site and documentation can be retrieved at all.

  1. Week 1 Complete

    Planned Prompt set drafted and signed off. Baseline sampling run one across the agreed queries, recording which tools are named and which sources are cited.

    Draft — not yet confirmed

    Done DRAFT — replace with what actually happened. Prompt set agreed and first baseline run captured, recording who is named today and which sources the answers draw on.

  2. Week 2 Complete

    Planned Second and third baseline runs to establish variance. Technical and retrievability audit covering rendering, indexing and whether documentation is readable without executing scripts. Entity review across GitHub, package registries and developer directories.

    Draft — not yet confirmed

    Done DRAFT — replace with what actually happened. Remaining baseline runs completed, technical audit delivered, entity inconsistencies listed with owners.

Weeks 3–6

Build

Answer the questions the baseline showed going to someone else. Technical fixes, entity and schema work, comparison and documentation coverage, article production begins.

  1. Week 3 In progress

    Planned Build starts. Highest-priority technical fixes from the audit, schema and entity corrections, and the first comparison and documentation pages drafted against the questions the baseline showed going elsewhere.

    Draft — not yet confirmed

    Done DRAFT — replace with what actually happened, or delete this line if week 3 is still in progress.

  2. Week 4 Scheduled

    Planned Documentation retrievability work: the facts an evaluator needs available in plain HTML rather than behind an interaction a retrieval system will not perform. Article production begins.

  3. Week 5 Scheduled

    Planned Comparison and alternatives coverage extended to the remaining questions from the baseline. Entity corrections submitted to the third-party sources that carry them.

  4. Week 6 Scheduled

    Planned Remaining technical items closed out. Internal linking and information architecture reviewed so the new pages are reachable. Build phase content complete.

Weeks 7–8

Review and publish

Technical review batched into one pass, revisions, publication, and crawl and indexation confirmed in Search Console rather than assumed.

  1. Week 7 Scheduled

    Planned Technical and factual review batched into a single pass rather than trickled — accuracy on a developer-facing page is checked by someone who can read the API.

  2. Week 8 Scheduled

    Planned Revisions applied, everything published, crawl and indexation confirmed in Search Console. Nothing is counted as live until it is confirmed indexed.

Weeks 9–13

Measurement

Three separate sampling runs across the same prompt set used in week one, then a written report covering what was built, what moved, and what did not.

  1. Week 9 Scheduled

    Planned Measurement run one, against the same prompt set used in week one. First point of comparison with the baseline.

  2. Week 10 Scheduled

    Planned Analysis of run one: which questions moved, which did not, and which sources the answers are now drawing on.

  3. Week 11 Scheduled

    Planned Measurement run two. Repeated rather than single, because one run is an anecdote.

  4. Week 12 Scheduled

    Planned Measurement run three, completing the three sampling runs. Variance across the three assessed before any conclusion is drawn.

  5. Week 13 Scheduled

    Planned Written report: what was built, what moved, what did not, and what we would do differently. Published here in full, whatever it says.

What This Page Does Not Claim

Three weeks in, with the first measurement run scheduled for week 9, the honest list of things this page cannot yet tell you is longer than the list of things it can.

  • Whether any of this worked. The first measurement run is week 9; there is no before-and-after to show yet, and any number quoted now would be noise presented as progress.
  • Traffic, sign-ups or revenue attributable to the work. Some of that is not cleanly attributable at all, and we would rather say so than model it.
  • That the approach generalises. This is one product in one category with no local dimension. A single engagement is not a method validated.

All three will be answerable in week 13, and the report will be published here whatever it says — including a flat result. A case study that could only ever have ended well is an advertisement with dates in it.

See Where Your Product Sits Today

Every programme starts with the same baseline this one did: an agreed prompt set, sampled before anything changes, so there is something to measure against later. Request an audit and you get that much before any commitment.

Read the Accelerator scope and price, or the published citation studies behind it.