SessionHQ replaces the spreadsheets, paper sign-in sheets, and duct-taped Mindbody workarounds that most small studios tolerate because the alternatives are too expensive, too clunky, or too generic. We built it by sitting at the front desk on a Tuesday night and asking, “what actually needs to happen here?”
The answer, it turns out, is:
No per-member fees. No transaction surcharges on top of Square. One flat monthly subscription.
SessionHQ is a serious piece of software infrastructure. A quick tour of the stack:
auth_tenant_id() at the database layer — a studio cannot see another studio’s data, period.Multi-tenancy, GDPR-readiness (consent capture, data export, right-to-erasure, full audit trail), idempotency, rate limiting, feature flags — all in from day one, not bolted on later.
We have spent 20+ years building software for other people. SessionHQ is different: it is our product. We own the roadmap, the pricing, the customer relationship. We decide which features matter. We eat the bug reports.
It is also a proof point. We believe small businesses deserve software that is as thoughtfully engineered as anything the enterprise market gets — without the enterprise price tag, the 12-month implementation, or the 400-page MSA. SessionHQ is our demonstration that a small, focused team can ship serious SaaS.
SessionHQ did not launch in a vacuum. It launched with a customer.
Havana on the Hastings is Port Macquarie’s Latin dance community — Cuban salsa, bachata, urban kiz, and rueda (the dance that brought founders Mike and Kellie together). They run on passes, practicas, and real connection, with the warmth of a studio where “everyone starts somewhere” is not just a slogan but a weekly reality.
They were already operating on the pass system that SessionHQ is built around. Partnering with them meant we did not have to guess what studio operators needed — we had one telling us, in real time, what worked and what did not. Every feature in SessionHQ has been stress-tested at their front desk on a Tuesday night.
If you are in Port Macquarie and want to dance, drop in. Absolute beginners are welcome every week.
SessionHQ is onboarding new studios now. If you run a dance studio, gym, yoga or pilates studio, martial arts school, or climbing gym — or if you know someone who does — we would love to talk.
info@sessionhq.org.This is the start of something we are going to spend years building on. Thanks for being here for the beginning.
]]>stamp-scanner — a two-device workflow for cataloguing stamp collections. The iPhone acts as a tethered macro scanner. The Mac runs SAM 3 segmentation, perceptual-hash deduplication, rotation correction, and a local Qwen3-VL for identification. Everything lives in a queryable SQLite library you can point external tools at.
iPhone (ios-app/) Mac (mac-app/) Python (tools/)
┌───────────────────┐ HTTP over ┌───────────────────┐ file ┌─────────────────┐
│ Capture (HEIC) ├───LAN+Bonjour─▶│ PhoneIngestServer ├──drop───▶│ sam_worker.py │
│ MotionGate │ │ (accepts uploads) │ │ SAM 3 + dedup │
│ Lens picker │ └───────────────────┘ │ + white balance │
└───────────────────┘ │ └────────┬────────┘
│ │ writes
▼ ▼
┌────────────────────┐ ┌─────────────────────┐
│ SwiftUI library UI │◀──GRDB──│ library.sqlite │
│ grid · detail │ │ (~/Library/App Sup) │
│ rotate · identify │ └──────────▲──────────┘
│ colnect lookup │ │ writes
└────────────────────┘ │
│ spawns │
▼ │
┌────────────────────┐ │
│ orientation_worker │───── Ollama ───────┤
│ (Qwen3-VL) │ │
│ colnect_lookup.py │───── HTTP ─────────┘
└────────────────────┘
MotionGate waits for the phone to be steady (accelerometer settled) before taking the shot, the lens picker selects the macro-capable camera, and the captured HEIC is uploaded over Bonjour/LAN to the paired Mac.PhoneIngestServer — a SwiftUI app wrapping a tiny HTTP listener — drops the file into .run/sam_inbox/.sam_worker.py runs the Segment Anything 3 model to cut the stamp out of the page, perceptual-hashes it to detect duplicates already in the library, warps it square, and white-balances against the untouched corners of the page.library.sqlite via a GRDB schema.orientation_worker against a local Ollama-hosted Qwen3-VL instance. Hitting “Colnect lookup” queries the Colnect catalogue API for an official ID match.Because an iPhone’s macro camera + image signal processor is genuinely excellent at stamp-sized subjects — better than a flatbed scanner at 1200 dpi for small dense subjects, and much faster. A Mac, meanwhile, is the right place for the heavy lifting: SAM 3 wants a GPU, the local VLM wants 20 GB of unified memory, and GRDB + SwiftUI want a real filesystem and a large screen. Splitting capture from processing plays to each device’s strengths.
A stamp collection is personal. You do not want to upload it to a third-party cataloguing service that might vanish in two years or quietly start charging a subscription. Local models, local SQLite, local UI. The only optional outbound call is the Colnect catalogue API, and that is a lookup against their public IDs — no collection data leaves your Mac.
Working end-to-end for single-subject captures, deduplication, rotation, and VLM-based identification. Full architecture and build instructions in the README. If you have a collection that deserves better than a spreadsheet, this is a solid starting point.
]]>bike-shock-planner — a test-driven, code-as-data planner for mountain bike rear shock replacements, coil conversions, and ebike suspension builds. It began as “can I fit a coil shock to a 2013 Trek Fuel EX 5 ebike conversion?” and grew into a reusable framework that models rear suspension geometry, shock fitment, spring rates, frame clearance, conversion hardware, and global sourcing paths for any bike.
The 2013 Fuel EX 5 is the first “recipe” — a self-contained config describing one bike, one rider, and a set of candidate parts. Everything is written so you can drop in a new recipe for your own frame and the same fit-check and spring-rate logic runs against it. That is the whole point of the project: a single, testable model of rear-shock dimensions and fitment rules, with as many recipes layered on top as people are willing to contribute.
Primarily a 2013 Trek Fuel EX 5 model. The coil catalog includes Push ElevenSix (the only currently-buildable imperial 7.25×2.0 coil in April 2026), plus Marzocchi Bomber CR, Fox DHX2, DVO Jade X, MRP Hazzard Coil, and Cane Creek DB Coil IL entries marked used-market-only. The air catalog includes Fox Float X2, RockShox Super Deluxe Ultimate, and Marzocchi Bomber Air. Real VALT Progressive sizes are captured with the 45 mm stroke that fits inside a 50 mm shock; Sprindex 55 mm is flagged as not-fitting. The conversion kit catalog covers Offset Bushings, Shockcraft Deaktiv, an unpublished custom-machine path for Huber Bushings, plus a speculative metric-to-Trek kit flagged publishedSku: false so the test suite warns on it.
Because every existing shock “compatibility chart” is a PDF, and PDFs cannot be run against a test suite. If you model the data in TypeScript, the test suite can assert things like “no reservoir clash on any frame in the catalog”, “every link in the research library is reachable”, and “every catalog entry has a spring rate range if it is a coil”. That turns a messy research task into something a contributor can submit a pull request against. Source on GitHub.
]]>clean-backdrop — a free, open-source tool for cleaning up studio portrait backdrops. Shadow lift plus frequency separation on a high-quality portrait segmentation mask, running on a CUDA GPU, no AI inpainting artifacts anywhere. It is a clean-math alternative to paid tools like Retouch4me Clean Backdrop.
Studio paper backdrops are never as clean as they look before the shoot. A six-hour session leaves scuff marks, footprints, seam shadows where the paper meets the floor, uneven lighting where the key light rolled off, and the occasional crease from the roll dispenser. Fixing those by hand in Photoshop — with the healing brush, dodge/burn layers, and a feathered mask around the subject — is a real job. For a shoot with two hundred keepers, it is unreasonable.
The commercial tools that automate this are excellent and expensive. clean-backdrop is the free alternative.
Two complementary techniques, run on GPU:
Both passes run on a BiRefNet-Portrait subject segmentation mask with distance-based feathering, so the boundary between subject and cleaned background has no visible “bar” artifact at any crop size.
There are two ways to use it:
# Web UI — drag-and-drop with live sliders
pip install -r requirements.txt
python app.py
# open http://localhost:5000
# Batch — directory in, directory out
python batch.py "D:\Photos\Export\My Shoot" --lift 70 --texture 50
The web UI shows four tabs — Original, Shadows, Texture, Preview — so you can dial shadow lift and texture smoothing independently and watch the separation happen. Outputs are saved next to the original with a _clean suffix, ICC colour profiles and EXIF metadata preserved.
Because the underlying math is not exotic — shadow lift and frequency separation have been in the photo-retouching toolkit for twenty years — and because a high-quality portrait segmentation model exists under a permissive licence. The commercial offerings are polished, but the core workflow does not need to be proprietary. If you shoot regularly against studio paper, clone the repo and stop paying a per-seat fee for a batch operation.
]]>ledger — a terminal-first personal finance tool that ingests bank statements from multiple Australian banks, categorises transactions with regex-based rules, and renders an ATO-ready tax return view plus a net worth dashboard. Local-first, SQLite under the hood, no cloud dependency.
Every mid-year I rebuild the same Excel spreadsheet: paste in ING transactions, paste in PayPal, paste in the Bankwest credit card, then hand-categorise everything, then try to remember which expense was for which business, then double-count a $200 transaction that appeared on both the credit card and the bank account it was paid from. Then I hand it to my accountant and we do it all over again. Ledger is the version I should have built five years ago.
| Source | Formats | Parser |
|---|---|---|
| ING Australia | PDF statements, CSV export | etl/parsers/ing_pdf.py, ing_csv.py |
| PayPal | CSV activity download | etl/parsers/paypal_csv.py |
| Bankwest | PDF eStatements, CSV | etl/parsers/bankwest_pdf.py, bankwest_csv.py |
| HSBC | PDF statements | etl/parsers/hsbc_pdf.py |
| Coles Mastercard | PDF statements | etl/parsers/coles_pdf.py |
| Amex | CSV download | etl/parsers/amex_csv.py |
Drop a statement into staging/<source>/, run ledger ingest, and the right parser picks it up. PDF parsing is per-bank because every Australian bank has a different statement layout and none of them offer a clean machine-readable export.
flight, biz-hosting, rental-income for finer reporting without having to invent a deeper category tree.Because my financial data is mine. No cloud dependency, no third-party aggregator pulling read-only access to my bank accounts, no “we are deprecating the Xero integration” email six months from now. SQLite sits in a folder, the dashboard runs on localhost, and if I want to back it all up I copy a single file.
git clone https://github.com/isaacrowntree/ledger.git
cd ledger
python3 -m venv .venv && source .venv/bin/activate
pip install -e .
cp config/accounts.yaml.example config/accounts.yaml
cp config/categories.yaml.example config/categories.yaml
cp config/tax.yaml.example config/tax.yaml
ledger init
mkdir -p staging/ing staging/paypal
# Drop PDFs/CSVs into those folders
ledger ingest
python -m api
# Open http://localhost:5050
Anyone in Australia with more than one bank account, a side business or two, and an accountant who currently gets a hand-assembled spreadsheet every July. Source on GitHub.
]]>local-llm-coding-guide — a no-fluff, benchmark-driven guide to running a genuinely useful local LLM as a coding assistant on consumer hardware. It covers Qwen3.5 and Gemma 4 across llama.cpp, Ollama (with MLX), and vllm-mlx, with real tokens-per-second numbers from three real machines.
Cloud LLMs are wonderful until you are on a flight, behind a client VPN, editing code with sensitive data, or burning through a monthly token budget faster than is reasonable. The quality gap between the best frontier models and the best local-runnable models has narrowed dramatically — a quantised 9B Qwen model on a modest NVIDIA card is now perfectly capable of the “reformat this function, add a docstring, write a test” type of work that makes up most of a coding assistant’s day.
Measured on release builds, real completions, real contexts:
| GPU | Model | Tok/s | Context | Memory |
|---|---|---|---|---|
| RTX 4070 Ti 12GB | Nemotron 3 Nano 4B Q4_K_M | TBD | 262K | ~5GB |
| RTX 4070 Ti 12GB | Qwen3.5-9B Q4_K_M | ~65 | 131K | 7.8GB |
| RTX 3060 12GB | Qwen3.5-9B Q4_K_M | ~43 | 128K | ~7.8GB |
| RTX 3090 24GB | Qwen3.5-27B Q4_K_M | ~30 | 262K | ~18GB |
| M3 Pro 36GB | Qwen3.5-35B-A3B Q4_K_M | ~29 | 131K | ~22GB |
| M3 Pro 36GB | Qwen3.5-9B Q4_K_M | ~20 | 131K | ~7GB |
| M3 Pro 36GB | Qwen3.5-27B Q4_K_M | ~9* | 131K | ~18GB |
| M3 Pro 36GB | Gemma 4 26B-A4B Q4_K_M (Ollama MLX) | ~31 | 256K | ~17GB |
*The dense 27B is slower than the 35B-A3B MoE on 36 GB machines — see “Why MoE?” in the repo for the full story.
Apple’s unified memory is generous but its memory bandwidth is not as high as a discrete NVIDIA card’s. A dense 27B model saturates that bandwidth on every token. A mixture-of-experts model like Qwen3.5-35B-A3B only activates 3B parameters per token, which means each token reads a fraction of the weights — and the model runs faster and smarter than the dense option it replaces. The guide walks through the tradeoff properly.
The guide walks through llama.cpp from source (with -DGGML_CUDA=ON or -DGGML_METAL=ON), the llama-server binary, wiring it into VS Code via the Continue extension, and wiring it into Claude Code as a local endpoint. Ollama + MLX is covered as the one-command alternative for Apple Silicon.
Developers who want a serious coding assistant that runs on their own hardware, without a subscription, without a round-trip to a cloud inference endpoint, and without hand-tuning flags for six hours. Read it on GitHub.
]]>audio-analysis-and-recut — a small Python + FFmpeg pipeline that takes a noisy live performance recording, works out exactly which sections of the original studio track the band played, and generates a high-fidelity recut that follows the live arrangement.
You have two audio files:
The live arrangement is better — it is the one the band actually performed — but the audio fidelity is worse. What you want is: the live arrangement, with studio fidelity. That is what this tool does.
For “Ya Te Olvide” by Los 4 ft Laritza Bacallao (4:40 studio original → 1:56 live performance):
SEGMENT MAP:
1 0:00-0:19 | Orig 0:12-0:30 | 18.5s (intro/verse start)
2 0:19-1:04 | Orig 0:50-1:35 | 44.5s (verse/chorus)
3 1:04-1:36 | Orig 2:44-3:15 | 31.5s (montuno section)
4 1:36-1:46 | Orig 4:13-4:23 | 9.5s (ending)
5 1:46-1:48 | Orig 4:33-4:35 | 2.0s (final tag)
Skipped from original:
0:00-0:12 (11.8s) - pre-intro
0:30-0:50 (20.1s) - transition/repeat
1:35-2:44 (69.1s) - repeated verse section
3:15-4:13 (57.9s) - extended montuno/breakdown
4:23-4:33 (10.3s) - outro padding
The segment map reads like a director’s cut list: the band skipped the pre-intro, compressed the long breakdown, and landed on a different ending. Feeding that back into FFmpeg reconstructs the performance from clean studio audio.
Latin dance classes like Havana on the Hastings often rehearse to studio recordings but perform to the band’s own arrangement — which means choreographies that work in rehearsal do not always align with the live record they are showcased against. A recut reconciles the two: same arrangement the dancers know, but clean enough to cue on.
cp original_song.mp3 staging/original.mp3
cp performance_recording.mp3 staging/performance.mp3
python3 analyze.py
# Output: output/ya_te_olvide_recut.mp3
Dependencies are Python 3 with NumPy, plus a working FFmpeg on $PATH. Source on GitHub.
react-native-nitro-unzip — a high-performance ZIP module for React Native, built on Nitro Modules. It extracts and creates password-protected archives on iOS and Android faster than the existing community options, with real progress callbacks and cancellation delivered directly over JSI rather than the old bridge.
On a 350 MB archive containing 10,000 files:
Those numbers are measured with release builds, not debug — the bridge-free JSI path is a large part of why the difference shows up at all.
UIApplication background task management, so a 500 MB archive can finish extracting even if the user backgrounds the app.import { getUnzip } from 'react-native-nitro-unzip';
const unzip = getUnzip();
const task = unzip.extract('/path/to/archive.zip', '/path/to/output');
task.onProgress((p) => {
console.log(`${(p.progress * 100).toFixed(0)}% — ${p.extractedFiles}/${p.totalFiles} files`);
});
const result = await task.await();
console.log(`Extracted ${result.extractedFiles} files in ${result.duration}ms`);
Progress callbacks fire on every file, and because they ride JSI they never queue up behind the bridge.
React Native has had ZIP libraries for years. Most of them predate Nitro and therefore predate modern JSI — which means every progress tick had to serialise across the bridge, every cancellation had to round-trip through an async message queue, and every archive operation paid the bridge tax proportional to the number of files. For the kind of app that extracts a single 2 MB archive at install time, none of that matters. For the kind of app that handles large user-uploaded archives, downloads payload bundles from a server, or packages up content for offline use, it matters a lot.
Internally the native side leans on battle-tested libraries — SSZipArchive on iOS, an optimised ZipInputStream path on Android — rather than reinventing the compression format. The contribution is the JSI layer, the cancellation machinery, and the progress plumbing that sits on top.
npm install react-native-nitro-unzip react-native-nitro-modules
cd ios && pod install
Requires React Native 0.75+, Nitro Modules 0.34+, iOS 15.5+, and Java 17 on Android. Full docs — including extraction, compression, password handling, cancellation semantics, and the API reference auto-generated from TypeScript — live at isaacrowntree.github.io/react-native-nitro-unzip.
Source on GitHub.
]]>claude-social-skills — a Claude Code plugin marketplace bundling three genuinely useful capabilities into a single install. No MCP servers, no background daemons — just Python scripts plus SKILL.md files that teach Claude how to use them.
| Plugin | What it does |
|---|---|
| social-post | Post to Twitter/X, Reddit, Facebook Pages, and Instagram Business/Creator accounts |
| ebay-listing | List items for sale on eBay — title, description, photos, pricing, shipping |
| himalaya-email | Read, send, and manage email using the excellent Himalaya CLI |
Each plugin is a self-contained directory with its own skill definition, scripts, and dependency list. Install only what you need.
Inside Claude Code:
/plugin marketplace add isaacrowntree/claude-social-skills
/plugin install social-post@social-skills
/plugin install ebay-listing@social-skills
/plugin install himalaya-email@social-skills
social-post wraps four very different APIs behind a uniform skill surface. Credentials are exported as environment variables (Twitter API keys, Reddit client ID/secret, Facebook Page token, Instagram Business token), and the skill tells Claude which ones are required for which platform.
You can ask Claude things like:
Post this to Reddit r/programming: “Check out this tool…”
Share on Twitter and Reddit: “Big announcement…”
And it figures out the right endpoints, handles the rate limits, and reports back with the posted URLs. Under the hood, each platform is a ~100-line Python script, so nothing is magic — you can run python3 scripts/tweet.py "Hello world" directly if you want.
Listing on eBay through their API is finicky: item specifics, shipping policies, photos, tax categories, return policies, payment profiles. The skill defines a structured JSON shape for “a listing” and hands Claude enough context to map a rough human description (“I’ve got a 2022 Shimano derailleur, barely used, want $80”) into a valid eBay payload.
Himalaya is a terminal-native email client that speaks IMAP, SMTP, Maildir, and Notmuch. Wrapping it in a skill means Claude can triage, summarise, reply, and draft email the same way a human would — without Yet Another OAuth dance or a bespoke Gmail integration that breaks on IMAP-only accounts.
I experimented with full-blown MCP servers for these capabilities and ended up preferring the scripts-plus-skill approach: zero extra processes, zero ports to manage, and the underlying scripts stay runnable by a human on the CLI. Every credential is whatever the underlying service hands you — Twitter developer tokens, Reddit app credentials, Facebook Graph tokens, IMAP passwords in your keychain — stored however you already store them.
If you run Claude Code and you want to turn it into a genuinely useful operator for your daily online life, install the marketplace and pick the skills you actually use.
]]>deflicker-runner — a Python pipeline for removing the subtle but maddening LED flicker that rolling-shutter cameras capture when shooting under overhead LED panels. It runs on arbitrarily long 4K footage in about 400 MB of RAM, which is the interesting part.
LED panels do not emit light continuously. They pulse at 100 Hz (50 Hz mains, rectified to both halves). A rolling-shutter sensor at 59.94 fps captures a slightly different slice of that pulse train per frame — and the beat frequency between the two lands right around 20 Hz. The result is a ~2% whole-frame brightness oscillation, which is small enough to miss on set and loud enough to ruin the footage in post.
Two flavours show up in real shoots:
deflicker-runner ships a handful of modes, each suited to a different failure:
| Approach | Best for | How it works |
|---|---|---|
temporal-median |
Whole-frame LED flicker | Per-pixel temporal median at 540p, upscaled back to 4K. Eliminates the 3-frame cycle entirely. |
spot-replace |
Small filament bulbs | Full-resolution detection of bright flickering spots, then per-box temporal median replacement. |
running-mean |
General purpose | Per-row running temporal mean baseline. Good balance of speed and quality. |
pixel-smooth |
Motion-preserving | Per-pixel BCC-style weighted average that respects motion. |
fft-notch |
Precise frequency removal | FFT notch at the exact LED beat frequency (~19.88 Hz). Subtle ~2% correction. |
physical-model |
Physics-based | Fits the LED waveform and rolling-shutter timing model. Most theoretically correct. |
global-row |
Global brightness variation | Two-stage: global normalisation plus per-row residual. |
For most footage, auto picks the right mode for you. temporal-median is the default recommendation.
A 4K frame is 8 MB raw. Naively running temporal median on a full-length clip means holding hundreds of frames in RAM at once. The runner sidesteps that by:
The result is a deflicker pass that runs happily on a laptop, not a workstation, and handles a full talk recording without ever buffering the whole thing into RAM.
LED flicker is one of those problems that is unsolvable in a single ffmpeg filter — none of the stock filters know about the beat frequency, and none of them can route different correction strategies at different scales. A small, focused Python tool makes the tradeoffs explicit and gives a colourist or editor an honest knob to turn. Source on GitHub.