DEV Community: Admin Supafast

Controlling a treadmill from an iPhone over Bluetooth LE

Admin Supafast — Mon, 10 Aug 2026 16:06:32 +0000

Most treadmills have a Bluetooth chip and a companion app nobody enjoys using. I wanted to drive the treadmill - speed, incline, live stats - from a clean SwiftUI app instead. That became Treadmill Pro, an iOS app that talks to the treadmill directly over Bluetooth Low Energy with CoreBluetooth. Here's what building a BLE hardware controller actually involves.

BLE in one paragraph

A BLE device exposes services, each containing characteristics you can read, write, or subscribe to. Fitness equipment often speaks FTMS (the Fitness Machine Service), a standard set of characteristics for treadmills, bikes and rowers. In practice, support is uneven - some machines follow the spec, some ship their own quirks - so you discover services at runtime and adapt.

The connection lifecycle

The unglamorous truth of BLE is that most of the work is state management:

Scan for peripherals advertising the right service.
Connect and discover services and characteristics.
Subscribe to the ones that stream data (speed, distance, time).
Write to the control characteristic to change speed or incline.
Handle disconnects - devices drop, users walk out of range, sessions end.

Every one of these steps can fail or stall, so the app is really a state machine with a treadmill on the other end.

Reading stats vs sending commands

Two directions, two different concerns:

Reading is a subscription: the treadmill pushes notifications and you decode the bytes into speed, distance, time, calories. The decoding has to match the characteristic's data layout exactly.
Writing is a control request: you send a command to set speed or incline. Many machines require a "take control" handshake before they accept commands, and you have to respect their allowed ranges.

Lessons from talking to hardware

Assume the spec is a suggestion. Real devices deviate. Log raw packets and be defensive when decoding.
Make the state machine explicit. Scanning, connecting, connected, reconnecting - model them directly instead of juggling booleans.
Never trust the connection. Design for the treadmill vanishing mid-run; recover gracefully instead of hanging.
Keep the UI responsive during BLE work. Connection and discovery are async; the interface should always show what's happening.

Takeaways

BLE hardware apps are less about the flashy UI and more about robust connection handling and correct byte decoding. Get the state machine and the parsing right and the rest is easy.

The app is at https://treadmillpro.app

If you've worked with CoreBluetooth or FTMS, I'm curious how you handle devices that ignore the standard - do you maintain per-device quirks, or try to stay generic?

Rendering a live 3D earthquake globe on iOS from the USGS feed

Admin Supafast — Mon, 10 Aug 2026 15:53:44 +0000

I wanted to see earthquakes the way they actually happen: as points lighting up on a spinning planet, in near real time. That became Earthquake: Live Seismic Monitor, an iOS app that renders a 3D globe of recent quakes straight from the USGS feed. No backend of my own - just the public data and the device. Here's how it comes together.

The data source

The USGS publishes earthquake data as GeoJSON feeds, updated continuously, at several time/magnitude cutoffs (past hour, past day, 2.5+, 4.5+, etc). Each feature has coordinates, magnitude, depth and time. That's everything you need to place a quake on a globe - no custom API required.

The app polls the appropriate feed, diffs against what it already has, and updates the scene. Because USGS does the heavy lifting, the whole thing is effectively serverless from my side.

Putting quakes on a globe

The core mapping problem is turning (latitude, longitude) into a point on a sphere. Once you have that, each earthquake becomes a marker whose size and color encode magnitude and depth, so a glance tells you "big and shallow" vs "small and deep".

Design decisions that mattered:

Encode magnitude visually. Radius and color do more than any label. A magnitude 6 should look like a magnitude 6.
Cluster sensibly. Active regions produce swarms; markers need to stay readable when dozens land in one area.
Keep the globe interactive. Rotate, zoom, tap a quake for details. It should feel like an object, not a chart.

Real-time without a server

Every network-dependent app has to answer: what happens offline, and how fresh is "live"? My rules:

Cache the last good feed so the globe still renders with no connection.
Refresh on foreground and on an interval, and show the data's own timestamp so "live" is honest.
Never block the UI on the network - render what you have, then update.

Why no backend

It's tempting to proxy the feed through your own server "for control". But USGS is reliable, public, and built for exactly this. Skipping a backend meant no servers to run, no scaling to worry about, and no place for me to introduce staleness. The device talks to the source directly.

Takeaways

Great public datasets (USGS here) can carry an entire app - look for them before building infrastructure.
Encode the important variable (magnitude) into shape and color, not text.
Be honest about "real time": show the source timestamp instead of implying instant.

The app is at https://earthquakes.site

If you've built globe or map visualizations, I'd love to hear how you handle dense clusters of points without the map turning to mush.

Generating daily horoscopes and zodiac videos with an automated AI pipeline

Admin Supafast — Mon, 10 Aug 2026 15:47:33 +0000

Astrology content has a brutal property: it has to be fresh every single day, for every sign, ideally in a few languages, forever. Writing that by hand doesn't scale. For AstroZodify I built a pipeline that generates daily horoscopes and short zodiac videos on a schedule, with humans reviewing rather than writing. Here's the shape of it.

The content problem

Per day you need: 12 signs x N content types (daily horoscope, love, career) x M languages. That's hundreds of pieces of copy a day that all have to feel written, not templated, and stay consistent with each sign's "voice".

Templating alone reads robotic. Free-form generation drifts. The trick is constraining an LLM enough to stay on-brand while still sounding human.

The generation pipeline

Structured prompts per sign. Each sign has a persona and constraints (tone, themes, length). The model fills the daily specifics, not the whole thing from scratch.
Scheduled batch runs. A cron job kicks off generation ahead of time so content is ready before it's needed, never on the critical path of a page request.
Validation. Output is checked for length, banned phrasing, and structure before it's allowed near the site.
Store, then serve. Everything lands in Postgres. Pages are SSR and just read pre-generated rows, so the LLM is never in the user's request path.

Keeping generation offline from serving is the single most important decision - it keeps pages fast and costs predictable.

Adding video

Text was step one. Short vertical zodiac videos (for social) are step two, and that's a heavier pipeline: script -> imagery -> voiceover -> render. That part runs on Cloud Run as a separate job so a slow render never touches the web app, and we pilot one item before any batch.

Cost and safety rails

Anything that calls a paid API in a loop is a footgun. The rules I follow:

Always pilot on 1-10 items before a full batch.
Never an unbounded loop against a paid API.
Cache and pre-generate so serving is basically free.

Takeaways

Separate generation from serving. Pre-generate on a schedule, serve static rows.
Constrain the model with per-entity personas instead of free-form prompts.
Treat video as its own isolated pipeline, not an extension of the text one.

You can see the output at https://astrozodify.com

If you're generating large volumes of scheduled content, I'd love to compare notes on validation - how do you catch a bad generation before it ships?

Building an AI translator that lives everywhere on macOS, iOS and Chrome

Admin Supafast — Mon, 10 Aug 2026 15:43:24 +0000

Most translation tools make you leave what you're doing: copy text, switch to a tab or app, paste, read, copy back. I wanted translation to sit inside whatever I was already using. That turned into Linguin, an AI translator with a native Mac app, an iPhone app, and a Chrome extension. Here's how I think about building the "same" product across three very different surfaces.

One idea, three surfaces

The product promise is identical everywhere: select text, get a fast, context-aware translation in 100+ languages. But the interaction has to be native to each platform, or it feels wrong:

macOS: a menu-bar app plus a global hotkey. Select text anywhere, hit the shortcut, get an overlay. The whole point is that you never switch apps.
iOS: a share-sheet extension and keyboard, so translation is one tap from any app instead of a context switch to a separate screen.
Chrome: an extension that translates selections and full pages in place, keeping layout intact.

Same core, three genuinely different UX shells.

Keeping the core in one place

The translation logic - language detection, prompt construction, tone handling, caching - is the part you never want to fork. If Mac and iOS drift, you get subtly different translations for the same input, which erodes trust fast.

So the model-facing logic lives behind one small service contract, and each client is a thin shell that owns only its platform UX. A translation request looks the same whether it comes from the menu bar, the share sheet, or a browser selection.

Why "AI" translation instead of a classic API

Classic MT is great at literal accuracy but blind to context. "Book" in a travel app and "book" in a library app should not translate the same way. Passing the surrounding context and a tone hint (formal, casual, technical) to an LLM produces translations that read like a human wrote them, not a dictionary.

The tradeoffs I had to design around:

Latency: users expect near-instant results, so caching and streaming matter a lot.
Consistency: same input should give the same output, so requests are normalized and cached aggressively.
Cost: batching and caching keep per-translation cost sane.

Lessons so far

Ship the platform-native interaction first. A technically perfect translation behind a clunky flow loses to a decent translation that's one keystroke away.
Centralize the model logic early, before the clients diverge.
Context and tone are where AI translation actually beats the old tools - lean into that, not raw language count.

If you want to try it, the Mac app, iOS app and Chrome extension are all at https://linguin.app

Curious how others structure a shared core across native + web clients - do you go with a shared service, a shared package, or just accept some duplication?

How I track whether ChatGPT, Claude and Perplexity recommend my product

Admin Supafast — Mon, 10 Aug 2026 15:41:37 +0000

When people look for software today, a growing share of them never touch Google. They ask ChatGPT, Claude, Perplexity or Gemini "what's the best tool for X?" and take the answer at face value. If your product isn't in that answer, you're invisible to those users, and you have no idea it's happening.

I kept running into this with our own products, so I built AskAiRank to measure it. This post is about the problem and how the tracking actually works under the hood.

The problem: AI answers are a black box

Classic SEO gives you rank trackers, Search Console, backlinks. For AI assistants there's almost nothing. You can't see:

Whether a model mentions your brand when asked about your category
Where you land relative to competitors in that answer
Which sources the model cites to justify its recommendation

And the answers aren't deterministic. Ask the same question twice and you can get different tools, different ordering, different citations. So a single manual check tells you nothing, you need to sample over time.

How the tracking works

The core loop is simple:

Prompts. You define a set of buyer-intent prompts for your category, e.g. "best AI translation app for Mac" or "tools to monitor earthquakes".
Run across models. Each prompt is sent to ChatGPT, Claude, Perplexity and Gemini on a schedule, so we sample the distribution rather than a single roll.
Parse the response. For each answer we extract brand mentions, their position in the list, sentiment, and any cited source URLs.
Score and compare. Mentions and positions roll up into a visibility score per model, and you can add competitors to see share of voice.
Alert on drift. When your visibility drops or a competitor overtakes you, you get notified.

The parsing is the hard part. Model output is prose, not JSON, so mention detection has to handle aliases, partial names, "also worth checking out X" asides, and citations that live in footnotes or inline links. It's the piece I'm still iterating on the most.

Stack

Nothing exotic:

Next.js frontend
Self-hosted Postgres + PostgREST for data and API
Python workers that call the four model APIs and do the parsing/scoring
Scheduled runs so the sampling happens without anyone clicking a button

Why this matters (AEO / GEO)

People are starting to call this AEO (Answer Engine Optimization) or GEO (Generative Engine Optimization). The name matters less than the shift: recommendation is moving from ranked blue links to a single synthesized answer. If you ship a product, it's worth knowing where you stand in that answer, the same way you'd check your Google rank.

If you want to try it on your own product, there's a free plan (no credit card): https://askairank.com

I'd genuinely love feedback, especially from anyone who has tackled mention-detection in free-form LLM output. Where does your approach break?