Connecting Claude to the Platforms We Build On

One model plans. A different model builds. Nothing ships unchecked.

This is the standard for all platform work. It exists because the failure we keep repeating is not bad code — it is building the wrong thing quickly, then discovering it at the client review.

Plan with Fable

The output of this phase is a written plan you would be comfortable handing to a contractor who has never seen the account.

Feed it the real context first

Before asking for a plan, put the source material in front of it — the same four sources we use for everything: meeting transcripts (highest trust, most recent wins), client emails sent and received, Slack, and whatever already exists on the platform today. A plan built from a task title is guesswork with better formatting.

What the plan must contain

Stress-test before you accept it

Ask the planner to grade its own plan against the goal, out of ten, and to say exactly what is missing. Then fix what it names and ask again. Keep going until it stops finding real gaps. Two or three rounds is normal and takes minutes.

When the stakes justify it

For a significant strategic piece — a new service, a pricing structure, a campaign the whole month depends on — run the same prompt through more than one model and compare. Where they agree, you can move fast. Where they disagree is exactly where you need to think.

Get the connection

Every platform reduces to the same four questions. Answer them before you write a line of anything.

Any REST API — the baseline pattern

Everything below is a variation on this. Learn it once.

Set it up so the key never appears in your work

# put the key in the environment, not in the file you are editing
export CLIENT_API_KEY="..."

# confirm the connection works before building anything on top of it
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $CLIENT_API_KEY" \
  https://api.example.com/v1/me

Prove the smallest thing first

Read one record before you write one. Write one test record before you write fifty. Every hour lost to a bulk operation that ran with the wrong field name could have been saved by a single-record test that took thirty seconds.

Three things that will bite you

• Rate limits. Find the number before you hit it. Add a small delay between calls by default.
• Silent partial success. A 200 response does not always mean the change took. Read the record back and compare.
• Different shapes for read and write. Many APIs return one structure and accept another. Never assume the object you fetched can be posted straight back.

Hosting and WordPress

Our most common build. Hosting on Hostinger, WordPress with Elementor, domain usually elsewhere.

Access to request, in order

Build pages as scripts, not clicks

Generating pages through the API means you can rebuild the whole site in minutes, review it as a diff, and hand it to someone else. Clicking through a builder means the knowledge lives in your head and dies when you move on. The full endpoint-level detail is in the Website Build Guide — read that alongside this one.

Wix

More closed than WordPress. Confirm what is actually possible on the client's specific plan before you promise anything.

What to establish first

• Who owns the account — the client, or an agency before us. This decides whether we can be added at all.
• The plan they are on. API and integration capability varies by plan, and a free or entry plan may not support what you are assuming.
• Editor or Studio. They behave differently. Know which one you are in before you quote a timeline.
• Whether the client edits it today. If they are used to editing their own site, whatever you build must stay inside the editor they already know.

The safe default

Where API access is limited or unclear, build inside the native editor and spend your effort on structure and content rather than fighting the platform. A clean site the client can maintain beats a clever one they cannot touch.

Framer

Powerful, and the easiest platform on which to accidentally deliver something the client can never edit.

How the connection works

You need an API key generated from the client's Framer workspace, and the specific site or project it applies to. Confirm which project before you build — workspaces routinely contain several.

Why this comes up constantly

Dropping in code is faster on the day and produces something that looks correct in screenshots. It also produces a page the client is locked out of forever, and they find out at the review. On Scivora that requirement was explicit from the client and it is now the standing rule for every Framer account.

Watch the credits

Framer's own AI features consume credits, and a project can stall mid-build when they run out. That is exactly what caused a nine-day delay on one account. Two responses: check the credit position before committing to a deadline, and know that building components directly through the API is a viable route when credits are gone.

Client-editable output is not optional

Across every platform, on every job, this is the constraint that decides whether the build was good.

Execute with Opus

Fresh session, finished plan, one step at a time.

How to run it

• Start clean. Give Opus the plan as the brief. Do not carry over the planning conversation — you want execution, not more debate.
• One step, then verify. Build a step, check it actually did what it claimed, then move on. Batching five steps means debugging five things at once.
• Make it repeatable. Prefer a script you can run twice over a sequence of manual actions you would have to remember.
• Stop when reality contradicts the plan. If something turns out to be impossible, go back and change the plan rather than improvising around it silently.

Built-in QA

Check it yourself before anyone else has to.

Look at it properly

Screenshot at a real desktop width, a tablet width and a phone width. Most of what gets sent back to us is a layout that was only ever viewed on a laptop.

Assert numbers, not impressions

"It looks fine" is not a check. Confirm the status code, confirm the certificate is valid, count the pages, count the links, and compare what you wrote against what the platform actually stored.

# does it load, and is the certificate real?
curl -s -o /dev/null -w "%{http_code}\n" https://clientsite.com/

# check every internal link, not a sample
curl -s https://clientsite.com/ | grep -oE 'href="[^"]+"' | sort -u

The gate

• Loads over HTTPS with a valid certificate, no browser warning
• Checked at desktop, tablet and phone widths
• Every link goes somewhere real — no placeholders left in
• Every form submits, and the notification actually arrives in a mailbox someone reads
• Images load, are the right ones, and sit in the client's own library
• Client can edit text and swap an image — tested, not assumed
• Nothing published contains a price, claim or credential nobody approved
• Backup exists from before you started

Handover

The job is not the build. The job is the client being able to live with the build.

• Credentials filed in the password manager, under the client, with a note on what each one opens.
• Show them how to edit it — a short walkthrough on the call beats a document nobody opens.
• Write down what you learned about that platform and add it to this guide. The next person should not rediscover it.
• Dashboard task closed, with the live link in it.
• Say what is still outstanding in writing, so nothing lives only in your memory.

Traps by platform

Quick reference

Which model, when

Before you start anything

• Read the last touchbase transcript for this client
• Plan written and stress-tested
• Every credential in hand, filed properly
• Backup taken
• You know who runs their email
• You know how the client will edit this afterwards

VersAssist · Contractor Guide · v1.0 · September 2026