Keenan Pereira · Problems & solutions

From 3.3 MB to 180 KB, the image diet behind a fast landing page

2026-10-27T06:20:00Z

Luxury sells on photography. A premium home-automation brand can’t use small, muddy images. But people arrive at an ads landing page on phones, often on patchy mobile data, and every extra second on a slow load loses some of them.

The question wasn’t “big images or fast page”. It was how to serve images that look big without weighing much.

Where the weight was

The source folder was what you’d expect from a design team: camera exports and renders of up to 16–17 MB each. After a first round of compression the page still pulled about 3.3 MB of images:

Image set	Before	After
Hero	1,772 KB	35 KB
Two experience-centre photos	429 KB	53 KB
Five project photos	393 KB	73 KB
Six product cut-outs (PNG)	701 KB	22 KB

Step 1: convert

convert-webp.js runs every source image through sharp and writes WebP at quality 82. At that setting I couldn’t see a difference on a phone, and the files are a fraction of the size. Product cut-outs that had been huge transparent PNGs gained the most.

Step 2: resize to the layout, not the camera

Most of the waste wasn’t compression; it was pixels nobody sees. A 4,000 px photo shown in a 600 px card makes the phone download and then throw away almost everything. resize-for-cdn.js crops and resizes each image to the exact size it displays at, so Lighthouse reports no wasted bytes.

Step 3: let the browser help

Every image goes through <picture> with WebP first and JPG or PNG as the fallback.
Every image has explicit width and height, so nothing jumps as it loads.
Everything below the fold is loading="lazy": 32 images in all.
The hero is preloaded with fetchpriority="high", and the CDN gets a preconnect.

What else came out of the critical path

An icon font was replaced with a handful of inline SVGs.
The web font loads asynchronously, and the theme CSS is inlined.
The tag manager waits for the first interaction, or a timeout, before loading.

Result

The images went from about 3.3 MB to about 0.18 MB, 94% lighter, with no visible loss on a phone. The page still looks like a luxury brand; it just doesn’t make visitors pay for it in mobile data.

Lead capture without handing the browser your CRM keys

2026-10-27T06:40:00Z

When you build a lead form for paid traffic, there are two jobs. The lead has to reach sales immediately, and nothing about how it gets there should be visible to the visitor. My first attempt at the AHA landing page did the first job and failed the second.

The tempting shortcut

Zoho CRM’s API uses OAuth. You hold a long-lived refresh token and swap it for an access token that lasts an hour. The quickest way to get a form posting into the CRM is to do that swap in the browser: call the token endpoint, then call the leads endpoint.

It works on the first try, which is exactly why it’s dangerous. To make those calls, the page needs the client ID, the client secret and the refresh token. Anyone who opens the source can copy them and do whatever that token is allowed to do in your CRM. I caught this in my own draft before the page went out, and treated it as a hard stop.

The fix: one small endpoint

The browser should only submit a form. The credentials stay on a server, so I wrote a tiny Express handler for the form to post to.

// Simplified. The real handler reads credentials from the server environment.
let cached = { token: null, expires: 0 };

async function accessToken() {
  if (cached.token && Date.now() < cached.expires) return cached.token;
  const res = await fetch(`${ZOHO_ACCOUNTS}/oauth/v2/token`, {
    method: 'POST',
    body: new URLSearchParams({
      grant_type: 'refresh_token',
      refresh_token: process.env.ZOHO_REFRESH_TOKEN,
      client_id: process.env.ZOHO_CLIENT_ID,
      client_secret: process.env.ZOHO_CLIENT_SECRET,
    }),
  });
  const { access_token } = await res.json();
  cached = { token: access_token, expires: Date.now() + 55 * 60 * 1000 };
  return access_token;
}

app.post('/submit-lead', async (req, res) => {
  const lead = toCrmLead(req.body);        // validate + map fields
  if (!lead) return res.status(422).json({ ok: false });
  const r = await fetch(`${ZOHO_API}/crm/v2/Leads`, {
    method: 'POST',
    headers: { Authorization: `Zoho-oauthtoken ${await accessToken()}` },
    body: JSON.stringify({ data: [lead] }),
  });
  res.status(r.ok ? 201 : 502).json({ ok: r.ok });
});

Three details mattered more than the code:

Cache the access token for 55 minutes, a little under its one-hour life. Refreshing it on every submission is slow, and the token endpoint will throttle you.
Validate on the server too. The browser checks fields so people get quick feedback, but the endpoint is the real gatekeeper.
Return honest status codes. The page shows a retry message if the CRM call fails, instead of a fake “thank you”. That mattered more than I knew at the time; see A thank-you page that lied.

Making the lead useful to sales

A lead the sales team has to clean up by hand is only half delivered. The form:

requires a 10-digit phone number and a 6-digit pincode, and opens the numeric keypad on phones;
splits the full name into first and last name, because the CRM requires a last name;
sets the lead source, status and city, so it lands in the right view;
captures property stage, property type and preferred experience centre, so a salesperson can qualify the lead before the first call.

Proving it converts

Ads optimise for whatever conversion signal you give them, so the page pushes four events into the data layer: contact click, WhatsApp click, submit click and lead generated. A successful submit then redirects to a thank-you page marked noindex. That gives Google and Meta a plain URL-based conversion that keeps working even when a tag fails.

What I took away

If the browser can see a secret, so can everyone. “Only on my test page” lasts until it doesn’t.
A 40-line proxy is cheap insurance. It also gives you one place to add rate limits, spam checks and logging later.
Design the lead for the person who receives it, not just for the database.

Writing about Apple without breaking Apple’s rules

2026-10-27T07:00:00Z

When Apple announced HomeView, the ask was clear: tell visitors AHA works with Apple, and make the site feel Apple-ish. Both are easy to get wrong. Apple’s trademark rules are specific, and every claim has to be literally true.

What we could actually say

Before a line was written, every claim was checked against AHA’s fact files:

Compatible with Apple Home: verified, and already on 13 pages.
Matter and Thread certified, AirPlay on the room speakers: verified.
“Works perfectly with Apple”: not usable. Apple’s guidelines forbid exaggerating the Apple message, and “perfectly” is a promise no product page should make; voice control, for one, needs the internet.

Siri, the Home app and an iPhone app sat behind five questions, and nothing about them was published until the answers were in the knowledge base. Three were answered on 16 October: every AHA product shows up in Apple Home and is set up there on every install, Siri can control them, and there’s an AHA app for iPhone. The other two, a public listing for AHA’s Matter certification and a licence for Apple’s Home icon, are still open, so the badge and the icon stay off the site.

Apple’s rules, written as house rules

From Apple’s third-party trademark guidelines and its Works with Apple Home page:

Referential phrases only: “works with”, “compatible with”.
Never possessive or plural in site copy, and never “the Apple Home”.
AHA leads. Apple may appear in a title or H1 only as “compatible with Apple Home”, after AHA’s name.
No Apple logo or icon without a written licence.
A trademark credit wherever the marks appear.
The official badge needs Matter certification and Apple’s licence, and never goes on company pages.

Encoded, not remembered

Rules in a document get forgotten, so we built them, with Claude Code, into the files the templates read:

trademarks.js holds one credit line naming only the Apple marks the site actually uses. The footer prints it on all 91 main-site pages, and the landing-page template adds it whenever a section names an Apple product, so an editor can’t drop it.
appleHome.js holds badge approvals, and it’s empty:

// Empty until Apple approves a product.
// The badge template renders nothing without an entry,
// and we never draw our own badge.
module.exports = { badges: {} };

A wording check looks for possessives, plurals, “the Apple Home”, “Apple partner” and “Apple-certified”. It came back clean on every Apple page we shipped.

Borrow the restraint, not the brand

The new look took Apple’s structure: the type scale, generous spacing, borderless tiles, chevron links. On iPhone, iPad and Mac the body font is the device’s own SF Pro, through the system font stack, so there’s no download and no swap. Android and Windows keep Inter. It’s the device’s font, not an embedded Apple one.

The first previews also took Apple’s greys, and the site looked dull. I asked for AHA gold everywhere. Contrast improved rather than suffered: small gold text measures 5.0:1 on its band and secondary text 5.6:1, where the old grey managed 4.3:1 and fell short of AA. Plain AHA gold is only 2.3:1 on white, so it’s kept for fills and rules, never text. A page joins the look with two front-matter lines, and rollback is deleting them.

The pages

On 16 October an Apple Home landing page went up, titled “AHA Home Automation Compatible With Apple Home”, with AHA first. Five articles sit around it, from HomeView in India to the core question, “Does AHA work with Apple Home?”. Google crawled all six on 15 and 16 October and had them indexed within days, with no indexing requests needed.

The HomeView copy followed the same rules: every line checked against the fact files before it went in. The Siri cards say “Lock”, never “Unlock”, because Siri asks for authentication to unlock. HomeView sections for the landing page and a HomeView card for the homepage are built and going live, alongside an AI-generated hero: a Mumbai living room at dusk with HomeView among AHA’s own labelled products, recomposed at 9:16 for phones, with no Apple logo.

Rules I’d pass on

Read the rules before writing the copy. Apple publishes them.
Put rules where templates read them. A credit line in a data file can’t be forgotten.
Gate claims on recorded answers, not on what sounds right.
Borrow restraint, not branding. Gold, not grey.
Leave the badge slot empty until Apple fills it.

Rules first, LLM second

2026-10-27T07:20:00Z

I built this engine as part of AHA’s hiring process, and it set the pattern I’ve used since. The problem sounds simple, “turn speech into device actions”, until you listen to how people actually talk to a house.

Three kinds of commands

Literal: “turn on the bedroom lights”. A regular expression handles it.
Indirect: “I’m feeling hot”, “it’s too dark”, “make it cooler”. These need meaning, not matching.
Compositional: “everything off except the bedroom”. This is set logic over rooms and devices.

Rules first

The rule engine runs on every command. It handles aliases and typos (“fna” → fan, “blinds” → curtains), and it understands capabilities: set_temperature means the AC. When it’s confident (0.9 or higher) it answers immediately and the LLM is never called. Most real commands end here, in milliseconds.

A semantic resolver sits on top for indirect language. Comfort complaints map to a device and an action. Comparatives like “cooler” and “brighter” become relative changes. “Everything except the bedroom” becomes the complement of a set of rooms.

LLM second, inside a fence

Only what the rules can’t parse goes to Llama 3.2, running locally on Ollama. The prompt lists exactly which devices, rooms and capabilities exist, with a few worked examples. The engine extracts the first JSON object from the reply and drops anything not on the allow-list. If confidence falls below 0.55, it doesn’t guess. It asks a targeted question, like “Which room’s light?”.

Guardrails the model can’t talk around

Safety is a separate layer that applies whoever produced the action:

“Turn off everything” never includes locks or alarms unless they’re named.
Unlocking and disarming need typed confirmation; voice and WhatsApp can’t do them at all.
Unknown devices are rejected. The unit test for this uses a “nuclear reactor”.

One brain, three ways in

The same parser, guardrail and device state serve a console, offline Whisper voice (woken by “Aha, listen”) and a WhatsApp bot. A live dashboard shows every decision: which layer answered, with what confidence, and what it did.

Takeaway

LLMs are best as the exception handler, not the main path. Put fast, testable rules in front, a strict schema around the model, and safety outside both.

Product pages led by specifications

2026-10-27T07:40:00Z

AHA’s Smart Locks page had a 2,037 px block of bullets and not one specification. The datasheet existed only inside the PDF.

What a full-page capture showed

We diagnosed before designing, and the problem wasn’t styling:

A “Why it matters” block 2,037 px tall: one dense paragraph and three bullet lists, 26 items in all.
The bullets repeated facts already given in the rows above and in the printed catalogue below. Three formats, one set of facts.
No specification anywhere on the page.
No link to a sibling product.

All ten product pages followed the pattern, with 4 to 32 bullets each.

A layout led by specifications

On 9 September all ten pages moved to one order: hero, a masthead with the headline facts and the download, story rows with alternating images, specification, what it runs with, why it matters, compatibility, the experience centre, contact. In plain terms: what it is, how it works, what it’s made of, what it works with, why that matters, come and see it.

Two shared templates read one data file, the same one the PDF catalogue renders from, so page and catalogue can’t drift apart:

The spec table replaced the hand-written feature bullets, with 4 to 20 rows per product in the same ruled layout as the printed sheet.
“What it runs with” added 37 internal links, 3 to 6 per page, each with a line on why that product matters to this one. The build throws on a product name with no page, so a dead card can’t ship.

Built with Claude Code, then checked at 390 and 1440 px on all ten: 0 px of sideways overflow.

Nothing deleted on trust

Every bullet was checked against the specification data before it was removed. That found one fact that lived only in the bullets (unlocking a bedroom lock can trigger a scene), and it went into the data first. It also found a claim the product documentation didn’t support, RGB support on the lighting drivers, which left with the bullets.

Where a spec isn’t confirmed, the sheet says so: the Aroma Diffuser’s sheet states that capacity, refill type, room coverage and power source aren’t published yet, rather than padding it with plausible numbers. Product prices stay off every sheet.

Catalogues: lighter, and behind the form

The StarLight catalogue was 5.4 MB. It’s now 1.5 MB, and most of the other catalogues shrank with it.

The cause was pixel count, not file size. Chrome decodes each image and re-encodes it into the PDF, so StarLight’s two source images, only 283 KB on the CDN, went in at 2.1 and 3.1 megapixels. Each image now has a print-sized copy, sized from what it actually renders at: about 1.6× its placed size gives 150 dpi on A4. The first attempt, a blanket 1,200 px, left the StarLight hero carrying nearly twice the pixels its layout could show.

On 10 September, at my request, the catalogues went behind the lead form. A download click remembers which catalogue was asked for, scrolls to the form and relabels the button “Get the catalogue”. One submission unlocks every catalogue in that browser, and the thank-you page lists all ten with the requested one first. Three new dataLayer events (gate, unlock, download) shipped for Tag Manager, unwired at launch. It’s a soft gate: the files stay public at their own addresses.

Every image on the CDN, enforced by the build

The same day I set a hard rule: every image comes from the image CDN, never from the repo. An audit of the built site found about 1,750 image references, 332 of them pointing at 18 local files, among them the favicon, the home-screen icon, the share image and print-sized catalogue copies.

They were moved to the CDN or repointed at CDN copies, and a guard now runs after every build and fails it on any image reference that isn’t a CDN URL. It was proven both ways: a normal build passes, and a self-test with a fake offender fails. Its first run caught the 404 page’s own favicon, which no template edit had reached. By 21 September the live site had zero off-CDN images.

One limit, found later: the guard checks the host, not whether the file exists.

Rules I’d keep

Capture the whole page before redesigning it. The fault was structure, not styling.
One data file for the page and the PDF, so they can’t disagree.
Delete nothing on trust. Check each bullet against the data first.
Size images by the pixels they render at, not by file size.
Make the build enforce the rule, and prove the guard can fail.

The hero image that waited in line

2026-10-27T08:00:00Z

Largest Contentful Paint (LCP) measures when the biggest thing on screen, usually the hero image, finishes appearing. On AHA’s /solutions and /experiences pages it was over five seconds on a throttled phone. The images were already compressed, so the problem wasn’t their size.

Diagnosis: a traffic jam, not a heavy truck

The network waterfall told the story. The hero started downloading at the same moment as 13 to 23 other images further down the page. All of them were marked to load eagerly, and the browser treated them as equally important. The hero didn’t lose because it was big. It lost because it was waiting its turn.

There was a second trap. A carousel built its slides by cloning existing image elements. The clone copied src before loading="lazy", so every cloned slide downloaded immediately, which quietly defeated lazy loading.

The fix

Tell the browser what matters. The hero gets fetchpriority="high" and a preload hint. Everything below it gets loading="lazy" and explicit width and height, so nothing shifts as it loads.
Fix the clone order. Set loading before src and swap the real image source in only when a slide scrolls into view. Image requests at load dropped from 22 to 2.
Fake the blur, don’t compute it. A CSS filter: blur() over a full-screen hero costs real time on a weak phone, so the hero now uses a pre-blurred image.
Resize to the layout. /contact-us went from a 495 KB hero to 75 KB, with a 1024 px version in srcset for phones.

The other bug: phones running year-old JavaScript

Some returning visitors saw blank sliders. Their phones were running JavaScript from months earlier. The server told browsers to cache scripts and stylesheets as immutable for a year, but the filenames never changed. When we shipped a fix, those phones had no reason to fetch it.

The fix is the standard one, applied properly: every CSS and JS file gets an MD5 hash of its contents in its filename, at build time, after minification. Change one byte and you get a new filename, so caching forever becomes safe instead of dangerous.

// eleventy.after: hash, rename, rewrite references
const hash = createHash('md5').update(code).digest('hex').slice(0, 10);
const hashed = file.replace(/\.(js|css)$/, `.${hash}.$1`);

Results

Lighthouse lab runs, slow 4G with a 4× CPU throttle, before and after:

Page	Before	After
`/solutions`	5.44 s	1.11 s
`/experiences`	5.15 s	1.18 s
`/contact-us`	2.95 s	1.48 s
`/` (home)	2.68 s	1.44 s

One more lesson

The lab numbers passed, but real-user data stayed slower than they suggested. The giveaway was that the first paint arrived almost as late as the main image, and the server took about 1.2 s to respond. Past a point, the bottleneck is the hosting, not the page. That fix is documented and waiting on infrastructure access.

What a fortnight of Google Business Profile posts taught us

2026-10-27T08:20:00Z

A Google Business Profile post earns its views in about two weeks and then stops dead. I know because we first wrote down the opposite, and a third reading proved it wrong.

Where it started

AHA has two experience centres in Mumbai, Santacruz West and Lower Parel, and each has its own Business Profile. Until mid-September, posting to them was ad hoc. On 9 September the plan still listed the profiles as unstarted.

A post bank, not a habit

From 15 September, posting ran from a bank instead of memory:

One description per article, rewritten for curiosity. Each opens on a specific, sometimes surprising claim from the article and holds back the answer. All sit well under Google’s 1,500-character limit.
One tagged link per post, used on both centres, with the publish date in utm_content. Clicks are attributable in GA4 instead of landing as unknown traffic.
Both centres, every time, using Google’s own “Copy post” dialog.
A fixed cadence: Monday and Thursday, with Friday added a week later. Mumbai and buying-intent articles go first, and no two posts in a row share a topic.
A photo of the post’s own topic, never a logo card, exported as JPG because Business Profile won’t accept the site’s AVIF images. The photos prepared on 28 September, for example, were two JPGs: one for the retrofit article and one for TV-unit wall planning.

?utm_source=gbp&utm_medium=post
 &utm_campaign=blog/&utm_content=

The bank fell behind once, with descriptions for 19 of 30 published articles, because writing one was a separate task nobody had queued. Writing it is now a standing step in the Claude Code skill that publishes articles, so it happens in the same session a post ships.

Google declined our Business Profile API application automatically, so the readings came from screenshots of the profiles.

The claim we got wrong

The first four posts went up on 16 September. Between the first reading (day 5) and the second (day 15), their combined views rose 93%. On 1 October the log called it a long tail, “GBP posts keep earning for weeks”, and the plan was to work through every older article on that basis.

The third reading, on 6 October, said otherwise:

Six of seven posts gained nothing in five days.
The first four went from +93% in ten days to 0% in the next five. Not slower growth: identical numbers. That’s a plateau, not a reporting lag.

The 93% was real. It was just the end of the fortnight, and we had read the last of a curve as a trend.

The exception that explains it

One post kept climbing: an article on October heat in Mumbai, posted in late September. It rose 38% in five days while everything else was flat. A Diwali post from the same week went out about seven weeks before the festival. Same effort, same format, and the October post had nearly four times the views. The only difference was whether the topic was live when it went out.

What changed

Cadence still matters, for a duller reason. Each post is a one-off that earns for about two weeks, so value grows with the number of posts, not with time.
Season is the biggest multiplier. Festive posts go out when the festival is close. The Diwali article is scheduled for a re-post on 2 November, and that’s the main event, not a tidy-up.
Re-posting a good evergreen article every couple of months is now a tactic worth testing, because the first post has provably stopped earning.
Size it honestly. Twelve posts in three weeks make a useful supporting channel, not a main line.

Still open

The profiles themselves aren’t at 100% yet. A phone number added to the Lower Parel profile on 22 September still wasn’t showing in Google’s public data a month later, and the Friday review-request habit is still on the open list. That matters more than any single post: on commercial searches, the Santacruz listing averages position 3, where the homepage averages 16.

Rules I took from it

Read a channel three times before calling a trend. Two points make a line; three show its shape.
Identical numbers mean a plateau, not a lag.
Post in season. Timing beat everything else we controlled.
Tag every link, or the visits belong to nobody.

The sitemap that quietly hid the whole blog

2026-10-27T08:40:00Z

A sitemap is the list of pages you hand to Google. Most of the time nobody looks at it, which is how it can be wrong for months.

How it went wrong

The site I took over had a sitemap written by hand. It had 31 entries, used the bare domain instead of www, still listed old URL patterns, had one entry missing .com entirely and listed one page twice. Every time someone added a page, someone else had to remember to add it to the sitemap. Usually nobody did.

The worst failure was quieter. The site is built with Eleventy, and the sitemap logic skipped any page it believed was marked noindex. A code comment in the blog’s template was misread as that flag, so every blog post silently dropped out of the sitemap. Nothing errored, nothing turned red, and Google simply got a shorter list.

Later, the same kind of drift hit pagination: page 2 onwards of the blog listing was skipped.

The fix: derive it, don’t maintain it

The sitemap is now generated from two sources of truth that already have to be right for the site to work:

The built pages. Every page that isn’t explicitly excluded (redirect stubs, thank-you pages, ads-only landing pages) is included.
The blog taxonomy data. It feeds categories, topic hubs and paginated archives, so a new topic hub appears in the sitemap the moment it exists.

Three rules keep it honest:

Exclusion is explicit. A page leaves the sitemap only through a real front-matter flag, never through text that happens to appear in a template.
The canonical host is enforced. Every URL is built from one base address, so www and the trailing slashes always match.
Every deploy checks what it shipped. A live check requests every URL in the new sitemap and fails loudly on anything that isn’t a 200.

The same idea now generates llms.txt, the plain-text index some AI tools read. It went from listing 66 URLs to all 107.

Results

The sitemap grew from 38 URLs to 108 as the content programme shipped, with no manual edits.
By late October, 106 of the 107 submitted pages were indexed.
The blog, which was invisible in the sitemap for a while, now brings in more than half of all non-brand clicks.

Takeaway

If a file can be derived from data you already maintain, derive it. A hand-kept sitemap isn’t wrong on the day it’s written; it goes wrong slowly, and silently.

Don’t let the LLM do the maths

2026-10-27T09:00:00Z

The first version of my CRM insights agent did what most tutorials suggest. It fetched the data, put it in the prompt and asked the model for a summary of the day.

The output read beautifully, and it was wrong. In one test run, the model dropped a digit from a rupee figure and described a lead status as a marketing channel. Nobody would have noticed until a manager quoted the number in a meeting.

Why this keeps happening

Language models predict text. Adding up 400 rows, or noticing that a field means something subtle, is arithmetic and schema knowledge: precise work that fails unpredictably. Prompting harder doesn’t fix a tool that’s the wrong shape for the job.

Split the work

Postgres does the maths. I deleted about 255 lines of Python analytics and replaced them with 327 lines of SQL functions: funnel counts, conversion rates, pipeline by stage, and anomaly checks. Anomalies are fixed rules, not vibes. Examples:

a salesperson holding a pile of active leads with almost no pipeline is flagged as overloaded;
a lead source where at least 30% of leads are junk is flagged as toxic.

The model only narrates. It receives one compact JSON payload of already-computed figures and writes two sections from one prompt: a dashboard report and a WhatsApp summary. The summary is capped at 1,500 characters and cut at a line break, because WhatsApp’s limit is 1,600.

Then I took even that away for the numbers people forward. The WhatsApp message became a fixed template filled with the computed values. The model still writes the commentary, but it never retypes a figure.

The same idea at a bigger scale

The growth-intelligence platform has a chat where managers ask questions. Most questions are numbers: “demos last week?”, “leads from Meta this month?”. Those go to a deterministic router, about 14 SQL “skills” that run read-only queries on allow-listed views with an 8-second timeout and a row cap. They answer in under a second, for nothing, and they’re correct by construction.

Only “why” questions (why did demos drop?) reach Claude, along with the relevant computed numbers. The model does what it’s good at: connecting facts and explaining them.

Rules I now build every data agent with

If it can be computed, compute it. Never ask a model for a sum.
Give the model a payload, not the database. Small, typed and precomputed.
Templates for anything people will forward. Numbers in fixed slots; prose around them.
Route first. Most “AI” questions are SQL questions in disguise.

Building for a 2 GB TV and a remote with no pointer

2026-10-27T09:20:00Z

The deals map started as a desktop tool: every Mumbai building where AHA has automated homes, with plans, architects and what’s nearby. Then someone asked the obvious question. Could it run on the big screen in the experience centre, so a consultant can say “we’ve done twelve homes in your building” and show them?

The big screen is a TV, and TVs are hostile places for web apps.

Constraint 1: a remote has no pointer

A D-pad gives you up, down, left, right and OK. Picking one marker out of 500 by stepping through them is miserable.

Zone jump (the old TV mode). The map split into a 3×3 grid, and each press narrowed it to one ninth. About 500 buildings came down to a handful in two or three presses instead of dozens.
A magnetic, accelerating cursor. Holding a direction speeds up, and the cursor snaps to the nearest marker when it gets close.
Holding OK, four ways. TV browsers report a held OK key in four different ways, so one small function recognises all four as “hold”.

Constraint 2: the edges don’t exist

TVs crop 2–5% of the picture at the edges (overscan), so a button in the corner may simply not be on screen. The old TV mode had an overscan calibration step, and laid itself out inside the safe area it measured.

Constraint 3: BACK leaves the app

On the TV browser, BACK left our app and opened an old cached copy of the page. Now each BACK press is absorbed by one step of in-app history (up to 40), and a service worker forces fresh loads so a stale copy can’t come back.

Constraint 4: 2 GB and a weak GPU

LITE mode. The map draws at the screen’s native size instead of a high-DPI multiple. Browser memory fell from about 1,000 MB to about 650 MB.
Compositor-only animation. Everything animates with transform and opacity only, so the GPU composites layers instead of repainting. Measured: the curtains scene went from 20 to 57 fps, the smart-lock face scan from 25 to 60, and the moments reel from 30 to 60.
Heavy things are pre-baked. Floor plans are pre-rendered from PDF to 1,800 px WebP (200–350 KB each) in headless Chrome, so the TV never parses a PDF. Vertical product films were re-encoded from 23–35 MB down to 1.5–2.8 MB.

Constraint 5: two audiences, one screen

Visitors must never see money, deal status or salesperson names. Showroom view hides every amount and deal status on screen. Team view, for staff, adds the CRM calendar and billboard planning, and switches itself off after 10 idle minutes or when the screen sleeps.

The pitch, edited

Even a working app can be the wrong length. The first guided walkthrough took 15 minutes. “Present” is now seven chapters that play themselves, about 5½ minutes when a presenter clicks through.

Takeaway

Design for the worst device first. Nearly every TV constraint, from fewer pixels and less memory to clearer navigation and shorter stories, made the laptop version better too.

Where did this lead come from?

2026-10-27T09:40:00Z

A lead without a source is a phone number and a guess. In October I found that AHA’s two Zoho fields for the page a lead came from were blank on every website lead. No lead could be traced to a page.

It wasn’t the only gap I found that autumn:

Ad tags didn’t survive a second visit. UTM tags and Google’s click ID lived in session storage, so an ad visitor who came back in a new tab arrived as a stranger. Almost every lead credited to the website had no tags and no click ID.
The click ID went to the wrong field. Forms wrote it to a custom field. Zoho’s standard GCLID field, the one its Google Ads integration and offline conversion uploads read, was empty on every lead.
Zoho had a “Preferred Time For Callback” field. No form sent it.
Phone taps weren’t counted. The GA4 key event for calls had recorded nothing for 28 days, and the event that did fire wasn’t a key event.

Every lead records its page

Every visit now stores its first page. All seven forms add two fields to the end of the lead: the page the form was sent from, without the query string, and the first page of the visit. Both are cut to Zoho’s 255-character limit.

One field was left out on purpose. Zoho also has a URL-type field, but a bare path fails its URL validation, and that could make Zoho refuse the whole lead.

I had Claude Code test nine form placements against five kinds of visit: direct, tagged, an organic landing on a blog post, a tagged landing on another page, and a visit that began before the change. 45 of 45 sent one lead with both fields right. Against the previous build, every payload was identical apart from the two new fields. It went live on 24 October.

Tags that survive a second visit

The tag fix is built and tested, and going live now, so there are no results to report yet. The rule it implements:

// Which source a lead carries (simplified)
source = tagsFromThisVisit          // first tagged page of the visit wins
      ?? savedTags({ maxAgeDays: 90 }) // restored on an untagged return
      ?? fromReferrer();               // e.g. "google / organic"

One capture script, inlined everywhere, replaces six hand-kept copies.
A newer tagged visit replaces saved tags. A tag saved 100 days ago is dropped.
Every form sends the click ID to Zoho’s standard field as well as the custom one.
Untagged visits get a source from the referrer: a search engine becomes organic, no referrer becomes direct, and social networks and other sites, AI assistants included, are recorded by name. Lead Source itself doesn’t change.

The tag tests passed 34 of 34 in each of Chrome, Firefox and Safari’s engine, and the referrer cases 36 of 36. One known limit: Safari on iPhone can clear saved tags after seven days without a visit.

The new Ads landing page, /top-home-automation-companies, sends the same page, tag and callback fields, and is going live the same way.

Ask when to call

The callback field became an optional dropdown on all seven forms, with four slots that match the experience centres’ hours: 11am to 1pm, 1pm to 4pm, 4pm to 7pm, or any time. Optional, because every required field costs leads.

After it shipped, a test lead read back from Zoho with “4pm to 7pm”. The sales team’s WhatsApp alert now shows the slot too, and the first real enquiry to use it asked for 11am to 1pm. Testing this also exposed two Ads forms that couldn’t submit at all, which is its own story.

Count the taps

Calls and WhatsApp chats are enquiries too. One listener now catches every call and WhatsApp link and pushes a contact_click event with the method, where on the page it sat (floating button, footer, form) and the page path. GA4’s key events are now generate_lead and contact_click, and the old tap events were unstarred, because each tap fired both and would have counted twice. Counts before and after 22 September aren’t comparable, and I logged it that way.

Rules

A tracking field must never be able to lose the lead.
Record the first page of the visit, not just the last.
Write the click ID where the integration reads it.
Optional beats required. Ask what helps the call, not the report.
When you change what’s counted, date it.

A phone as the TV remote, with voice search

2026-10-27T10:00:00Z

In July 2026 the deals map got a full-screen TV mode, and with it a question the desktop version never had to answer: with the map on a TV across the room, how do you find one building by name? My answer was a phone. I built it with Claude Code.

Kiosk mode

One button switches the map to kiosk mode. The sidebar goes, open menus close and the map resizes to fill the screen. Adding ?tv=1 to the address opens the page straight into it, so it can be AirPlayed or opened in a TV browser with nothing to click.

One channel, two screens

The remote is a small web page opened on a phone. It and the map join the same Supabase Realtime channel and use two of its features:

Broadcast carries commands from the phone to the TV, and results back.
Presence tells each side who’s there. The phone reads “Waiting for TV…” until a map joins as the TV, then “TV connected”. The TV shows a toast when a phone pairs.

The phone is deliberately thin. It doesn’t search anything itself: it sends what it heard, and the TV runs the same matcher as its own mic button. Below the mic, a D-pad pans and zooms the map, resets it to Mumbai, closes the building card and toggles TV mode.

// phone → TV
{ action: 'search', q: 'what it heard', alts: [/* up to 4 guesses */], id }
// TV → phone
{ ok, label, q, suggestions, id }

The id earned its place. On a broadcast channel every map page answers, and an old map tab left open from a test stays connected and replies to every command too. Its late answer could overwrite the real one. So the phone ignores any reply that isn’t for its latest search.

Hearing names in Indian English

Voice uses the browser’s own speech recognition, set to Indian English (en-IN). The phone shows the words as they’re heard and asks the recogniser for up to 4 guesses at what was said. All of them go to the TV, every building is scored against each guess, and the best score wins.

Building names still get mis-heard, and an exact lookup fails on one wrong syllable. So the matcher works in tiers:

Close text matches. An exact match scores 100, one name starting with the other 88, one containing the other 68. Words in common score 22 each, up to 55.
A fuzzy fallback. Edit distance counts the single-letter changes that turn one string into the other. About 77% similar is enough to fly the map to the building; a weaker match can only be suggested.
Common words count for less. Building names often start with the developer’s name, and that word alone can’t say which one you meant. The matcher counts how many buildings each word appears in, and a fuzzy match on a word shared by 3 or more is capped below the jump line. It can suggest; it can’t decide.

Sure, or not sure

If the best score clears the line (28 out of 100), the TV zooms in, centres the building and opens its card, and the phone says “Found”. If not, the TV says there’s no project by that name, and the phone shows up to 3 “Did you mean” chips: the closest names the map actually has. Tapping one runs that search, so a near miss costs a tap, not a second try at the name.

Where it went next

The phone remote was the deals map’s first answer to the TV; it later grew into the showroom TV app, driven by the TV’s own remote, which brought problems of its own: building for a 2 GB TV and a remote with no pointer.

What I’d keep

Use the device in people’s pockets. A phone already has a microphone and a touchscreen.
Keep the remote thin. One matcher on the TV serves the phone and the TV’s own mic.
Ask for several guesses. Score every alternative the recogniser offers, not just its favourite.
Use two thresholds. Jump when sure, suggest when not.
Tag every request. On a broadcast channel, anyone can answer.

Measuring whether AI assistants recommend you

2026-10-27T10:20:00Z

When a buyer asks ChatGPT for the best home automation company in Mumbai, does it name AHA? When I took over AHA’s website in August, nothing was measuring that, and no dashboard could.

Why you can’t just look it up

Search Console’s API has no AI Overview breakdown. Bing has an AI Performance report in preview, but it covers only Microsoft’s own answers, and I found no API for it. For ChatGPT and Perplexity, the only way to know is to ask them.

What Bing did show, in September, was sobering: only 4 of AHA’s 70 pages had any AI citation at all.

The panel

So I set up a measure with Claude Code: a fixed panel of 12 buyer prompts, from wired versus wireless, to the best company in Mumbai, to adding automation to a finished flat without breaking walls. Each runs on 2 engines, ChatGPT and Perplexity, logged out, in a fresh chat every time. That’s 24 answers a run.

for each of the 12 fixed prompts:
  for each engine in [ChatGPT, Perplexity]:     # logged out, fresh chat
    log: AHA named? · source cited · claim made about AHA · notes
score = answers naming AHA, out of 24

The wording never changes. Edit one prompt and the trend means nothing. “Named” and “cited” are logged separately, because an engine can use your page as a source without saying your name.

The baseline

The first run, on 21 September, named AHA in 5 of 24 answers. Some were strong: Perplexity named AHA first for the best company in Mumbai and cited AHA’s own site. But none of the six explanatory prompts named AHA, and three more answers used AHA’s pages as a source without naming it. The single most-cited source was a directory site, in 5 answers.

The retrofit prompt, adding automation to a finished flat without breaking walls, is AHA’s core work. Neither engine named AHA.

What I changed

Let AI crawlers in. robots.txt explicitly allows the AI crawlers from OpenAI, Anthropic and Perplexity. In October, all 11 AI crawler user agents tested got a 200 from the live site.
Bing, properly. Webmaster Tools and the IndexNow key went live on 5 September, but nothing was submitted until 15 September. Then one push sent all 70 live URLs. IndexNow speeds discovery, not ranking, and Google doesn’t use it. The payoff is Bing, which ChatGPT search and Copilot draw on.
A complete llms.txt, the plain-text index some AI tools read. It now comes from the same data as the sitemap, so it lists 107 of 107 URLs, up from 66, under a short block of verified facts, including what AHA does and doesn’t do.
One Organization. Twelve hand-copied Organization blocks, and 14 blog publishers using an old brand name, became one node with one @id across the site, with a description, address and service area.
Content in the HTML. Three homepage sliders were empty until JavaScript built them, so a crawler that doesn’t run JavaScript saw no cards. Their cards are now in the HTML.

A month later

The second run, on 22 October, named AHA in 7 of 24 answers, and named or cited it in 10, up from 8. Perplexity added the Bandra and architects prompts. Bing’s index of the site grew from 84 to 112 pages.

It moves both ways. On the architects prompt, ChatGPT dropped AHA from first to eighth of eight. One answer said AHA installs hardware, which it doesn’t; another quoted an old page title with an out-of-date company age. AI answers lag the site by weeks.

The retrofit prompt still names AHA on neither engine, so the work isn’t finished. The same review found “retrofit” in no title, H1 or H2 on the site. The llms.txt, Organization and slider changes were built after this run, so the next run is the first that can show their effect.

What I’d tell anyone starting

Measure before you optimise, with prompts you never edit.
Count “named” and “cited” separately. Being a source isn’t being recommended.
Make the facts easy to lift: crawlable HTML, one entity, a complete llms.txt.
Expect lag, and don’t over-read one run of 24 answers.

A phone page that tells consultants who to call next

2026-10-27T10:40:00Z

A screen of totals tells a sales consultant how the month is going. It doesn’t tell them who to ring this morning. AHA’s consultant page was built for that: a single page on a phone, in plain words, with a short list of who to call first.

Start from a whiteboard, not a schema

The current page began as a whiteboard sketch, and the build copied it top to bottom. Two rules shaped it: phone first (every tab checked at 320, 375 and 430 px wide) and read-only. The page never writes to Zoho. Wrong deals get fixed in Zoho, and the page catches up on the next refresh.

A consultant’s login opens their own page; the admin can switch between consultants or see the whole team. I directed the work, and Claude Code wrote much of the code.

What’s on the page

The target bar. Closed, likely to close and still missing for the month, with a line marking the days gone. Under it, a best case (closed plus likely) and a worst case (closed only).
Closing date passed. Open deals whose closing date is behind them, in red, with one instruction: move the date in Zoho or close the deal. Left alone, such a deal drops out of every projection.
Closing probability. Open deals by the consultant’s own call: this month, the next two or three months, or no timing yet.
Your week. Demos, proposals and wins since Monday, against the same days last week.
Ask for a referral. Clients whose deal closed two to four months ago.
Architects and designers. Partners named on the consultant’s deals, with the quiet ones (a past win, nothing in 90 days) marked as worth a call.

Call these first

It’s a ranked list:

always first:  deals waiting for the advance
then, after 7 days with nothing logged
(no note, call, stage change or demo):
  called for this week or this month
  a fresh demo still waiting for a proposal
  a proposal or a negotiation
  rated 4 or 5
order:  by step, then the bigger deal
card:   top five, the rest one tap away

Each row has a tag saying what to do, such as “Collect the advance” or “Call once more”, and one line on why it’s there. No call buttons, no phone numbers: an earlier Today screen with call and WhatsApp buttons was retired because the BI is a report, not a CRM.

Why 7 days? For every deal open on 1 June, 1 July and 1 August 2026, we compared how often it was won within two months against how long it had gone with nothing logged. The odds dropped sharply after a week of silence and kept falling. It’s a correlation, not proof that calling saves deals, but a sensible line.

The scoreboard and the review

The second tab, Closed, is the scoreboard: won against lost for the period and the one before, split by rating, source, value, the consultant’s call and time. At its foot, a review of lost deals shows every Zoho note on the deal and its lead, and flags the ones worth a second look, such as a note written after the loss (the client may be back). Since 15 Oct, each consultant’s login shows the review for their own deals.

What got cut

More screens were built than kept: Growth Brief mock-ups, an Explore drill-down, follow-up queues that became the Today screen, an ad-spend screen, a funnel, an Ask chat, and a 3D map tab, rolled back. Each went when it didn’t earn its place; Funnel, Ads and Ask went in one decision, so the effort could go into one page.

Checking what the phone shows

A preview mode loads made-up deals under a red “made-up numbers” ribbon, as a consultant or as the admin, so layouts get tested without real data.

On 16 Oct, Claude Code read about 140 figures off the rendered page, for the whole team and one consultant over two months, and recomputed each with separate SQL. Every figure matched. The check still caught two small things: a tile and the review below it counting different groups under one label, and a split that silently dropped a deal with no lead date. Both were fixed. The rules behind the numbers are in One meaning per number.

What I’d keep

Draw the page before querying anything.
End in an action. A ranked list with reasons beats another chart.
Stay read-only. The CRM stays the one place to fix a deal.
Cut screens that don’t earn their place, even finished ones.
Check the rendered page, not just the query.

From sleep loop to portable screensaver

2026-10-27T11:00:00Z

A showroom TV has to earn its place when nobody is touching it. Ours goes to sleep after 20 seconds without a button press, and sleep is a loop with one job. The first line of its notes says it plainly: “It sells the life, not the map.”

What the loop plays

One pass is 22 slides, about 4½ minutes: the AHA logo, all eleven AHA moments in the order of a day, five products (the next five on the next pass), two client testimonials, four buildings with AHA homes, both experience centres with live opening hours, and a QR code to the experiences page.

It opens on the moment that fits the hour. At 6 pm that’s Grand Welcome, arriving home; at 10 am it’s Goodbye Routine, leaving. On a laptop the loop waits until nothing is open, so a page someone is reading is never swept away. The TV sleeps from anywhere: its viewers have walked off.

Smooth on a 2 GB TV

Slide changes used to stutter on the TV, waiting on the network or the image decoder. Now the next slide’s photo is fetched and decoded while the current one shows. The new photo dissolves in over the old one, which is removed only once covered. A few decoded images stay in hand (the one on screen, the next, and the one a ◀ press would bring back), and older ones are let go so the TV doesn’t run out of memory. The progress line is scaled rather than resized, so the graphics chip has little to redo.

Building photos, sorted by eye

Most buildings use their public map photo, which is whatever a visitor uploaded. All 229 were sorted by eye. 65 were construction sites, hoardings, street scenes or not the building at all (a shop, a temple, a chai van), and are never shown. 76 were good enough for the loop. Each verdict is tied to that exact photo, so a photo swapped later is judged afresh instead of inheriting the old verdict.

The same loop, somewhere else

In October the loop was wanted for the AHA camera app, as a screensaver in its web view. Rather than keep a second copy that could drift, a script builds the standalone page from the TV’s own code, copying the loop’s functions, photos, words and styles verbatim, so it plays exactly as the TV does.

It leaves out the login, the map and the CRM data, so the buildings slide goes: 21 slides, about 4 minutes. A tap wakes nothing, because there’s no app underneath; it tells the app showing the page, which usually closes it.

The script is strict. Every function and style rule it copies must be found exactly once, and so must every edit it makes:

// each [old, new] edit must match exactly once, or the build stops
pairs.forEach(([a, b]) => {
  const n = text.split(a).length - 1;
  if (n !== 1) fail(label + ': expected to find once, found ' + n);
  text = text.replace(a, () => b);
});

If the TV’s code changes shape, the build stops and says where, instead of shipping a screensaver that quietly differs.

What the handover taught

The first handover was three files, and the page opened alone as a blank white screen. Now aha-screensaver.html holds everything in one file, so it plays however it’s opened: from a chat, a download, an app’s own files, or handed to a web view as text.

Older web views needed two more guards. CSS inset is unknown before Chrome 87, and without it the whole page would collapse to nothing, so the script writes it out as top, right, bottom and left. And if the page can’t start, with JavaScript off (an Android web view’s default) or files missing, it says so on screen after two seconds instead of staying blank.

What I took from it

Idle time is airtime. A screen nobody is touching should still be selling.
Decode before you show. A change should never wait on the network or the decoder.
Generate the copy, don’t fork it. And make the generator fail loudly when its source moves.
Hand over one file. Assume it will be opened in the least helpful way.

I directed the work and Claude Code wrote much of the code. There is still only one loop: the screensaver is rebuilt from it, and the build stops rather than copy something that has changed shape.

The slow part was the server, not the page

2026-10-27T11:20:00Z

PageSpeed Insights said three of AHA’s pages failed Core Web Vitals on phones. My own throttled lab runs of the same pages passed comfortably. Both were right, and the gap between them was the most useful number I found.

Do the arithmetic before you optimise

PageSpeed shows real-user (field) data beside its lab test. On all three pages it told one story: first paint at 2.4 s, largest paint at 2.5 s. About 96% of the time to Largest Contentful Paint (LCP) passed before anything was drawn at all.

That rules out the usual suspects. Image weight, render-blocking CSS and image priority only matter once bytes arrive. Field Time to First Byte (TTFB) said the same: about 1.2 s waiting for the server. My lab runs, on Slow 4G with a 4× CPU throttle, measured TTFB at 36 to 108 ms. Real users were losing about a second before the race started.

Interaction delay agreed. Real-user INP was 247 to 270 ms, yet under the same throttle the page’s tap handlers took 14 ms. A page still arriving when people start tapping explains the difference.

The pages were already lean: one script, 145 to 171 KB, the main image preloaded. Hosting was outside the project’s scope. I recorded the finding as a measurement, not a proposal, so nobody commissions more page work against a problem it can’t move.

The lab sweep did find slow pages, just not these. Their causes were in the page, and fixing them took /solutions from 5,440 to 1,108 ms. That’s its own story.

The hero image that never existed

On 9 October I went through the site on my iPhone, and the homepage video seemed to load late.

The August audit had flagged that the 5.25 MB hero video had no poster frame. By October the template referenced one, and even preloaded it at high priority, but the file had never been uploaded. It returned 403. On this hosting a missing file answers 403, not 404, so it reads like a permissions error.

Two details made it worse. The lab test still passed: with no poster, it measured the headline as the LCP element, so a broken hero scored as fast. And Low Power Mode on iPhone, like data-saver modes, blocks autoplay. For those visitors the poster is the hero, permanently, and it was a blank box.

Our first guess, that the video took 20 seconds or more on mobile data, was wrong. On a throttled phone it was playing at 3.0 s, because the CDN streams it progressively.

The fix was small: point the poster and its preload at a photo that exists, verified 200. The real gap was in tooling: the build’s image guard checked each image’s hostname, never whether the file existed.

Then test every page, everywhere

Phones are AHA’s bigger audience, so I asked for every page to work on iPhone, Android and every major browser. With Claude Code I built a Playwright sweep of all 110 pages in 9 browser setups: Chrome, Edge, Firefox and Safari’s engine, on phones, a tablet and desktops. A page is clean only with no JavaScript errors, no failed requests, no sideways scroll, nothing stuck invisible, no broken images or empty sliders, one H1, and no form field under 16 px, which makes iPhone Safari zoom in.

Every setup came back 110 of 110. The pass also fixed slider drag in Firefox, where the cards are links and Firefox started its own link drag, and added CSS prefixes Safari needs.

A phone pass added interaction checks. At 320 px wide, 26 of 31 passed; after the fixes, 31 of 31 on all five phones. One fix was for a real bug: on short phones the floating call and WhatsApp buttons sat under the open menu, so a tap meant to close it could start a call.

Results (lab)

Homepage Lighthouse, median of 13 runs: Performance 0.85 to 0.89, Accessibility 0.96 to 1.00, failing tap targets 37 to 0.
Smaller copies of seven oversized photos, served through srcset, are 73% lighter.
Width and height on 626 of 626 images, up from 226. Lighthouse across all 74 live pages in September: median score 83, CLS 0.000.

There’s no real-user Core Web Vitals data from after these fixes yet, so these are lab figures.

Rules I kept

If first paint and largest paint are close, look at the server. No image fix will move it.
A passing metric can hide a broken page. Check what was measured.
Check that files exist, not just where they point.
Test every page on every device. Samples miss the page that breaks.

A nightly sync that survives its own failures

2026-10-27T11:40:00Z

Every screen in the growth-intelligence platform reads from one Postgres database, fed by a daily sync that talks to Zoho CRM, Google Ads, Meta Ads, Google’s geocoder and Claude. On any given day, one of them can fail. The real question was what the other steps should do when that happens.

Claude Code wrote most of the scripts. My job was deciding how each one is allowed to fail.

One script, 25 steps

The orchestrator runs 25 steps in order: leads and deals through Zoho’s Bulk Read API, demos and lead notes, call recordings and electrical-plan PDFs, Google and Meta ads, AI summaries and call analysis, geocoding, enrichment, and a quality check at the end. From 27 April a GitHub Action scheduled it for 08:00 IST every day, and it also shipped as a nightly cron job.

If all 25 had to succeed, one flaky API would hold back the rest. So every step is one of two kinds.

Two kinds of failure

Core (9 steps): the leads, deals and demos pulls, recordings and plan PDFs, the OCR that reads those PDFs, geocoding and the buildings rebuild. Everything downstream reads from them, so if one fails, the run stops and writes “failed” and the step’s name to a status row.
Optional (16 steps): ads, AI summaries, call analysis, enrichment and the quality check, among others. These are marked non-fatal: a failure logs a warning and the run moves on. An expired ads token is no reason to hold back the CRM data.

for (const step of steps) {
  try { run(step) }
  catch (err) {
    if (step.nonFatal) { warn(step); continue }  // log it, keep going
    writeStatus('failed', step.name); exit(1)     // stop, and say where
  }
}
writeStatus('success')

Every main page shows a freshness badge read from that status row: green under 12 hours, amber up to 36, red after that or when the last run failed. Hovering over it shows where a failed run stopped.

Failing small inside a step

Attachments. The recording and plan-PDF syncs re-check every attachment on every run instead of keeping a cursor. It costs more, but it heals itself: a file missed yesterday lands today. Each file is handled on its own, so one bad attachment can’t halt the scan, and a retry overwrites instead of leaving an orphan.
Meta Ads. Meta rejects large day-by-day requests, so the puller asks in 30-day chunks. A failed chunk is logged and skipped, and the rest still lands.
Pinned windows. A normal run re-pulls only the last 7 days of Google Ads and 28 days of Meta, because Meta keeps attributing late conversions to past days. The windows are pinned in the orchestrator, so a backfill setting left in a config file can’t turn a daily run into a full-history re-pull.

A check that grades every run

The last step runs 28 checks: totals that shouldn’t collapse; records missing IDs, statuses, sources or coordinates; drops in leads, deals or demos since the previous run; and stored files reconciled against table rows, so a recording without a row, or a row pointing at nothing, shows up straight away. It grades the run; it doesn’t block it.

The log keeps the last 30 runs. Across those, from 12 August to 9 October, 93% of checks passed. The only flags were the same two every time: leads with no status, and demos with no lead source. Both are CRM data-entry gaps rather than sync failures, so the check keeps them visible until someone fills them in.

What clean pulls exposed

Getting the ads pullers right exposed an older problem. The ROAS page had been reading spend from an abandoned table, and its spend was badly inflated. Once the Meta puller could backfill history in chunks, I checked that it covered every ad the old table had, then pointed the spend views at it. It was a database-only change, and those totals now refresh with every run.

Rules I’d keep

Decide per step what failure means. Stop for data everything else depends on; warn for the rest.
Fail small. One bad file, chunk or token should cost one item, not the run.
Pin windows in code, not in a config file someone forgot to reset.
Grade every run and keep the history. A flag that appears every time is a process problem, not a bug.
Show freshness on every page, so nobody has to ask whether the data is current.

A sync is only as good as its schedule. By October the daily run had stopped and one puller was swallowing its own errors, which is why the AI growth agent later got a live warehouse of its own, refreshed every 15 minutes.

Giving a TV remote a mouse pointer

2026-10-27T12:00:00Z

The showroom app’s Map tab puts every building on one map you move around freely: no rail, no lists, from the whole city down to street level. On a laptop that means a mouse and a scroll wheel. On the showroom TV it means a remote with four arrows and OK, and an air mouse that wobbles. (The TV’s other constraints are in Building for a 2 GB TV.) Claude Code wrote most of the code; my job was deciding how it should feel.

Move the pointer, not the map

The arrows move a pointer over the map, the way a mouse would, and the map stays still. Push the pointer against the edge of the screen and the map scrolls, so it can still travel the whole city. That gives the remote what a mouse has: a place you are pointing at.

Four arrows that feel like a hand

A tap nudges it. Holding an arrow starts it gently, then speeds it up.
Two arrows held together go diagonally.
Turns curve. Some remotes only press one arrow at a time. Switching from one arrow to another curves round instead of turning a sharp corner, so even those remotes can go diagonally.

The curve falls out of smoothing each axis on its own. Speed follows a held arrow quickly, lets go of a released one slowly while another is still held, and stops briskly once nothing is:

// every frame, for x and y separately
const target = held(axis) ? dir * speed(timeHeld) : 0;   // gentle start, then faster
const lag = held(axis) ? QUICK : anyArrowHeld() ? SLOW : BRISK;
v[axis] += (target - v[axis]) * (1 - Math.exp(-dt / lag));

And at the end of a move, let go right beside a building and the pointer settles onto it. Nobody has to land exactly on a dot.

Finding a building without aiming

The building at the pointer turns gold, and a card shows its photo, area, homes and plans. The card sits in a corner and moves across when the pointer heads into it.
Buildings are named as you come close: the ones with AHA homes first, then every building, never overlapping and never under the card or the key hints.
On a near tie, an AHA home wins. It’s what visitors come to see.
OK always does something. It opens the building once it stands clear or the map is close in. Before that, it goes one level closer around the pointer.
BACK retraces. It steps out one level at a time to the whole city, then closes the map. Open a building and come back, and you’re at exactly the same spot and zoom.

The air mouse wobbles

The TV also has an air mouse, so the map takes a drag (a flick carries on), a scroll to zoom, a hover for a building’s card and a click to open it.

An air mouse moves a little as its button is pressed, so a click can turn into a drag by accident. On the TV, a press has to travel three times as far as on a laptop before it counts as a drag. The map moves only while the button is actually held down, so a button-up the browser never passed on can’t leave the map stuck to the pointer. Put the air mouse down and pick up the arrows, and the pointer carries on from where the cursor was.

Keeping it crisp

The camera is driven by the app, not by Google’s own gestures, which misread the double-size map the app draws for sharpness. Every step in or out is a whole zoom level from the opening view, so the map stays crisp at each stop.

What I took from it

Model the hand, not the keys. Ease in, curve, settle.
Make every press useful. OK zooms until it can open.
Give hardware slack. An air mouse is not a mouse.
BACK should retrace. One level at a time, back to the same spot.

Turning showroom pages into local landing pages

2026-10-27T12:20:00Z

AHA has two experience centres in Mumbai, in Santacruz West and Lower Parel, where buyers can try a smart home before they commit to one. In search, the centres already did more than the website: on commercial queries, the Santacruz Google listing averaged around position 3, while the site’s own sales pages barely ranked. On the website itself, both centres had pages that barely made the case.

What I found in October

Thin, shared copy. The two centre pages had 332 and 362 words, from one shared text. Their schema described a web page and the company, but neither carried a LocalBusiness of its own.
A page Google didn’t know. The Lower Parel page had been live since late September. Google had never crawled it, and URL Inspection called it “URL is unknown to Google”.
A button to nowhere. “Book a Demo” on both pages pointed at a form the template never included.
Three pages, one query. The homepage (title and H1), the About page (title) and the Mumbai page all targeted “home automation mumbai”.

The centre pages

Each centre got its own copy, approved before building: 897 words for Santacruz West and 999 for Lower Parel. Santacruz covers its colour scenes and what a system costs. Lower Parel covers the hardware you can press, from the door lock to the curtain track, and what happens after a visit.

Each page now has:

Visit details as facts: address, hours, walk-ins welcome, about 60 minutes, free, parking.
Nearby areas. “Who Lower Parel is closest to” names Worli, Prabhadevi, Dadar and the rest of south Mumbai. I left named buildings off, because their distance to a centre isn’t on record.
Five visible FAQs, with FAQPage schema built from the same strings.
The lead form, restored.
One LocalBusiness per centre (a HomeAndConstructionBusiness). Each is built once in centres.js and printed by both the centre page and the contact page under the same @id, so the two can’t disagree. Its name, location and map link match the Google listing.

The same afternoon the layout was redone to read well on a phone: visit facts in tiles, nearby areas as chips, and photo cards for the products you can try. As with the rest of the site, I directed the work and Claude Code wrote much of the code.

The Mumbai page

The Mumbai page was rebuilt on 17 September: an answer in its first 44 words, question-shaped headings, a comparison table, and links to the live Google listing in place of a hand-typed “5.0 on Google”. When a national “companies” cluster needed a page the same day, it got an India-wide buyer’s guide, not a second Mumbai page competing with one rebuilt six hours earlier.

On 22 October it closed five gaps against the pages that outrank it: neighbourhoods served, a written warranty, Alexa and Google Home, a dated Google rating in visible text only, and a cost calculator that opens on the same complete 3 BHK as the headline estimate.

That calculator had a bug. Its four weights summed to 0.9999999999999999 in floating point, so the script always rounded down and replaced the figure in the HTML on load. The HTML said one range; visitors with JavaScript saw a lower one. The fix was two lines: round the sum, then round to whole lakh.

Then the overlap. I chose to let the Mumbai page own the query. The homepage title became brand-led, the About title stepped back, and the homepage now links to the Mumbai page in its first paragraph. That has a cost I accepted: the homepage is the page Bing’s AI answers cite most, and “Mumbai” left its title and H1.

Where it stands

Since Google swapped the URLs on 13 October, the Mumbai page has ranked 2 to 4 for “home automation company in mumbai” and two close variants. The homepage only ever reached 7 to 17 on them.
The 22 October work is built, verified and waiting on the next upload. Then Lower Parel gets an indexing request.
Rankings aren’t enquiries. By 22 October, commercial search as a whole hadn’t moved.

Rules for local pages

One query, one page. Pick the owner, and have every other page link to it instead of competing.
One place, one entity. Build each location’s schema once and print it everywhere.
Publish only what’s on record. Areas, scenes and ratings come from records, not memory.
Check what your JavaScript does to the HTML. It can quietly contradict the page it runs on.

One meaning per number, so the screens stop arguing

2026-10-27T12:40:00Z

In mid-October, two tabs of AHA’s sales BI showed the same September, and one total was more than twice the other. Neither tab had a bug. Each was following its own rule, and the rules had drifted apart.

One number, three hidden choices

Each tab had picked up its own answer to three questions:

Which date? Overview put a win on the deal’s closing date. Closed put it on the day someone marked it won in Zoho.
Which amount? One showed amounts after GST. The other showed them as stored in Zoho, with 18% GST included.
Which people? One counted the consulting team. The other counted every consultant.

It wasn’t only the tabs. On 22 Sep it was decided that a deal still waiting for its advance (“Closed and Advance Pending”) is not a win. Two weeks later, the database views and the written instructions behind the Ask chat still counted it as one.

Even the words drifted. In conversation, “taxed” meant the amount with 18% GST taken off. The BI labelled that same figure “untaxed”.

Write each rule once, with its date

The fix was one home for every definition, each filed under the date it was decided:

SQL          call rating 3 or higher, from any source
HQ           rating 4 or 5, always counted inside SQL
CPL          channel spend / all leads in that channel’s bucket
Google       includes WhatsApp-direct and Exotel leads
Win          stage Closed Won, dated by its closing date
Consultant   the deal’s Lead Assigned To
Amounts      after 18% GST is deducted, and labelled so

Those rules live in a compact context file that Claude Code, which wrote much of the code, reads at the start of every session, before any analysis or build. The same file says which source wins for each kind of number, lists every known data defect and what to do about it, files decisions by date, and keeps open questions with the default in use until they’re answered. A separate glossary holds 750 terms.

Most rules have a story. CPL had three candidate denominators (paid-ad leads only, every lead in the channel’s bucket, or the platform’s own count) until one was picked. The consultant rule changed when the BI and a consultant’s own saved filter in Zoho disagreed about their open deals: the BI credited whoever ran the demo, and the filter used Lead Assigned To. The record owner is never used, because it’s the same person on most records.

Why the date rule matters

45% of 2026 wins were marked won in Zoho after their closing date. For nearly half the wins the two dates differ, and the choice can move a win into another month. Marking also happens in batches: one clean-up day in 2025 marked dozens of wins at once.

Neither date is perfect, and a closing date can be backdated. The closing date won because it matches the wins sheet that already existed, and since 15 Oct every tab uses it.

Put the rules where people look

A rule in a file only helps people who open the file. So the BI has an admin panel, Fields & formulas, with 54 metric formulas in plain words, 104 field meanings, 33 traps to avoid when reading Zoho and all 573 Zoho fields, behind one search box. When a number looks odd, its definition is in the same app.

Labels carry rules too. Amounts say “18% GST deducted”, not a word that can be read both ways.

Keep the copies honest

A rule still lives in several copies: the database views, the panel and the instructions written for the Ask chat. Check 9 of the data audit compares every copy with the dated decisions on each change to the BI or its rules, and passes only when they match everywhere. The audit’s other checks, and the bugs they caught, are in Five bugs a data audit caught.

Rules I now keep for every metric

A number is a definition, a date, an amount basis and a group of people. Write all four down.
One home per rule, with its date. Everything else is a copy, and copies get checked.
Labels say what was done. “18% GST deducted” can’t be misread. “Untaxed” was.
When two screens disagree, compare definitions before data.

The numbers didn’t get bigger. They just stopped changing with the tab you opened.