DEV Community: Charles Blackwood

I built an SEO interception engine for my side project in one week. Here's the exact system

Charles Blackwood — Fri, 29 May 2026 10:42:58 +0000

Most developers think about SEO the wrong way.

They write blog posts. They optimise their landing page. They add meta tags and hope Google notices.

That's broadcasting. You're shouting into the void and waiting.

There's a better move: interception.

Find the exact moment a developer is in pain. Meet them there. Solve it. Let the tool speak for itself.

That's what I spent the last week building for PasteCheck — a mobile-first code linter I built entirely from my Android phone.

Here's the exact system.

The core insight

Developers don't search for "code linter." They search for their error.

"Cannot read properties of undefined JavaScript"
"Python indentation error fix"
"Unexpected token JavaScript"

These are high-intent, emotionally charged searches. Someone's code is broken. They're frustrated. They want a fix in the next 30 seconds.

If you can intercept that search with a page that actually solves the problem — and then naturally introduces your tool — you don't need to advertise. You're already inside the moment.

The architecture

I built a config-driven SEO page system. One template. One data file. Zero duplicated JSX.

The data file: src/data/fixPages.ts

Every page is a config object:

{
  title: "How to fix: Cannot read properties of undefined in JavaScript",
  slug: "cannot-read-properties-of-undefined",
  language: "JavaScript",
  summary: "This error means your code tried to access a property on a value that is undefined...",
  whyItHappens: "JavaScript allows variables to exist without a value...",
  brokenExample: `async function getUser() { ... }`,
  fixedExample: `async function getUser() {
    if (!data.profile) { return; }
    console.log(data.profile.name);
  }`,
  commonCauses: [
    "Accessing nested properties before checking the parent exists",
    "An API call returned null or an empty object",
    ...
  ],
  primaryCtaCopy: "Check your code and see the exact error line",
  searchIntent: "error-fix",
}

The template: ErrorFixPage.tsx

One component renders all 20 pages. Title, summary, broken example, fixed example, common causes, CTA — all pulled from config. Change the data, get a new page. No copy-paste, no drift between pages.

The route: /fix/:slug

Dynamic route via Wouter. One line in App.tsx:

<Route path="/fix/:slug" component={ErrorFixPage} />

SEO: canonical tags via react-helmet-async

Every page gets its own canonical, meta title, and description. No duplicate content risk.

20 pages in one sprint

The first 20 pages cover:

11 JavaScript errors (the biggest search volume)
6 Python errors
2 HTML errors
1 CSS error

Each page took about 20 minutes to write. The template handles everything else.

All 20 submitted to Google Search Console on May 28. Currently discovering. The compounding starts now.

What else shipped this week

The SEO engine wasn't the only thing. Here's the full v2.18–v2.33 sprint:

UX:

Two-column desktop layout — input left, results right. Mobile untouched.
First 3 errors expand automatically on check
"All errors fixed ✓" state — only triggers when previous check had errors
Ctrl+Enter keyboard shortcut
First-time onboarding snippet — pre-filled broken JS on first visit
Check button loading state

Infrastructure:

Fixed a critical black screen bug — setHistory was outside a setTimeout closure. Vite's minifier renamed the variable reference in production. Silent in dev. Blank page in prod.
Closed a Pro bypass vulnerability on the /success page
Extended Stripe webhook to handle subscription cancellations and failed payments
Enabled Dependabot

Distribution:

Listed on AlternativeTo — already the highest-quality traffic source in GA (1m 31s avg engagement)
Full violet rebrand sitewide

The numbers so far

Two weeks post-launch:

126 total users
UK users: 2m 43s avg engagement, 84% engagement rate, 81% of all events — the real market
US users: 1s avg engagement — launch traffic, not retention
AlternativeTo sending better-quality sessions than Reddit or Dev.to
Organic search: 94% engagement rate on 18 sessions — early SEO working

The SEO pages haven't indexed yet. That's week 3.

The strategic frame

This isn't about gaming Google. It's about being genuinely useful at the exact moment someone needs help.

Every fix page is a real explanation written for a real error that real developers actually hit. The CTA into PasteCheck is natural — "want to find this exact line in your code?" — because that's what the tool does.

20 pages compounds. 50 pages compounds heavily. 100 pages becomes a moat.

Built entirely from an Android phone.

PasteCheck is a free mobile-first code linter. Paste your JavaScript, TypeScript, Python, HTML, or CSS — see your errors instantly, in plain English. pastecheck.co.uk

I Built a Pro Tier with Stripe, Supabase Auth, and Multi-File Mode From My Android Phone

Charles Blackwood — Sun, 24 May 2026 17:59:06 +0000

No MacBook. No desk setup. No IDE.

Every line of code in PasteCheck was written on an Android phone using SPCK Editor, committed via GitHub mobile, and deployed to Vercel. That includes the free tier launch, the linting engine, and everything I'm about to describe.

This week I shipped Pro tier. Here's exactly how I built it.

What PasteCheck is (quick context)

PasteCheck is a mobile-optimised code linter. You paste code, it detects the language, highlights errors and warnings, and gives you tappable explanations with actionable fix hints. No setup. No signup required for the free tier.

It supports JavaScript, TypeScript, Python, HTML, and CSS. The linting runs entirely client-side no server round trips, no latency.

Pro tier adds three things: multi-file mode (up to 5 files at once), shareable check links (permanent URLs anyone can view), and saved collections (cross-device sync via Supabase).

The auth flow: magic links vs passwords

The first decision was authentication method. I initially set up Supabase magic links so user enters email, gets a link, clicks it, they're in.

It broke the user flow immediately. Every session meant going to your email, finding the link, clicking back to the app. For a tool people use repeatedly that's friction that compounds fast. I scrapped it and rebuilt with email and password.

The Supabase email + password flow in React looks straightforward on paper. In practice the callback routing caught me, the /auth/callback page needs to handle two completely different scenarios: email confirmation on signup (verifyOtp) and session restoration on login (getSession). Getting those two paths clean without one interfering with the other took a few iterations.

The confirmation email routes through Resend on a custom domain (noreply@pastecheck.co.uk). 3,000 emails a month free. That was a zero-cost decision that took about 20 minutes to configure.

Pro gating: keeping free users out of paid features

This was the most important piece to get right. The Pro gate connects three things: Stripe payment confirmation, a Supabase is_pro boolean on the user record, and localStorage for session persistence.

The flow on successful payment:

Stripe redirects to /success
/success writes the Pro licence to localStorage immediately (so the UI updates without a round trip)
/success also writes is_pro: true to Supabase via a serverless function
On every subsequent mount, login, and page load the app re-syncs is_pro from Supabase

The reason for both localStorage and Supabase is speed vs reliability. localStorage gives you instant UI response. Supabase gives you truth that persists across devices and survives a cleared browser. Neither alone is sufficient.

The gating itself is a check against both the local state and the synced Supabase value before rendering any Pro component. If either is missing or false, the upgrade prompt shows instead.

Stripe: test mode to live mode

I built the entire payment flow in Stripe test mode first. Fake card numbers, test webhooks, the full checkout session. Once it was working reliably I switched to live keys, hit the upgrade button myself, and watched the checkout load with a real cs_live_ session URL, no test banner, real payment form.

I didn't pay for my own subscription to verify it. I trusted that test mode behaviour maps cleanly to live mode, which it does, by design. The architecture doesn't change between modes. Only the keys change.

The Stripe integration runs through a Vercel serverless function (api/create-checkout.ts). It creates the checkout session server-side so the secret key never touches the client. Standard practice but worth stating explicitly if you're building this for the first time.

Multi-file mode

This was the most satisfying feature to build. The UI lets you add up to 5 named files, switch between them, and see per-file linting results alongside a summary bar showing total errors and warnings across all files.

The architecture is straightforward. each file is an entry in a React state array with its own name, content, and result set. The linter runs on each independently. The summary bar aggregates.

What makes it feel polished is the tab system. Each file gets a tab. The active tab highlights. Errors on inactive tabs show a red indicator so you can see at a glance which files need attention without switching to them.

Shareable check links

User hits share, a serverless function writes the current code and results to a Supabase shared_checks table, returns a unique ID, and the app constructs a /s/[id] URL. The share page is read-only — anyone with the link can see the code and results without an account.

The share page includes a CTA to the free tool for users who arrive without an account. Every shared link is a passive acquisition touchpoint.

What the stack looks like end to end

React / TypeScript / Vite / Tailwind — client
Vercel — hosting and serverless functions
Supabase — database and auth
Stripe — payments (£4/month)
Resend — transactional email
SPCK Editor on Android — where every line was written

Total infrastructure cost: £0 until revenue arrives. Vercel free tier, Supabase free tier, Resend free tier, Stripe takes a cut only on successful payments.

The Android constraint

I want to be direct about this because it changes how you think about the whole build.

Working from Android means no terminal. No local dev server. No hot reload in a browser you control. Every change is: edit in SPCK → commit via GitHub mobile → wait for Vercel to deploy → test in mobile Chrome.

The feedback loop is longer. But it forces discipline. You don't make speculative changes because every change costs a deploy cycle. You think the edit through before you make it. You read the code more carefully because you can't run it locally to check.

I'm not claiming it's better. I'm saying it's a real constraint that produces a specific way of working and that way of working built a production app with live payments in a few weeks from nothing.

Where it is now

PasteCheck is live at pastecheck.co.uk. Free tier is fully functional with no account required. Pro is £4/month.

If you paste code regularly for debugging, for learning, for checking before committing give it a try. The mobile experience in particular is something most linters don't prioritise.

If you're building something solo under constraints, I'd genuinely like to hear what your setup looks like. The Android-only workflow is uncommon enough that I rarely find other people doing it.

Built solo. Deployed from a phone. Open for business.

PasteCheck v1.7 + v1.8 — Hints that tell you what to fix, and a nudge panel that tells you where to start

Charles Blackwood — Fri, 22 May 2026 23:20:14 +0000

Most linters tell you what's wrong. They stop there.

PasteCheck has always shown you the error and the line. But "var is discouraged" doesn't tell a beginner what to actually do about it. "Empty catch block" doesn't tell you why it matters or what to replace it with.

That changes in v1.7.

Every error and warning message now ends with one actionable sentence. Not a docs link. Not a vague suggestion. One clear fix.

Prefer 'let' or 'const' over 'var' — use 'const' if the value never changes, 'let' if it does
'eval()' executes arbitrary code — dangerous and a security risk — remove it and find a safer alternative like JSON.parse() or a lookup object
Empty catch block — errors are silently swallowed — add at least console.error(e) so failures don't disappear silently

This covers every language PasteCheck supports — JavaScript, TypeScript, Python, HTML, and CSS. 30 messages updated across the entire linter.

Two Reddit commenters validated this independently before it was built. Both said the same thing unprompted — knowing what's wrong isn't enough, you need to know what to do next. That's what v1.7 ships.

v1.8 adds something no other paste tool has.

When errors or warnings exist, a collapsible "What to do next" panel appears below the results. Not per-error guidance — big picture debugging logic. The kind of thing an experienced developer would tell you if they were sitting next to you.

If you have errors: fix the first one before the rest. Errors cascade. One missing bracket can cause five false positives below it.
If you have warnings only: no errors is good — work through warnings one at a time using the fix hints above.
If you have both: ignore the warnings for now. Fix the errors first. Warnings can wait until your code runs.

It's collapsed by default. It doesn't get in the way. It's there when you need it.

Both features were designed around the same principle — PasteCheck doesn't just find your mistakes, it helps you understand them.

Built entirely from an Android phone. Live at pastecheck.co.uk.

I built a syntax linter from my Android phone. Here's what v1.6 taught me about false positives.

Charles Blackwood — Fri, 22 May 2026 19:33:44 +0000

A few weeks ago I was debugging a TypeScript file on my phone and pasted it into three different AI tools trying to get a clean syntax check. Every one of them reformatted something. One introduced a line break mid-string. Another quietly changed a variable name.

I didn't need AI to fix my code. I needed something to read it and tell me what was wrong. So I built PasteCheck — a dark-themed, mobile-optimised linter that runs entirely in the browser. No backend. No login. No reformatting.

I built the whole thing from my Android phone using SPCK Editor, Termux, and GitHub. No laptop. No desktop. That constraint turned out to matter more than I expected — but more on that later.

This is the story of v1.6, and what I learned building it.

The problem with being too clever

By v1.5, PasteCheck was linting JavaScript, TypeScript, Python, HTML, and CSS with decent accuracy. Session history was live. The core loop worked.

Then I started getting false positives.

The duplicate variable checker I shipped in v1.6 was supposed to catch const and let redeclarations — a real, common mistake. But without scope awareness, it was flagging perfectly valid code where the same variable name appeared in two separate functions. Technically the same name. Semantically completely different things.

The fix was a scope stack — push on function and block entry, pop on exit. Simple in principle. Fiddly to get right. The checker now correctly ignores cross-scope reuse and only flags genuine same-scope redeclarations.

The lesson: a linter that's wrong loudly is worse than no linter at all. Developers learn to ignore noisy tools. Once you've trained someone to dismiss your warnings, you've lost them.

The large file problem

The same issue appeared from a different angle with TypeScript detection.

PasteCheck uses acorn with an acorn-typescript plugin to parse TS files. For small files, this worked cleanly. Then someone pasted a 974-line linter.ts file and it misdetected as Python — because the file contained import * and print, both of which pattern-match as Python syntax.

The fix was ordering: TypeScript detection now runs before Python detection. Obvious in retrospect. But it only surfaced because the file was large enough to contain Python-shaped TS patterns.

I also capped the duplicate variable checker and TS regex fallbacks at 200 lines. Not because large file support isn't worth building — it is, and it's in the roadmap — but because a wrong answer on a 500-line file does more damage than a "file too large, try a smaller snippet" message. Honest limitations beat confident mistakes.

What else shipped in v1.6

Beyond the scope-aware duplicate variable detection and the language detection fix:

Python pass check. A pass statement inside a non-empty block is redundant — the block runs fine without it. v1.6 flags these as warnings by looking ahead for sibling lines at the same or deeper indent level. Small thing, but it catches a specific habit that creeps into refactored Python.

CSS missing units. Non-zero numeric values on dimension properties — margin, padding, width, height, font-size, border-radius, and 20+ others — flagged as warnings with a "did you mean 16px?" suggestion. Zero values are correctly ignored. This one came from my own mistakes more than anything else.

The Android constraint

I mentioned building PasteCheck entirely from an Android phone. This isn't a gimmick — it's the actual development environment.

Every commit, every deploy, every debug session happened on a phone screen. Termux for the terminal. SPCK Editor for the code. GitHub for version control. Vercel for deployment via GitHub sync.

The constraint has a real effect on what gets built. When your own testing surface is mobile, mobile UX problems surface immediately. The v1.4 scroll fix — removing a fixed maxHeight on the results panel that was creating a box-within-a-page scroll nightmare — would have taken much longer to catch on a desktop.

Building from the same device your users are likely using isn't a limitation. It's a feedback loop.

Where PasteCheck is now

Five languages. Real syntax detection. Session history. 54 users across five countries in the first five days — US, UK, Canada, Türkiye, and others showing up in Analytics.

The roadmap has a Pro tier on the horizon — GitHub integration as the proposed anchor feature, so PasteCheck runs on every push rather than requiring manual paste. That's a Week 2 research problem. Right now the free tier is the product, and it's earning its keep.

If you work with code on mobile — or just want a clean, instant paste-and-check tool without an AI trying to improve your work — give it a try.

pastecheck.co.uk

Building in public, solo, from Android. Follow along if that sounds interesting.

PasteCheck v1.3 — what I improved after launching and getting real users

Charles Blackwood — Wed, 20 May 2026 14:20:18 +0000

A few days ago I launched PasteCheck — a free tool
to paste code and see errors highlighted instantly.

After launch I found real gaps and shipped v1.3.
Here's what changed:

Python indentation monitor
Now flags mixed tabs and spaces as an error, and
inconsistent indentation style across the file as
a warning.

CSS property validator
Embedded CSS inside HTML now checked for misspelled
properties. Catches things like colour instead of
color, font-weigh instead of font-weight —
with "did you mean X?" suggestions.

Aria-label support
Previously flagged inputs with aria-label or
aria-labelledby as unlabelled. Fixed — those are
now correctly recognised as labelled.

Language detection confidence UI
Short snippets under 5 lines now show a subtle ?
badge next to the detected language so users know
detection may be approximate.

All shipped in a single session, tested, live.

Try it: https://www.pastecheck.co.uk

What would you want to see in v2?

I built a free mobile-friendly code error checker — PasteCheck

Charles Blackwood — Mon, 18 May 2026 20:30:15 +0000

I got frustrated constantly copy-pasting broken code into AI and getting inconsistent results. So I built PasteCheck.

You paste JavaScript, Python or HTML and every error gets highlighted instantly. Tap any highlight to see what the issue is. No sign up, completely free, works well on mobile.

Would love feedback from developers:

(https://www.pastecheck.co.uk)