At SLTech I built BHS Custom Blocks, a WordPress Gutenberg plugin for Brown Harris Stevens, one of New York City's best-known residential brokerages. It has more than 70 custom blocks. The goal was simple to say and harder to deliver: editors should be able to build a full marketing page on their own, and it should still look like Brown Harris Stevens.

This post covers how I think about a block library that size: what goes in it, what keeps it consistent, and what makes editors actually like using it.

Why custom blocks, not a page builder

Page builders give editors a lot of freedom. That's the problem. With enough freedom, every page slowly drifts away from the brand: a slightly different blue, a new font size, a button that looks almost right.

Custom blocks flip that around. Each block is a finished piece of the design. The editor picks what goes on the page and fills in the content. The block decides how it looks.

For a luxury brand like BHS, that trade-off is worth it:

• The brand stays consistent on every page, no matter who built it.
• Pages stay fast, because each block only loads what it needs. There's no heavy builder framework on top.
• Editors can't break the layout by accident.
• It's native WordPress. Content stays in the standard editor, so there's nothing extra to learn or maintain.

What 70+ blocks actually covers

Seventy sounds like a lot until you list what a brokerage website needs. The blocks fall into a few families:

Grouping them this way matters for editors too. In the block inserter, they look for "an agent block" or "a hero", not for block number 47.

Keeping 70 blocks consistent

The hard part of a big block library isn't building block number 70. It's making sure block 70 still looks and behaves like block 1. A few rules make that possible.

One set of design tokens. Colours, font sizes, spacing and breakpoints should live in one place, shared by every block. If the brand blue changes, it should change once.

Shared building pieces. Most blocks are made of the same smaller parts: headings, buttons, image frames, cards. Build those once as shared React components for the editor and shared templates on the front end, and reuse them everywhere.

The same controls everywhere. If one block has its spacing setting in the sidebar, every block should. Editors learn the pattern once and it works across the whole library.

Clear naming. Every block gets a predictable name and lives in a clear category. Future developers will thank you, and so will editors searching the inserter.

Static vs. dynamic blocks

Gutenberg blocks come in two kinds, and choosing the right one for each block saves a lot of pain later.

• Static blocks save their final HTML into the post. They're a good fit for content the editor fully controls, like an editorial section or a quote.
• Dynamic blocks are rendered by PHP on the server each time the page loads. They're the right choice for anything that changes on its own, like listings or agent details, because the page always shows the current data.

A useful rule: if the content can change without an editor touching the page, make the block dynamic. Otherwise you end up with pages showing a sold property or an agent who left months ago.

Dynamic blocks have one more benefit for a library this size: when you change a block's design, every page using it updates at once. With static blocks, old pages keep the old HTML until someone re-saves them.

Designing for editors, not developers

A block is only useful if editors are comfortable using it. What helps:

• The editor preview should match the live page. If a block looks different in the editor than on the site, editors stop trusting it.
• Give fewer options, with good defaults. Every setting is a decision the editor has to make. Most blocks should look right the moment they're added.
• Use patterns for common pages. A ready-made layout for "new development launch" or "neighbourhood guide" lets editors start from a page that already works, then swap in their content.
• Write labels in plain language. "Background image", not "bg_media_id".

What I'd tell anyone building a block library

1. Design the system before the blocks. Tokens and shared components first. Building blocks one by one without them is how you end up with 70 slightly different buttons.
2. Default to dynamic for live data. Listings and people change; pages shouldn't go stale.
3. Fewer options make happier editors. Constraints are a feature, not a limitation.
4. Treat editors as your users. Watch them build a page. The confusing parts show up in minutes.

A good block library feels boring in the best way. Editors open WordPress, build the page they need, and it looks right. That's the whole point.

Need a custom Gutenberg block library or a WordPress build for your team? Get in touch.

I don't train models. I build things on top of them: chatbots, agents, internal tools that real users touch. So when I read a benchmark table, I'm not asking "which model is smartest?" I'm asking "which model should I put behind this feature, and what will break?"

Here's the full table, as Google published it:

Source: Google DeepMind's Gemini 4 Argon launch materials. Methodology at deepmind.google/models/evals-methodology/gemini-4-argon. Bold marks the best score in each row.

Start with who made the table

These are Google's numbers, picked and run by Google, for a Google launch. That doesn't make them wrong. It does mean the benchmark list was chosen by the team with the most reason to look good on it, and the competitor scores were measured under Google's setup, not each vendor's own.

So I treat a table like this as a strong hint, not a verdict. The independent leaderboards and, more importantly, your own tests come later.

Where Argon clearly pulls ahead

Gemini 4 Argon has the top score, or a share of it, in 14 of the 19 rows. Some of those wins are a point or two. A few are not, and those are the ones I'd pay attention to.

Very long context. At up to 128k tokens, every model in the table does fine, with all four between 90% and 99.7%. Between 256k and 1M tokens, Argon scores 84.2% and the next best is 71.8%. That's the biggest practical gap in the whole table. If your product needs to reason over a full codebase, a long contract or months of support tickets in one go, this row matters more than any coding benchmark.

Agents doing office work. AutomationBench (51.3% vs 42.5% for the next model) and Vals Finance Agent v2 (65.4% vs 58.9%) are both about multi-step tasks in business settings. Harvey's legal benchmark is the most striking on paper: 19.6% against single digits for everyone else. But read the absolute number too. Even the winner fails most of those tasks. "Best" and "ready to run unsupervised" are different things.

Charts and video. On LVBench and Chartography Argon leads, though GPT-6 Astra is close on charts (71.0% vs 71.6%).

The rows where it doesn't win are more useful

If you only look at the blue cells, you'd conclude Argon is the best choice for everything. The grey cells tell a more practical story.

Coding is close, and it depends on the kind of coding. On Vibe Code Bench, all four models land between 89.6% and 91.9%. That's close to a tie, and any of them will handle typical "build me this feature" work. The differences show up in the harder, more specific tests:

• Claude Opus 5.5 leads Terminal-bench 4.0 by a wide margin: 66.4%, against 57.4% to 58.2% for the others. That benchmark is about working in a real terminal over many steps: running commands, reading output, fixing what broke.
• GPT-6 Astra leads FrontierSWE v2 with 65.5%, ten points above Argon's 55.0%.
• Argon leads DeepSWE v1.1 with 77.9%.

Three coding benchmarks, three different winners. To me that's the most honest signal in the table. "Best at coding" isn't one thing anymore.

Science tasks done in the terminal go to GPT-6 Astra (68.1%), and ML engineering goes to Opus 5.5 (49.3%). In both cases Argon trails.

Computer use is thin data. Fable 5.1 has no scores here, and Opus 5.5 has none on OSWorld. GPT-6 Astra leads OSWorld-2.0, but on an "offline subset" with "partial score", which is a narrower test than the name suggests. I wouldn't pick a model for computer-use agents from these two rows.

How I'd actually use this

When I built the RAG chatbot for REConnect, I used Claude Haiku 4.5, which isn't in this table at all. It was the right call, because the job was answering from well-chunked context quickly and cheaply, not solving the hardest benchmark in the world. Most production AI features look like that. The model only needs to be good enough at a narrow job, and fast and affordable at scale.

So here's how I'd turn a table like this into decisions:

1. Match the benchmark to your workload. If your agent lives in a terminal, Terminal-bench tells you more than the overall win count. If you process huge documents in one pass, the 1M-token row is the one to read.
2. Run your own evals before switching. Take 50 to 100 real examples from your product, with known good answers, and run each candidate on them. That will tell you more than any launch chart.
3. Don't build for one model. Put a thin layer between your app and the model API, so swapping models is a config change, not a rewrite. With launches this frequent, the "best" model changes every few months.
4. Route by task if you can. Nothing stops you from using one model for long-document analysis and another for coding agents. The table practically argues for it.
5. Keep an eye on what the table leaves out. There's nothing here about price, speed or rate limits. For a live chat widget, those decide more than a two-point benchmark gap.

So, is Gemini 4 Argon the best model?

On Google's chosen benchmarks, mostly yes. It wins most rows, and in long context and business-agent tasks it wins by real margins. If those match your workload, it should be first on your list to test.

But the table also shows that the top models are now close on everyday coding, and that each one has areas it's clearly best at. That's good news for anyone building products. It means you can pick by fit, cost and speed, instead of feeling locked into whichever lab has the latest launch.

If you're choosing a model for a product feature and want a second opinion, get in touch. I'm happy to help set up a proper evaluation on your own data.

This post walks through the chatbot I built for REConnect, a real estate data platform, at SLTech. It started as a straightforward retrieval-augmented generation (RAG) widget and grew into an agent that can look things up, adapt its tone, and guide people through sign-up.

The stack

I picked a small, fast model for answering on purpose. In a support widget, latency is part of the experience — and when retrieval does its job, the model mostly needs to read and summarise well, not reason for a long time.

Step 1: Chunk the source documents

The knowledge base is the product's own content: pricing, MLS coverage, and FAQs. Each type of document has a natural shape, and chunking along that shape matters more than any clever splitting algorithm:

• FAQs — one question and its answer per chunk. Never split an answer from its question.
• Pricing — one plan per chunk, with the plan name repeated in the chunk text so it still makes sense on its own.
• MLS coverage — grouped by region/provider so a question like "do you cover X?" lands on a chunk that actually names X.

Every chunk carries metadata (source, section, last updated) so I can filter, debug, and re-index one source without touching the rest.

// Simplified: index one document's chunks into Chroma
const embeddings = await openai.embeddings.create({
  model: EMBEDDING_MODEL,
  input: chunks.map(c => c.text),
});

await collection.upsert({
  ids: chunks.map(c => c.id),
  documents: chunks.map(c => c.text),
  embeddings: embeddings.data.map(e => e.embedding),
  metadatas: chunks.map(c => ({ source: c.source, section: c.section })),
});

Step 2: Retrieve, then let the model answer

For each user message, the backend embeds the query, pulls the 10 most relevant chunks from Chroma, and passes them to Claude with a system prompt that keeps it grounded:

• answer only from the provided context and the user's data;
• say so plainly when the answer isn't there, and offer a next step (contact support, see pricing) instead of guessing.

Ten chunks is a deliberate trade-off. Too few and multi-part questions ("how much is the pro plan and does it cover my MLS?") miss half the answer. Too many and you pay for tokens the model has to wade through. Because the chunks are small and well-shaped, ten fits comfortably.

Step 3: From answering to acting

A pure RAG bot can only quote documents. Users kept asking things the documents couldn't answer — "is my listing live?", "which plan am I on?" — so I gave the bot tools:

• MLS provider lookups — check coverage against live data rather than a static page.
• Account, plan, and listing data for logged-in users — the bot can answer about their account, scoped strictly to the authenticated user.
• Guided sign-up flows — the bot can walk someone through creating an account, with explicit confirmation steps before anything is submitted.

The confirmation step is the important part. A model deciding to take an action is fine; a model taking it without the user seeing exactly what will happen is not.

Step 4: Make it feel right for each user

Role-aware tone. An agent, a broker, and a first-time visitor need different answers to the same question. The bot adjusts its tone and level of detail based on who's asking.

Rolling conversation summaries. Long chats are where costs and confusion creep in. Instead of resending the whole transcript, older turns are periodically folded into a running summary, and only recent turns are sent verbatim. The model keeps the thread of the conversation without the context growing forever.

Step 5: Production guardrails

The unglamorous part is what makes it shippable:

• Rate limiting per user/session, so one client (or bot) can't run up the bill or degrade the widget for everyone else.
• Thumbs-down retry. When a user marks an answer as unhelpful, the bot retries with that feedback in context instead of just logging it. It's a cheap way to recover a conversation in the moment — and the logged thumbs-downs show exactly where the knowledge base has gaps.

What I'd tell anyone building one

1. Chunking is the product. Most "the bot gave a wrong answer" bugs were retrieval bugs, and most retrieval bugs were chunking bugs.
2. Small model, good context beats big model, bad context — for latency and for cost.
3. Tools need confirmations, and user-data tools need strict scoping to the signed-in user.
4. Feedback buttons should do something in the moment, not just feed a dashboard.

If you're building something similar, I'm happy to compare notes — get in touch.

The Model Context Protocol (MCP) makes that possible: an MCP server exposes Coolify's operations as tools Claude can call. The catch was authentication.

The mismatch

• Coolify's API authenticates with a static bearer token. One long-lived secret, full API access.
• Claude's remote MCP connectors expect the server to speak OAuth — the user is sent through an authorization flow, and Claude receives tokens it can refresh.

Handing the Coolify token to every client wasn't an option: there's no consent, no per-session revocation, and a leaked token means full access to the infrastructure. So I built a shim in the middle.

The shim's job

A small Node/Express service that:

1. Speaks OAuth to Claude — the authorization and token endpoints Claude's connector expects.
2. Shows a consent step before issuing anything, so access is an explicit decision rather than a side effect of knowing a URL.
3. Proxies MCP requests to Coolify, attaching the static bearer token server-side only. The real token never leaves the shim.
4. Stores sessions in Supabase, so they survive redeploys.
5. Rate-limits requests per session.

Claude ──OAuth──▶  Shim (Node/Express)  ──Bearer token──▶  Coolify API
                     │
                     └── sessions & tokens in Supabase

Why Supabase for sessions

Keeping sessions in memory works right up until the shim itself is redeployed — which, on a tool whose whole purpose is deployments, happens a lot. Every redeploy would log everyone out and force them back through the OAuth flow.

Storing sessions and tokens in Supabase (Postgres) avoids that: the process is stateless, and a redeploy is invisible to connected clients. It also gives one place to look up and revoke a session.

// Simplified: look up a session by its access token
const { data: session } = await supabase
  .from('mcp_sessions')
  .select('id, expires_at, revoked')
  .eq('access_token_hash', hash(accessToken))
  .single();

if (!session || session.revoked || isExpired(session)) {
  return res.status(401).json({ error: 'invalid_token' });
}

Storing tokens hashed means a database read alone doesn't hand anyone a usable credential.

Guardrails

• Consent flow protection. The consent step is where a malicious link could try to trick someone into approving access, so it's protected against being completed by anything other than the user's own deliberate action.
• Rate limiting. An agent in a loop can fire a lot of requests. Per-session limits keep one runaway conversation from hammering the Coolify API.
• Least exposure. The Coolify token lives only in the shim's environment. Clients only ever hold shim-issued tokens that can be revoked individually.

The payoff: deployments by prompt

With the shim and a custom MCP server in place, deployments across our client projects became fully prompt-driven. Redeploys, status checks, and log reads happen from a conversation, and the manual click-through steps are gone.

Takeaways

1. When two systems disagree on auth, put a small, boring service between them rather than weakening either side.
2. Never forward a master token to clients. Issue your own revocable tokens and keep the real one server-side.
3. Persist sessions outside the process — especially for a service you'll redeploy often.
4. Rate-limit anything an agent can call.

Questions about MCP or Coolify setups? Get in touch.

None of these techniques is new. The value is in applying them in the right order and measuring as you go.

1. Measure first

Before changing anything, find out where the time actually goes. For each slow endpoint I looked at:

• total response time — at typical and peak load, not just the average;
• time spent in the database vs. in application code vs. waiting on third-party APIs;
• how many queries a single request triggers.

That last number is often the biggest surprise.

2. Fix the queries

Caching a slow query just hides it until the cache misses. So queries came first.

Read the query plan. EXPLAIN ANALYZE shows what the database is really doing:

EXPLAIN ANALYZE
SELECT id, status, created_at
FROM leads
WHERE campaign_id = $1
ORDER BY created_at DESC
LIMIT 50;

A sequential scan over a large table for a filter-and-sort like this is the classic sign of a missing index. A composite index matching the filter and sort order turns it into an index scan:

CREATE INDEX idx_leads_campaign_created
  ON leads (campaign_id, created_at DESC);

Kill N+1 queries. Loading a list, then querying related data once per row, scales linearly with the list. Fetching related rows in one query (a join, or a single WHERE id = ANY($1) lookup) collapses dozens of round trips into one.

Select only what you use. SELECT * on wide tables moves data nobody reads.

3. Cache what's read often and changes rarely

With queries in good shape, Redis took the remaining repeated work off the database. I used the cache-aside pattern:

async function getCampaign(id) {
  const key = `campaign:${id}`;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const campaign = await db.campaigns.findById(id);
  await redis.set(key, JSON.stringify(campaign), 'EX', 300);
  return campaign;
}

The rules that kept it correct:

• Cache by access pattern, not by table. Good candidates are read on almost every request and change rarely — configuration, campaign settings, reference data.
• Always set a TTL. Even with explicit invalidation, a TTL is the safety net against stale data living forever.
• Invalidate on write. When the source record changes, delete its key so the next read repopulates it.
• Don't cache per-user, fast-changing data unless you have a clear invalidation story.

4. Lazy-load the expensive parts

Some responses were slow because they did everything up front — computing or fetching data that most callers never used. Deferring that work helped on both sides:

• API side: return the core payload immediately; expose expensive, rarely-needed details through a separate endpoint or on request.
• Frontend side: load heavy components and below-the-fold data only when needed, so the page becomes usable sooner.

5. Make it stick

A one-off speed-up decays as features are added. To keep the gains:

• keep an eye on slow-query logs and endpoint latency after each release;
• treat a new N+1 or an unindexed filter as a bug in code review;
• keep the infrastructure efficient too — at TGG that included serving over HTTP/2 with proper SSL configuration on our AWS servers.

Summary

Together these brought response times down by about 40%. The order matters: measure, fix queries, then cache, then defer.

Working on a slow API? Let's talk.