Forem: SweepBase

How I Maintained an Awesome-List of 136 Crypto Cards as a CI-Linted Dataset

SweepBase — Thu, 07 May 2026 08:29:34 +0000

Last month I open-sourced awesome-crypto-cards — a curated list of 136 crypto debit and credit cards. This post is about the boring infrastructure: why I run awesome-lint in CI, how I keep the list synced with the dataset behind sweepbase.net, and where I underestimated effort.

Why a flat README, not a database

The list lives as a single README.md. No JSON, no YAML, no static site. People who land on a GitHub awesome-list expect to scan markdown, not click into an interactive viewer.

Trade-offs I accepted: no programmatic queries, no filtering UI, no auto-generated content.

Trade-offs I avoided: an extra build step, broken links from generator bugs, and the friction of "wait, where do I edit this?"

The awesome-lint CI

Every push runs awesome-lint via GitHub Actions. It catches:

Duplicate URLs (you'd be surprised)
Links missing https://
Markdown formatting that breaks GitHub's renderer
Broken anchor references in the contents section
Categories that don't sort alphabetically

# .github/workflows/main.yml
name: Awesome Lint
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '22' }
      - run: npm ci
      - run: npx awesome-lint

The lint config is the strictest version (no-emoji). I keep it that way because the goal is acceptance into other awesome-list registries down the line, and they reject any list that fails their own awesome-lint pass.

Keeping it synced with the source

The dataset behind sweepbase.net is a CSV of 141 rows. Five of those are pre-launch products (waitlist, "in development" custody, "TBA" network) — the README rule is "shipping only," so the README count is 136.

The diff between CSV and README runs as a small Node script:

const csvNames = new Set(cards.map(c => c['Card Service'].trim()));
const readmeNames = new Set();
const re = /- \[([^\]]+)\]\(https:\/\/sweepbase\.net\/cards\//g;
let m;
while ((m = re.exec(readme)) !== null) readmeNames.add(m[1].trim());

const inCsvNotReadme = [...csvNames].filter(n => !readmeNames.has(n));

Each time I add a card to the dataset, this tells me what's missing in the README, and I add it manually. Manual is fine because it's once a week at most.

What I underestimated

Alphabetical filter sections. Each region/custody/use-case section repeats card names. Adding one new card means editing 4-5 lists. I have a script in mind but haven't built it.
The "Related Lists" section. The other awesome-lists in the crypto/defi space are mostly stale (2-3 years since update). Including them feels honest but reduces the list's perceived freshness.
Star farming. Two-week organic plan, 23 days later, 1 star. Reality check: the list needs distribution, not just existence.

If you're building an awesome-list, the lint+CI part is fast. The interesting work is keeping it honest as the underlying space changes.

Repo: https://github.com/mbtrilla/awesome-crypto-cards

Three months of running a Next.js aggregator on a CSV: what broke and what did not,

SweepBase — Wed, 06 May 2026 12:22:11 +0000

I shipped a 141-row crypto card comparison site on a public CSV instead of a database back in February, and I want to write down what I have learned three months in. The earlier posts covered why I picked CSV (why a CSV beats a database for this) and what I would do differently on the architecture side (six lessons-learned from shipping a Next.js 15 + CSV side project). This is the operational version.

What broke

ISR cache went stale faster than I expected. Setting revalidate = 86400 on card detail pages felt safe in dev. In production, when I edited the CSV and pushed, the new content took up to 24 hours to surface on cold pages because Vercel only revalidates on traffic. I added a /api/revalidate webhook that I hit from a small script after every CSV change. That fixed the lag, but it adds a step I forget half the time.

PapaParse parsing in a Server Component blew up once when a column contained a comma inside quoted text and the quoting was wrong. Zod validation caught the malformed row, but I had 20 minutes of "is the entire site broken" panic before I read my own logs. Lesson: always log the failing row before throwing.

Image proxy started rate-limiting. I serve card images via /api/image-proxy with a 7-day cache. About six weeks in, I noticed Google Drive started throttling requests from Vercel egress IPs. Cache hit rate dropped, latency went up. I now host all new card images locally as .webp and only fall back to Drive for legacy entries.

What did not break

The catalog itself. 141 rows in a CSV is below any threshold where you actually need a database. Greps are instant in CI, the file diffs cleanly in PRs, and contributors can read it without a SQL client. I have not regretted this once.

Filter functions as predicates. Every category on the site is a single function (card: Card) => boolean in one file. When I needed to add a new category (Brazil, USDC, self-custody), it was a one-line export. Reading a meta post on the editorial layer of a comparison site made me realize this was the architectural choice that made the most editorial work feel cheap.

Zod schemas as the source of truth. Card type, validation, defaults all in one place. I have refactored the card model three times now and the migration was always trivial because the schema was the contract.

What I would copy on a new project

Start with a CSV. Move to a database only when you have evidence the CSV is the bottleneck. For three months of traffic and 141 rows, mine never was.

If you want the live result, the database is at sweepbase.net and the comparison methodology piece is on Telegraph. There is also a follow-up note on the founder-pitch lens that complements this operational view.

What I learned shipping a Next.js 15 + CSV side project

SweepBase — Thu, 30 Apr 2026 10:48:50 +0000

I shipped a small side project this year: sweepbase.net, a comparison site for crypto debit and credit cards. 139 cards, no DB, the whole dataset is one CSV file in the repo.

Here are the things I'd actually tell another dev about it.

CSV beats a DB more often than people admit

The whole catalog is data.csv, parsed at boot, validated with Zod. Reads outnumber writes by something like 10,000 to 1, and most "writes" are me fixing a number once a month.

For that load profile, a database is theatre. CSV in a public repo gives me:

One source of truth, version controlled
Diff-able commits when I change a number
No admin UI to build
An auditable timeline anybody can inspect

When somebody asks "why did you change Crypto.com APY", I link the commit. That answer is more reassuring than any dashboard.

Zod earns its rent

Zod's schema does double duty: it validates at boot, and it generates the TypeScript type via z.infer. One source for shape, no drift between runtime and compile time.

const CardSchema = z.object({
  service: z.string().min(1),
  fxMargin: z.number().min(0).max(10),
  atmFee: z.number().min(0),
});
export type Card = z.infer<typeof CardSchema>;

If a row in the CSV is malformed, the build fails. I never ship broken data without knowing.

ISR is the right default for content sites

Next.js 15.1 App Router with revalidate: 3600 on every page. The data changes a few times a week. There is no reason to re-render on every request. Lighthouse stays at 100 across the catalog because the rendered HTML is essentially static, and the framework refreshes it every hour.

I had to fight the urge to reach for SSR or client-side fetching. Neither belongs here.

React.cache() is underrated

Multiple components in a single page render call the same getCards() function. Without React.cache(), the CSV gets parsed once per call site. Wrapped in React.cache(), it parses once per request. Easy 10x latency win that I almost missed.

Filters as predicates beats SQL for small data

37 category pages (USA, no-KYC, self-custody, travel, and so on), all rendered from the same Server Component. The category-specific logic lives in lib/filters.ts:

export const isSelfCustody = (card: Card) => card.custody === 'self';
export const isUSACompatible = (card: Card) => card.regions.includes('USA');

Adding a new category page is a 6-line PR: filter, slug, name. No migration, no index to remember.

What I would do differently

Started the public CSV from day one. I used Notion for the first month, lost a week porting it.
Set up Sentry before shipping, not after the first ghost bug report.
Wrote the report-error button in week 1. Real user reports caught more bad data than my own auditing.

Where to look

Live: sweepbase.net
Dataset: /datasets/data.csv
Calculator: /calculator

If you want to see the schema or argue with one of my ratings, both are public. The CSV is the source of truth.