I track a lot of repos. Most drift off a few months after I first star them. These five stayed useful across every build I've touched this year — one running on a Raspberry Pi in a room, three running on Vercel. None of them are glamorous. All of them solve a real constraint.
NCNN — neural network inference without CUDA
When I started running a YOLO model on a Raspberry Pi 3, every inference framework I tried assumed a GPU. NCNN doesn't. It's Tencent's open-source inference library for ARM and x86, and it has no external runtime dependencies.
For my shelf-scanning PoC, I exported a fine-tuned YOLO11n model to NCNN format. The resulting weights file came out to 36 MB (model.ncnn.bin). Running inference on a Pi 3 Model B — 906 MB RAM, no accelerator — the measured median is 8.5 seconds per scan, across 19 real scans on the device (range 8.4–11.8 s). That is slow. For a system that scans once per hour, it is fine.
NCNN forces a real tradeoff: I dropped the input resolution from 640 px (used in training) to 416 px to keep memory inside what the Pi can handle. The model still delivered mAP50 0.844 on the held-out test set, but that number was earned as much through post-processing as through model accuracy. NCNN gets you to the shelf; it does not make the shelf problem easy.
Repo: github.com/Tencent/ncnn
Ultralytics YOLO11n — small detection model with a transparent training API
YOLO11n is the Nano variant in Ultralytics' current lineup. I trained it for empty-shelf detection on a Mac using Apple MPS — device="mps", imgsz=640, batch=16, epochs=60. Zero cloud GPU cost.
After 60 epochs on 9,358 training images: validation precision 0.782, recall 0.734, mAP50 0.792. On a separate held-out test set (1,255 instances), precision reached 0.82 and mAP50 0.844. I also ran YOLO11s (the Small variant) under the same conditions; it hit 0.820 mAP50 on validation. Better, but not enough to justify its larger footprint on constrained hardware. The Nano model is the right call here.
What I value about the YOLO11 API is predictability: one training call, a reproducible config dict, and a clean NCNN export at the end. The NCNN export step is the part most tutorials skip entirely — Ultralytics' own docs cover it, but you have to read past the GPU-first examples.
Repo: github.com/ultralytics/ultralytics
Roboflow Universe — public CV datasets with filterable licences
Finding labelled object detection datasets is easy. Finding ones with a commercial-use licence is harder than it should be.
For the shelf project, I merged 7 Roboflow Universe datasets — 11,667 images total, split into 9,358 train / 1,162 valid / 1,147 test — selecting only datasets with CC BY 4.0 licences. The filter is a one-field check in each dataset's metadata. But you have to check: Roboflow Universe hosts datasets under a mix of licences (CC0, CC BY 4.0, CC BY-NC 4.0, and others), and CC BY-NC 4.0 bars commercial use. Roboflow makes this discoverable from the search interface; most dataset aggregators don't.
The outcome: no labelling work. The only cost was downloading, auditing licence strings, and writing the merge script. I went from zero training data to 11,667 annotated images in a day.
Site: universe.roboflow.com
Turso libSQL — SQLite at the edge, with a data model tax
I use Turso for all three of the AI-curated directory sites — Top AI Tools, Find Games Like, and Open Alternative To. The setup is familiar: SQLite-compatible wire protocol, a TypeScript SDK that works like a standard query builder, schema lives in the repo.
The free tier has real constraints. Row limits and database count limits shaped the data model more than the application logic did — I wrote about exactly how in Three ways Turso's free-tier limits shaped my directory site data model. If you're starting a new project assuming Turso free tier, read that first. The shape of the schema it forces on you is not obvious until you're already running.
The tradeoff worth naming: "edge without the serverless tax" is a simplification. You're trading one pricing model for another. For static-first sites where read latency matters more than write throughput, the trade is worth it.
Site: turso.tech
Pagefind — build-time search with no API call at runtime
The last thing I wanted was a search API that charges per query or requires a running server. Pagefind generates a search index at build time — no external service, no API key, no monthly bill after the first day.
The integration with Astro is one npm package and one plugin call. What catches people off guard: Pagefind outputs WASM, so the search logic runs client-side. The index is chunked and lazy-loaded, which matters for large sites that would otherwise pay the full index transfer cost on every page load. I walked through the lazy-loading pattern and how I wired it to a <dialog> element in How I implemented Pagefind search with a lazy-loading native dialog in Astro 5.
The tradeoff is obvious once you see it: results are only as fresh as the last build. For a site that rebuilds on every data update, that is fine. For a site that patches individual records without triggering a rebuild, it is a mismatch.
Repo: github.com/CloudCannon/pagefind
These five aren't the only tools in the stack. They're the ones where I can point to a specific constraint they solved that a more popular alternative didn't — either because the popular alternative assumed a GPU, charged per query, or required a managed cloud service I didn't want to depend on. Low-ceremony tools for constrained builds. That's the criterion I keep coming back to.
Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.
Top comments (0)