DEV Community: Andy Stanly

Codes pages are the fastest-traffic pages you can build — and the fastest to lose

Andy Stanly — Thu, 15 Oct 2026 17:01:49 +0000

A codes page can carry a site. It can also destroy it, because the traffic it attracts is exactly the traffic that leaves the moment the codes stop working.

Why codes pages work

The search intent is unambiguous: the player wants free items, now. There is no reading, no comparison, no decision. That makes the page easy to rank and easy to satisfy — a short list, a copy button, done.

It is also the only kind of page where speed is the feature. If the codes are twelve hours stale, the visitor bounces and does not return.

What went wrong on my first version

I treated it as a content page: long introduction, background on the game, then the codes. The intro was there for the search engine. The reader scrolled past it every time.

Two changes fixed it:

Codes first, above everything, with the timestamp visible.
A "what changed" line per code, so a returning reader can see in one second whether anything moved.

The structure that keeps them coming back

A codes page is a hub, not a destination. It earns repeat visits when the reader can see the whole system in one screen:

the codes, with status and date
how to redeem them, in one sentence
a link to the deeper reference — the stands wiki — for the part that is not just a code

Be honest about expiry

Marking a code as expired is better than leaving it in the list. A reader who finds one dead code stops trusting the other twenty.

Written after watching a codes page out-traffic every guide on the same site.

What building a traffic game taught me about teaching a system

Andy Stanly — Thu, 15 Oct 2026 16:59:41 +0000

Traffic systems look simple until you build one. Two roads, one intersection, obvious right answer — and then every player does something you did not anticipate.

The first twenty minutes decide everything

When I looked at where players quit, it was never the hard levels. It was the third or fourth decision, when the game had introduced enough systems that the player could no longer hold them all at once.

The fix was not a tutorial. It was removing a system from the early levels and reintroducing it later, once the first one was automatic.

Teach one variable at a time

A beginner guide has the same problem as a beginner level. If it explains cost, throughput, and layout in the same paragraph, the reader retains none of them.

What worked:

One decision per section. Cost first. Then throughput. Then layout.
Name the failure, not the rule. "Players build the long route first and run out of budget" teaches more than "budget matters".
Say what to ignore. Half of a beginner's anxiety comes from systems they do not need yet.

The metric that mattered

Not time on page. Whether the reader took one more action — built the thing, tried the layout, came back the next day.

That changed how I wrote. Instead of explaining the whole system up front, every section ends with one concrete thing to try, and the next section assumes they tried it.

Write the guide as a sequence of decisions

If you are writing a beginner's guide for a systems game, structure it like the game structures its levels: one new variable at a time, a named failure mode, and a reason to keep going.

Notes from building and rebuilding the same traffic sandbox three times.

Shipping a niche tool: the honest version of the launch story

Andy Stanly — Sat, 10 Oct 2026 18:13:28 +0000

Launch posts usually skip the part where nothing happens for six weeks. Here is what actually moved the needle on a small niche tool, in order of effect.

1. A walkthrough beats a feature list

The single highest-impact page was not the landing page. It was a plain walkthrough: what the tool is for, the exact steps for one real task, and what the output looks like. People arrive with a task, not with curiosity about features.

2. Answer the question that made you build it

I built the thing because a specific question kept coming up and no page answered it properly. Writing that answer down — as a page, not a blog post — brought the first consistent traffic.

3. Free tier must complete a real task

A free tier that only demonstrates produces no word of mouth. One that lets someone finish a genuine piece of work produces recommendations, which is the only marketing that compounds.

4. Fix the first-run experience before adding features

Watching five people use it for the first time was worth more than a month of feature work. Three of the five got stuck in the same place, and it was not a bug — it was a label.

What did nothing

Posting the launch in general communities.
Paid anything.
Redesigning the landing page twice.

If you are documenting your own tool, a good tool walkthrough guide will outlast every announcement you write.

Written six months after a launch that felt like nothing and then quietly worked.

Shipping a niche tool: the honest version of the launch story

Andy Stanly — Sat, 10 Oct 2026 17:52:21 +0000

Launch posts usually skip the part where nothing happens for six weeks. Here is what actually moved the needle on a small niche tool, in order of effect.

1. A walkthrough beats a feature list

2. Answer the question that made you build it

I built the thing because a specific question kept coming up and no page answered it properly. Writing that answer down — as a page, not a blog post — brought the first consistent traffic.

3. Free tier must complete a real task

A free tier that only demonstrates produces no word of mouth. One that lets someone finish a genuine piece of work produces recommendations, which is the only marketing that compounds.

4. Fix the first-run experience before adding features

Watching five people use it for the first time was worth more than a month of feature work. Three of the five got stuck in the same place, and it was not a bug — it was a label.

What did nothing

Posting the launch in general communities.
Paid anything.
Redesigning the landing page twice.

If you are documenting your own tool, a good tool walkthrough guide will outlast every announcement you write.

Written six months after a launch that felt like nothing and then quietly worked.

What running a game server list taught me about keeping data honest

Andy Stanly — Sat, 10 Oct 2026 17:47:26 +0000

A server list sounds like a table. It is actually a freshness problem: the moment your data is wrong, the list is worse than nothing.

Stale entries cost more trust than missing ones

A missing server is an inconvenience. A server listed as online that has been dead for three weeks is a broken promise. So the design goal was not completeness, it was honesty about recency: every row carries a last-checked time, and anything unverified past a threshold is visibly marked.

Ping on a schedule you can afford

The naive version pings everything constantly and gets rate-limited. What worked:

Check popular entries often, long-tail entries rarely.
Back off exponentially after failures instead of hammering.
Store the last successful check, not just the last attempt.

Let players correct you

A one-click "this is wrong" button that does not require an account produced better data than any automated check, because players notice things a ping cannot: wrong region, wrong rules, fake player counts.

Present the numbers you can defend

If you show a player count, show when it was measured. If you cannot measure it, do not show it. Every unverifiable number on the page undermines the verifiable ones next to it.

If you are building a game server list, treat freshness as the feature and everything else as decoration.

Written after deleting forty percent of a directory for being out of date.

Building a solver for a puzzle game nobody had documented

Andy Stanly — Sat, 10 Oct 2026 17:41:24 +0000

When a game has no published mechanics, you end up reverse-engineering it — and the reverse-engineering is more interesting than the solver.

Start by writing down what you observe, not what you assume

My first notes were full of guesses: "the drop rate feels like one in ten". Useless. The version that became a usable guide recorded only what could be repeated:

Screenshot, board state, and the exact move made.
The result, including the cases that contradicted the theory.
The date, because balance patches land quietly.

Twenty recorded boards told me more than two hundred casual plays.

Level rules are usually positional, not random

The hardest part was accepting that some levels are not solved by the obvious move. Once I started logging where pieces were rather than what they were, patterns appeared: certain layouts punish the first move everyone tries.

Write for the player who is stuck, not the one who is curious

A theory page is fun to write and rarely read. The page that gets shared answers one question: "I am on level N and cannot see it." So the guide is organised by level, shows the board, and names the trap in one sentence.

Separate the solver from the explanation

A puzzle solver guide is a tool. The explanation of why a move works is the reason people come back. Keep them on the same page but do not make the tool the whole page.

Notes from documenting a puzzle game from scratch.

What a small quest guide site taught me about search intent

Andy Stanly — Sat, 10 Oct 2026 17:38:00 +0000

Guide sites live or die on one thing: whether the page answers the question the visitor actually typed. Building one for a game made the mismatch obvious in a way that general SEO advice never did.

There are three different questions behind one page

A single quest attracts at least three visitors, and they want different things:

"Where do I go?" — a location, a map, a direction. They want an image and a name, nothing else.
"How do I do it?" — ordered steps, including the step everyone gets stuck on.
"Why did it fail?" — the edge case: the item they missed, the prerequisite they skipped, the bug.

The page that ranks and keeps people is the one that puts all three in order, with the location first because that is the most common arrival.

Put the answer above the story

Lore is lovely and it belongs below the steps. My first version opened with two paragraphs of setting; the second opened with a bulleted path and a map, and time-on-page went up rather than down.

Name the stall points explicitly

"Walk north until you reach the ruins" fails for the reader who took a different route. "The trigger only fires if you approach from the east side" saves them twenty minutes and earns the bookmark.

Keep a corrections box

Every guide gets a comment saying a step changed. Having a visible "last verified" date and a one-line changelog means those readers trust the rest of the page.

If you are writing one, treat the quest walkthrough guides as the product: short, specific, and verified against the current patch.

Written after rewriting the same guide four times and watching the shortest version win.

Building a wiki for a game that updates every few weeks

Andy Stanly — Sat, 10 Oct 2026 17:37:06 +0000

A wiki for a live game has one problem a normal wiki does not: the ground moves. Every patch invalidates pages you spent a weekend on, and the pages that go stale are usually the popular ones.

Here is the structure that survived contact with a game that updates constantly.

Separate what changes from what does not

The single most useful decision was splitting pages into two kinds:

Volatile pages: stats, recipes, drop tables, tier lists. These carry a version stamp in the URL or the header, and they are expected to be rewritten.
Stable pages: how a mechanic works, why a strategy is sound, what to do first as a new player. These survive patches because they describe reasoning, not numbers.

A guide that explains why a build works outlives a guide that lists its numbers, every time.

Version the numbers, not the prose

Where a number must appear, put it in one place and reference it. When the patch lands you edit one table instead of forty paragraphs. This is dull engineering and it is the difference between updating a wiki in an hour and abandoning it.

Write for the person arriving from search

Most visitors land on one page and never see your home page. So every page has to answer a whole question on its own: what changed, what to do, and what to read next. Navigation is a bonus, not a safety net.

Mark outdated pages honestly

A banner saying "this was written before patch X" costs nothing and buys trust. Quietly leaving stale numbers up costs you the visitor permanently.

If you are starting one, begin with three game wiki guides pages that will still be true next month, then add the volatile ones.

Notes from maintaining a wiki through four major patches.

The documentation page that answered 80% of support questions

Andy Stanly — Sat, 10 Oct 2026 17:34:18 +0000

Support load is usually a documentation problem wearing a costume. On a project of mine, one page cut the recurring questions dramatically, and it was not the page I expected.

Nobody reads a manual, everybody reads an answer

My first attempt was a structured reference: every setting, every option, alphabetical. Traffic was fine and support tickets did not move.

The page that worked was written as questions in the user's own words, in the order they actually get asked. Not "Configuration options" but "Why is my result different from the example?"

Write the top ten questions first

I pulled every repeated support message for a month and grouped them. Ten questions covered roughly four out of five tickets:

Why does this not work the way the demo does?
What do the defaults assume?
How do I undo this?
Where does my data go?
Why is it slow sometimes?
Can I use the output commercially?
What happens if I close the tab?
How do I get a consistent result twice?
What is the cheapest way to do this repeatedly?
Who do I contact when it breaks?

Each answer got a short paragraph and a link to the relevant screen. No screenshots of every button — just the ones people could not find.

Put the answers where the failure happens

A documentation page only helps people who go looking. The bigger win was linking the specific answer from the error state itself, so the person who just hit the problem lands on the paragraph that explains it.

Keep it honest about limits

Stating plainly what the tool does not do reduced refund requests more than any feature I added. That is a strange thing to write and a true one.

If you maintain anything with users, treat your hotel lobby AI guide as a product surface, not a chore. It is read far more than your changelog.

Written after a single FAQ page outperformed three months of onboarding work.

What I learned building an image-to-video tool as a weekend project

Andy Stanly — Sat, 10 Oct 2026 17:31:35 +0000

Turning a still image into a short video sounds like a model problem. It is mostly a patience problem — yours and the user's.

Generation is slow, and that is the whole UX

Every design decision follows from one fact: a clip takes tens of seconds, sometimes minutes. That ruled out a lot of things I wanted to build.

No live preview while typing.
No "try again" button that silently starts another long job without saying so.
No queue that hides its position.

What worked instead: one input, one button, a progress state that says what is actually happening, and a result you can download immediately when it lands.

The three settings that matter

My first version exposed a dozen knobs. Almost nobody touched more than three. The ones that changed output quality in ways users could actually see:

Motion intensity. Too low looks like a slideshow; too high looks like a glitch.
Duration. Short clips hide artefacts better than long ones, and they generate faster.
Aspect ratio. Deciding this early avoids a whole class of complaints.

Everything else went under an advanced panel.

Fail loudly, and keep the input

When a generation fails, the worst thing you can do is clear the form. Keeping the uploaded image and the settings means one click to retry, which turned a frustrated user into a returning one more than once.

What I would cut from day one

Accounts. Let people generate before signing up.
Watermarks on the free tier that are so large they make the output useless.
A gallery of other people's results before the user has made anything.

If you are building anything in this space, start with an AI image to video generator that does one thing quickly rather than a studio with forty controls.

Notes from shipping and then shrinking the same tool three times.

The cost calculator nobody asked for, and why it became the most visited page

Andy Stanly — Sat, 10 Oct 2026 17:29:45 +0000

Every content site has a page the owner built reluctantly that quietly outperforms everything they enjoyed making. On mine it was a cost calculator.

Nobody links to an article, everybody links to a number

An explainer gets read and forgotten. A calculator gets returned to, bookmarked, and pasted into group chats. The difference is that a calculator produces something the user needs again next month.

That also changes the linking pattern: people link to a tool with the words "use this to work out yours", which is far more natural anchor text than anything you can write into a post.

The three inputs rule

My first version had eleven inputs across three sections. Conversion was poor, because eleven inputs is a form, not a tool.

The version that worked had three inputs, sensible defaults, and one number that updated live. Everything else moved behind an "advanced" disclosure that roughly 4% of visitors opened.

Show the working

People trust a number they can check. Adding a small breakdown — the formula, in plain language, with the actual substituted values — cut the bounce rate on the results state noticeably and produced the only user emails I actually enjoyed reading.

Make the result shareable

A calculator with a shareable URL (inputs in the query string) turns every result into a link someone can send. That is free distribution and it costs about twenty lines of code.

What I would skip

Charts. Nobody looked at them.
PDF export. Requested once, used never.
A backend. All of it runs client-side, which is also why it never goes down.

If you are sitting on a decision your audience makes repeatedly with numbers, a streaming cost calculator will outperform the article you were planning to write about it.

Written after watching a reluctantly-built tool out-traffic a year of guides.

Building an interactive map for a game wiki: what broke, and what I would do again

Andy Stanly — Sat, 10 Oct 2026 17:27:31 +0000

A game wiki starts as a list of pages and turns into a mapping problem the moment players ask "where is it?" rather than "what is it?".

Here is what I learned building an interactive game map for a game database, including the parts I got wrong.

Coordinates are the easy part

Storing x/y on a page is trivial. The hard parts are:

Zoom levels. One image does not survive 0.25x to 8x. You need tiles, or at least a few re-rendered sizes, or the map looks like a blur at the zoom players actually use.
Marker density. Four hundred pins at once is not a map, it is a texture. Clustering by zoom level is not optional.
Deep links. Every marker needs a URL that opens the map at that point. Players share locations far more than they share guide pages.

Deep links changed how the map gets used

Before deep links, the map was a page people visited. After, it became something people linked to — from guides, from forum answers, from Discord. That single change did more for returning visitors than any visual polish.

Filter state belongs in the URL too

If a player filters to one region and one category, that state should survive a refresh and be shareable. Doing this meant treating the URL as the source of truth and re-deriving the UI from it, rather than keeping filter state in component state and hoping nobody reloads.

What I would not do again

Build a custom tile pipeline first. Cache the pre-rendered sizes, measure whether anyone zooms past 2x, and only then invest.
Design the pin icons before the clustering. Clustering changes what a pin has to communicate.
Hide the coordinate in the page data. Put it somewhere queryable from day one.

The metric that mattered

Not page views. Marker opens per session. A visitor who opens three markers is using the map; a visitor who bounces off the overview is not, and the overview is the thing I kept polishing.

Written after rebuilding the map twice. The second version was smaller, faster, and the only one players linked to.