Hi HN,
I built Ayder — a single-binary, HTTP-native durable event log written in C. The wedge is simple: curl is the client (no JVM, no ZooKeeper, no thick client libs).
There’s a 2-minute demo that starts with an unclean SIGKILL, then restarts and verifies offsets + data are still there.
Numbers (3-node Raft, real network, sync-majority writes, 64B payload): ~50K msg/s sustained (wrk2 @ 50K req/s), client P99 ~3.46ms. Crash recovery after SIGKILL is ~40–50s with ~8M offsets.
Repo link has the video, benchmarks, and quick start. I’m looking for a few early design partners (any event ingestion/streaming workload).
by wkcollis1 ·
Hi HN — I’m sharing an empirical, long-term dataset from a DIY energy-storage project that ended up testing a common assumption in battery design.
Conventional advice says never mix battery brands. That guidance is well-founded for series strings, but there’s surprisingly little data on purely parallel configurations.
I built a 12 V, 500 Ah LiFePO₄ battery bank (1S5P) using mixed-brand cells and instrumented it for continuous monitoring over 73+ days, including high-frequency voltage sampling. The goal was to see whether cell-level differences actually manifest over time in a parallel topology.
What the data shows
No progressive voltage divergence across the observation period
Voltage spread remained within ~10–15 mV
Measured Peukert exponent ≈ 1.00
Thermal effects were small relative to instrumentation noise
In practice, the parallel architecture appears to force electrical convergence when interconnect resistance is low. I’ve been referring to this as “architectural immunity” — the idea that topology can dominate cell-level mismatch under specific conditions.
This is not a recommendation to mix batteries casually, and it’s not a safety guarantee. It’s an attempt to replace folklore with measurements and to define the boundary conditions where this does or does not hold.
Everything is public:
Raw CSV data
Analysis scripts
Full PDF report
Replication protocol
Repo: https://github.com/wkcollis1-eng/Lifepo4-Battery-Banks
I’m posting this to invite critique — especially around failure modes, instrumentation limits, or cases where this model would break down (e.g., higher C-rates, aging asymmetry, thermal gradients, different chemistries).
Happy to answer technical questions.
I’ve been building and selling software since the early 2000s, starting with classic shareware. In 2011, I moved into the App Store world and built an iOS budget app because I needed a simple way to track my own expenses.
At the time, my plan was to replace a few larger shareware projects with several smaller apps to spread the risk. That didn’t quite work out — one app, MoneyControl, quickly grew so much that it became my main focus.
Fifteen years later, the app is still on the App Store, still actively developed, and still used by people who started with version 1.0. Many apps from that era are long gone.
Looking back, these are some of the things that mattered most:
Starting early helped, but wasn’t enough on its own. Early visibility made a difference, but long-term maintenance and reliability are what kept users.
Focus beat diversification. I wanted many small apps. I ended up with one large, long-lived product. Deep focus turned out to be more sustainable.
Long-term maintenance is most of the work. Adapting to new iOS versions, migrating data safely, handling edge cases, and keeping old data usable mattered more than flashy features.
Discoverability keeps getting harder. Reaching users on the App Store today is much more difficult than it was years ago. Prices are higher than in the old 99-cent days, but visibility hasn’t improved.
I’m a developer first, not a marketer. I work alone, with occasional help from freelancers. No employees, no growth team. The app could probably have grown more with better marketing, but that was never my strength.
You don’t need to get rich to build something sustainable. I didn’t build this for an exit. I’ve been able to make a living from my work for over 20 years, which feels like success to me.
Building things you actually use keeps you honest. Every product I built was something I personally needed. That authenticity mattered more than any roadmap.
This week I released version 10 with a new design and a major technical overhaul. It feels less like a milestone and more like preparing the app for the next phase.
Happy to answer questions about long-term app maintenance, indie development, or keeping a product alive across many iOS generations.
Hi HN, I’m the creator of SnackBase.
I built this because I work in Healthcare and Life Sciences domain and was tired of spending months building the same "compliant" infrastructure (Audit Logs, Row-Level Security, PII Masking, Auth) before writing any actual product code.
The Problem: Existing BaaS tools (Supabase, Appwrite) are amazing, but they are hard to validate for GxP (FDA regulations) and often force you into a JS/Go ecosystem. I wanted something native to the Python tools I already use.
The Solution: SnackBase is a self-hosted Python (FastAPI + SQLAlchemy) backend that includes:
Compliance Core: Immutable audit logs with blockchain-style hashing (prev_hash) for integrity.
Native Python Hooks: You can write business logic in pure Python (no webhooks or JS runtimes required).
Clean Architecture: Strict separation of layers. No business logic in the API routes.
The Stack:
Python 3.12 + FastAPI
SQLAlchemy 2.0 (Async)
React 19 (Admin UI)
Links:
Live Demo: https://demo.snackbase.dev
Repo: https://github.com/lalitgehani/snackbase
The demo resets every hour. I’d love feedback on the DSL implementation or the audit logging approach.
Hi! I've built this because I kept reaching for Celery for simple scheduled tasks and it felt like overkill. I just needed "run this function every hour" or "daily at 9am", not distributed workers.
So it's decorators for scheduling (@scheduler.every(5).minutes, @scheduler.daily.at("09:00")), state saves to JSON so jobs survive restarts, and there's an optional FastAPI dashboard if you want to see what's running.
No Redis, no message broker, runs in-process with your app. Trade-off is it's single process only — if you need distributed workers, stick with Celery.
Hey HN! We’re Will and Jorge, and we’ve built LAD (Language-Aided Design), a SolidWorks add-in that uses LLMs to create sketches, features, assemblies, and macros from conversational inputs (https://www.trylad.com/).
We come from software engineering backgrounds where tools like Claude Code and Cursor have come to dominate, but when poking around CAD systems a few months back we realized there's no way to go from a text prompt input to a modeling output in any of the major CAD systems. In our testing, the LLMs aren't as good at making 3D objects as they are are writing code, but we think they'll get a lot better in the upcoming months and years.
To bridge this gap, we've created LAD, an add-in in SolidWorks to turn conversational input and uploaded documents/images into parts, assemblies, and macros. It includes:
- Dozens of tools the LLM can call to create sketches, features, and other objects in parts.
- Assembly tools the LLM can call to turn parts into assemblies.
- File system tools the LLM can use to create, save, search, and read SolidWorks files and documentation.
- Macro writing/running tools plus a SolidWorks API documentation search so the LLM can use macros.
- Automatic screenshots and feature tree parsing to provide the LLM context on the current state.
- Checkpointing to roll back unwanted edits and permissioning to determine which commands wait for user permission.
You can try LAD at https://www.trylad.com/ and let us know what features would make it more useful for your work. To be honest, the LLMs aren't great at CAD right now, but we're mostly curious to hear if people would want and use this if it worked well.
Yooo!
Papercuts lets you deploy AI agents that flow through your production app like a real user. Just provide a URL and get notified when something breaks.
Modern apps are way too complex for brittle selectors. Honestly, I think the only way to feel safe is to test in production with AI agents that actually perceive and navigate like a human.
I built this because with AI-assisted coding I spend much more time reading unfamiliar code than writing it.
The main friction was comments written in a non-native language: using external translators breaks focus, and many editor tools translate whole lines or buffers rather than actual comments.
This plugin uses Tree-sitter to detect comment nodes precisely and translates them inline on hover, so code reading stays uninterrupted.
Built this RSS aggregator based on the 2025 HN Popularity Contest rankings by Refactoring English [1]. If there's interest in other slices (top 10, top 200, etc.), happy to add them.