I built a spoiler-safe NYT Connections helper with Astro and Cloudflare

I recently built Connections Hint Today, a spoiler-safe helper for NYT Connections.

The original idea was pretty simple: most Connections helper pages solve the wrong problem.

They are useful if you want the answer right now, but a lot of them jump straight to spoilers. That works for panic-click traffic, but it does not feel great if you still want to solve the board yourself. I wanted something that behaved more like a coach than an answer dump.

So I built a small site around that idea:

• light hints first
• stronger hints only if needed
• archive pages for review
• Sports Edition support
• short explanation and trap notes for each group

The site is live here:

https://connections-hint.today/

And the repo is here:

https://github.com/liuyan-wjy/connections-coach

The product idea

The most important product decision was to treat “help” and “spoiler” as two different things.

If you play Connections regularly, you usually do not want a giant answer page. You want a nudge. Maybe you are stuck between two groupings. Maybe you know one category is structural but cannot see it yet. Maybe the purple group is clearly some kind of phrase pattern, but you are not sure which one.

That is a very different user need from “just show me the answer”.

So the site uses a layered model:

1. Light hint
2. Medium hint
3. Strong hint
4. Reveal answer and explanation

That sounds small, but it changes the whole tone of the product. Once I committed to that, the rest of the site became easier to shape: archive pages, strategy pages, and even the result analyzer all needed to support the same idea of helping without flattening the puzzle.

Why Astro + Cloudflare

This project is a pretty good fit for the Astro + Cloudflare stack.

I wanted:

• static-first pages for SEO
• fast page loads
• simple deployment
• low ops overhead
• enough server-side logic to ingest and publish daily puzzle data automatically

Astro gave me a clean content-heavy frontend without dragging in a lot of complexity. Cloudflare gave me a surprisingly compact deployment model:

• Cloudflare Pages for the site
• Workers for the ingest pipeline
• D1 for puzzle storage
• Browser Rendering as a fallback for dynamic Sports Edition capture

That combination let me keep the public site lightweight while still handling the scheduled automation behind the scenes.

The ingestion problem

The most interesting part of the project turned out not to be the UI. It was the ingest pipeline.

The main Connections board and the Sports Edition do not behave the same way. The main edition was fairly straightforward once I found the right live daily endpoint. Sports was messier.

At first, I tried to capture Sports data through browser automation. That worked some of the time, but it was not stable enough for a daily publishing flow. The browser connection would occasionally time out, which is exactly the kind of failure you do not want in a project that is supposed to update on its own every day.

The fix was to change the ingestion strategy:

• use a direct GraphQL request first
• keep browser capture only as fallback
• write both main and sports puzzles into D1
• mark them as published only when the payload is valid

Once that was in place, daily publishing became much more reliable.

Rule-based copy generation

Another interesting challenge was content generation.

I did not want every puzzle page to say the same thing with a new date stamped on it. At the same time, I also did not want to rely on live AI generation for every daily update. That would increase cost, add latency, and make the output less predictable.

So I built a rule-based copy layer instead.

Right now the generation works more like a lightweight editorial engine:

• detect whether a group is direct, structural, phrase-based, or sports-specific
• generate different hint and explanation styles based on that category shape
• vary summary copy by puzzle type
• keep the tone consistent across the site

It is not trying to imitate a human writer perfectly. It is trying to be useful, stable, and a little less repetitive than a pure template system.

That tradeoff feels right for this stage of the project.

SEO and information architecture

Because this is a search-heavy product, structure mattered a lot from the start.

I did not want the site to be just a single /today page. That would make it too dependent on one expiring keyword pattern.

Instead, I split it into a few clear surfaces:

• /today for fast daily usage
• /puzzle/{id} as the canonical puzzle pages
• /archive for review
• /sports for Sports Edition
• strategy pages for evergreen traffic

I also made /today noindex,follow and pointed canonical to the actual puzzle detail page. That gave the site a cleaner search shape and reduced duplication risk.

What I learned

A few things stood out while building this:

1. The real product is not the answer page

The answer page gets the initial traffic, but the real product is the habit loop around it.

If someone comes back for archive review, strategy pages, or Sports Edition, that is much more valuable than a one-time click for today’s board.

2. Small automation details matter more than flashy features

The site became meaningfully better once the daily ingest was reliable. That mattered more than adding another feature.

3. Distribution rules matter

Communities that seem like an obvious fit are not always friendly to direct links. Some puzzle communities treat any link to a current-board helper as a spoiler, even if the page is intentionally spoiler-safe.

That means the product and the distribution strategy have to be designed together.

4. AI is optional

A lot of projects like this immediately jump to “just use AI for the content”. I think that is often the wrong first move.

For this project, deterministic rules got me much farther than I expected. They are cheaper, easier to test, and easier to reason about when something goes wrong.

What is next

The next things I want to improve are:

• better puzzle-specific commentary
• more evergreen strategy content
• stronger archive depth
• clearer post-game analysis

I also want to keep refining the copy so it feels less like a generated system and more like a compact field guide for repeat players.

If you build content-heavy side projects, I would be curious how you think about this tradeoff:

When do you keep a site deterministic, and when do you add AI into the publishing path?