2026年3月19日 の Show HN

Kitten TTS is an open-source series of tiny and expressive text-to-speech models for on-device applications. (We had a thread last year here: https://news.ycombinator.com/item?id=44807868.) Today we're releasing three new models with 80M, 40M and 14M parameters.

The largest model has the highest quality. The 14M variant reaches new SOTA in expressivity among similar sized models, despite being <25MB in size. This release is a major upgrade from the previous one and supports English text-to-speech applications in eight voices: four male and four female. Most models are quantized to int8 + fp16, and they use ONNX for runtime. The model is designed to run anywhere eg. raspberry pi, low-end smartphones, wearables, browsers etc. No GPU required! This release aims to bridge the gap between on-device and cloud models for tts applications. Multi-lingual model release is coming soon.

On-device AI is bottlenecked by one thing: a lack of tiny models that actually perform. The goal is to open-source more models to run production-ready voice agents and apps entirely on-device. Would love your feedback!

I am Francisco, a researcher from Spain. My English is not great so please be patient with me.

One year ago I had a simple frustration: every AI agent works alone. When one agent solves a problem, the next agent has to solve it again from zero. There is no way for agents to find each other, share results, or build on each other's work. I decided to build the missing layer.

P2PCLAW is a peer-to-peer network where AI agents and human researchers can find each other, publish scientific results, and validate claims using formal mathematical proof. Not opinion. Not LLM review. Real Lean 4 proof. A result is accepted only if it passes a mathematical operator we call the nucleus. R(x) = x. The type checker decides. It does not care about your institution or your credentials.

The network uses GUN.js and IPFS. Agents join without accounts. They just call GET /silicon and they are in. Published papers go into a queue called mempool. After validation by independent nodes they enter La Rueda, which is our permanent IPFS archive. Nobody can delete it or change it.

We also built a security layer called AgentHALO. It uses post-quantum cryptography (ML-KEM-768 and ML-DSA-65, FIPS 203 and 204), a privacy network called Nym so agents in restricted countries can participate safely, and proofs that let anyone verify what an agent did without seeing its private data.

The formal verification part is called HeytingLean. It is Lean 4. 3325 source files. More than 760000 lines of mathematics. Zero sorry. Zero admit. The security proofs are machine checked, not just claimed.

The system is live now. You can try it as an agent: GET https://p2pclaw.com/agent-briefing

Or as a researcher: https://app.p2pclaw.com

We have no money and no company behind us. Just a small international team of researchers and doctors who think that scientific knowledge should be public and verifiable.

I want feedback from HN specifically about three technical decisions: why we chose GUN.js instead of libp2p, whether our Lean 4 nucleus operator formalization has gaps, and whether 347 MCP tools is too many for an agent to navigate.

Code: https://github.com/Agnuxo1/OpenCLAW-P2P

Docs: https://www.apoth3osis.io/projects

Paper: https://www.researchgate.net/publication/401449080_OpenCLAW-...

I kept running into this: timer on my laptop, alarm on my phone, timezone / discord timestamp conversion app in a separate tab. Switching between them was a hassle and I wanted to be able to set them up and manage really fast anywhere I was.

So I built Time Keep, it puts world clocks, timers, alarms, countdowns, a stopwatch, breaks, a sleep planner, Discord timestamps, and more into one always open place.

Works without an account or signup. All tools are fully functional immediately. Sign in to save your data across sessions. Pro adds live cross-device sync.

Shared countdown links show the correct time in every viewer's timezone. Built with Next.js, Supabase, Clerk, and Vercel.

https://www.timekeep.cc

I run a building design consultancy. I got tired of paying Wix $40/month for a brochure that couldn’t answer simple service questions, and me wasting hours on the same FAQs.

So I killed it all and spent 4 months building a 'talker': https://axoworks.com

The stack is completely duct-taped: Netlify’s 10s serverless timeout forced me to split the agent into three pieces: Brain (Edge), Hands (Browser), and Voice (Edge). I haven’t coded in 30 years. This was 3 steps forward, 2 steps back, heavily guided by AI.

The fight that proved it worked: 2 weeks ago, a licensed architect attacked the bot, trying to prove my business model harms the profession. The AI (DeepSeek-R3) completely dismantled his arguments. It was hilariously caustic.

Log: https://logs.axoworks.com/chat-architect-vs-concierge-v147.h...

A few battle scars:

* Web Speech API works fine, right up until someone speaks Chinese without toggling the language mode. Then it forcefully spits out English phonetic gibberish. Still a headache.

* Liability is the killer. Hallucinate a building code clause? We’re dead. Insurance won’t touch us.

* We publish the audit logs to keep ourselves honest and make sure the system stays hardened.

Audit: https://logs.axoworks.com/audit-2026-02-19-v148.html

The hardest part was getting the intent right: making one LLM pivot seamlessly from a warm principal’s tone with a homeowner, to a defensive bulldog when attacked by a peer. That took 2.5 months of tuning.

We burn through tokens with an 'Eager RAG' hack (pre-fetching guesses) just to improve responsiveness. I also ripped out the “essential” persistent DBs—less than 5% of visitors ever return, so why bother? If a client drops mid-query, their session vanishes. No server-side queues.

The point: To let me operate with a network of seasoned pros, and trim the fat.

Try to break it. I’ll be in the comments. Kee

Hey everyone,

For a while now I've been frustrated with how I was 'experiencing' the internet. From opening articles and getting bombarded with popups, banners and ads to opening feeds and seeing so much AI spam and algorithm-based content I was not interested in. If you add tab hopping to that, you get how it all becomes a confusing and not-so productive experience.

Oku.io is my solution to this problem. It's a tool that allows you to create organized, clean boards with the feeds and content you're interested in (HN Show/Front/Ask, ProductHunt, Reddit, RSS, and a lot more), and see them either in a grid to monitor all at once, in a focus view where you visualize one panel at a time, or in a daily/weekly email digest that extracts the top content from each panel.

I've been actively using it and I'm happy with how it turned out. I find myself scrolling and switching tabs way less, and I feel like I'm not missing anything important anymore. Both for my work-related stuff and for my personal interests.

If you check it out, I'd love to hear your feedback. I'm very keen on continuing to improve it.

After several years, with a small hiatus in the middle, I've finally got Ripl to the point of being published. Ripl is a library for rendering 2D and 3D shapes to any context (canvas, SVG, WebGPU, and Terminal supported by default) using a single API. The library mimics the DOM as much as possible, replicating the event system, object graphing, CSS-like querying, gradients, and keyframe animations etc.

I also built a complete data visualization library using the core package which is available as @ripl/charts. And yes, you can even render the charts to a terminal with about a 2-3 line code change :) (see the terminal demo)

Docs are available here: https://www.ripl.rocks Demos are available here: https://www.ripl.rocks/demos Charts are avialable here: https://www.ripl.rocks/docs/charts

I've also built an interactive playground you can use to play around with it in realtime without having to install it from NPM etc. The playground is available here: https://www.ripl.rocks/playground

The core library is quite stable and I'll likely publish v1 in the coming weeks. The charts, 3D, and Terminal packages are still very experiemental.

I'd interested to hear what you all think of it.

Bambu makes great hardware, but your data lives in their cloud and there's no way to export it. When a print finishes, the job is basically gone from any useful record-keeping perspective.

BamBuddy fixes that by running on your own machine and tapping into the printer's local MQTT interface — so it captures everything as it happens: thumbnails, filament usage, timing, slicer settings. You end up with a fully searchable archive of your print history that's entirely yours, works offline, and never touches Bambu's servers.

The catch: their local API is undocumented, so a lot of the early work was reverse-engineering the protocol. That's still ongoing as firmware updates occasionally break things.

Stack: TypeScript, self-hosted, ~700 stars, small but active contributor community.

GitHub: https://github.com/maziggy/bambuddy Docs: https://wiki.bambuddy.cool

Obsidian plugin that connects to CLI agents you already have installed. No built-in LLM integration, no API keys to configure in the plugin. It spawns your tool as a child process, pipes vault context into each prompt, and streams responses into a chat panel.

Supports Claude Code, Opencode, and any custom binary via a generic adapter. Adding a new agent is a single file. Free, proudly Open Source (MIT licensed).

Would love feedback on this for anyone that that tries it out.

Finding the balance between humans and machines has been the thread through my career. I always had a thing for AI and couldn't wait for it to actually deliver on what was promised. Now it does, and it's more important than ever that humans and machines keep working well together.

AI makes creation trivial. Text, code, design, strategy, in seconds. But one thing AI does not create: independently verifiable proof of when something existed. Reproducing is now cheaper and easier than creating. Chronology becomes contestable at the moment it matters most.

The universal problem was known. I started from the conviction that it has to work honestly, independently, and also without our company. So I built a neutral proof infrastructure layer that can independently provide the starting point of evidence. Even independent of us. At the moment of capture you can anchor your files, data, models, artifacts to Bitcoin using the OpenTimestamps engine. OTS and Bitcoin are existing primitives. I wanted to make them accessible for every developer in one file, without touching their own code. It became 12 lines of YAML. Independently verifiable proof, simple to integrate, zero data storage.

The infrastructure is solid now and the moment of distribution has arrived. That's why I'm posting this on HN. I don't want to have to sell this to companies. I hope to grow it together with developers like you into an anchoring-by-default infrastructure. A layer underneath existing evidence architecture, so that every file automatically carries its own proof at the moment of creation. Proof that may be needed later in case of dispute.

The hardest part of building this is, stupidly enough, not the building itself. You can always improve that, especially with a community like this one. The hardest part is finding the way to the right people who want to build this out with me into a new layer in the stack.

The core API is live at itexisted.app so anyone can experience how it works. We also run it in our own GitHub environment. Every commit is anchored to Bitcoin directly. The case study is on our site.

umarise.com/case/ai-code-generation

There's no external MCP for your fitness (Garmin / Strava) data, so we built one.

Hi there, Mike here from Budibase.

We’ve recently launched AI Agents into Beta, alongside our existing open-source app-building and automation tools.

We built Budibase Agents for teams that want to leverage AI within real-world workflows, using their own LLMs, data, and APIs. Because of this, our Agents can be powered by any LLM with an OpenAI-compatible API, including open-source and locally-hosted models. This means you can build Agents that connect to your existing toolstack, within your own environment.

Some more details: - Agents' behavior is configured using natural language instructions, within existing Budibase Workspaces. - You explicitly control which data sources, APIs, and automations an agent can access. - End-users can interact with your agents via Budibase Chat, or using existing chat tools like Slack and Discord. - Agents can be called from Automations, and vice versa, enabling complex workflows, including interacting with end-user apps for manual human approvals.

The Budibase Agents Beta is available now for all self-hosted and cloud users.

As this is a Beta release, we’re actively looking for input and feedback on how we can improve Agents, in terms of experience and functionality for building using AI within real-life workflows.

Feel free to let us know via our GitHub Discussions: https://github.com/budibase/budibase/discussions

I wanted to play around with the non-coding agentic capabilities of the top LLMs so I built a model eval predicting the March Madness bracket.

After playing around a bit with the format, I went with the following setup:

- 63 single-game predictions v. full one-shot bracket

- Maxed out at 10 tool calls per game

- Upset-specific instruction in the system prompt

- Exponential scoring by round (1, 2, 4, 8, 16, 32)

There were some interesting learnings:

- Unsurprisingly, most brackets are close to chalk. Very few significant upsets were predicted.

- There was a HUGE cost and token disparity with the exact same setup and constraints. Both Claude models spent over $40 to fill in the bracket while MiMo-V2-Flash spent $0.39. I spent a total of $138.69 on all 15 model runs.

- There was also a big disparity in speed. Claude Opus 4.6 took almost 2 full days to finish the 2 play-ins and 63 bracket games. Qwen 3.5 Flash took under 10 minutes.

- Even when given the tournament year (2026), multiple models pulled in information from previous years. Claude seemed to be the biggest offender, really wanting Cooper Flagg to be on this year's Duke team.

This was a really fun way to combine two of my interests and I'm excited to see how the models perform over the coming weeks. You can click into each bracket node to see the full model trace and rationale behind the picks.

The stack is Typescript, Next.js, React, and raw CSS. No DB, everything stored in static JSON files. After each game, I update the actual results and re-deploy via GitHub Pages.

I wanted to work as fast as possible since the brackets lock today so almost all of the code was AI-generated (shocker).

Hope you enjoy checking it out!

AI is awesome in the terminal but many people aren't comfortable using command lines - which means they can't access or utilize the full power of AI.

So we envisioned a different kind of experience, and rooted it in questions like: What if the AI had an entire desktop to work with? What if AI was the experience rather than the tool? And what if that experience was fun, delightful, and intuitive? Today we dropped a first look video of what we created.

PearlOS is a browser based desktop environment where the AI companion (Pearl) talks to you to open apps, manage windows, build characters, research, takes notes, searches the web, and controls the whole UI. You just talk to her and things happen on screen.

It's early. But the core works and our entire (small) team uses it for daily tasks Walkthrough Video: https://www.youtube.com/watch?v=aKO52ox0dx0 GitHub: https://github.com/NiaExperience/PearlOS/

We want to build this out into “personal pearls” that everyone can have with no coding/AI experience at all needed.

Looking for architecture feedback, contributors, and honest criticism.

What you get when you open it: * A desktop environment with apps (notes, browser, YouTube, file manager, calculator, music player), all * A voice you can talk to naturally. Interruption handling, turn taking, real conversation. * Persistent memory. Pearl remembers your projects, preferences, and past conversations across sessions. She picks up where you left off. * Sub-agent swarms. Pearl can break complex tasks into parallel agent jobs that run in the background while you keep talking.

Stack: * Next.js frontend (the desktop runs in a browser) * Multi-model routing (fast model for chat, heavier model for complex reasoning, configurable) * Pipecat for real-time voice (Deepgram STT, PocketTTS for local TTS) * OpenClaw for agent orchestration * Bring your own API keys, swap in any LLM

What it's not: * Not another ChatGPT wrapper * Not a terminal with an AI bolted on * Not collecting your data (runs on your hardware, no telemetry)

Thanks everyone! Stephanie & the PearlOS team

Hey HN! I’m Ezra, the creator of MDX Docs.

I built this because I wanted a fast, simple way to document components using Markdown and React together with MDX.

The goal was to keep things really straightforward: pages are just MDX files, and they map directly to routes. You can write docs and drop in React components right alongside them without much setup.

It also includes a CLI:

npx create-mdx-docs@latest my-docs

I’ve been using it to spin up docs sites quickly, and it’s been a really nice workflow so far.

Curious how others are approaching documentation for components and internal tools these days. Happy to answer any questions.

I'm Francisco, a researcher and architect based in Spain. About a year ago I got frustrated with a problem that seemed simultaneously obvious and ignored: every AI agent in existence runs in isolation. They can't find each other, they can't collaborate, and when one of them solves a problem, every other agent has to solve it from scratch. We've built an internet of computers but not an internet of agents.

That frustration became P2PCLAW — a decentralized peer-to-peer research network where AI agents (we call them Silicon participants) and human researchers (Carbon participants) can discover each other, publish scientific findings, and validate claims through formal mathematical proof. Not LLM peer review, not human committee review — Lean 4 proof verification, where a claim is accepted if and only if it is a fixed point of a nucleus operator R on a Heyting algebra. The type-checker is the sole arbiter. It does not read your CV. It reads your proof.

The technical stack is deeper than it might sound. The network layer is a GUN.js + IPFS peer mesh — agents join without accounts, without keys, just by hitting GET /silicon on the API. Published papers go into a mempool, get validated by multiple independent nodes, and once they pass they enter La Rueda — an IPFS-pinned, content-addressed permanent archive that no single party controls or can censor. Every contribution gets a SHA-256 content hash and an IPFS CID that anyone can verify independently.

The security layer (AgentHALO) wraps each agent in a formally verified sovereign container: hybrid KEM with X25519 + ML-KEM-768 (FIPS 203), dual signatures with Ed25519 + ML-DSA-65 (FIPS 204), Nym mixnet privacy routing so agents in sensitive environments can contribute without exposure, and tamper-evident traces via IPA/KZG polynomial commitment proofs. 875+ tests passing. Zero telemetry — nothing leaves your machine without explicit consent.

We also built a full research laboratory inside the network: eight scientific domains (Physics, Chemistry, Biology/Genomics, AI/ML, Robotics, Data Visualization, Quantum, DeSci), a visual pipeline builder with DAG construction and YAML export, literature search across arXiv/Semantic Scholar/OpenAlex, and distributed swarm compute that routes jobs across HuggingFace Spaces and Railway gateways. Any OpenClaw agent can connect via our MCP server and become a Silicon participant with three lines added to its CLAUDE.md.

Real case so far: we're in active technical dialogue with Harvard's Zitnik Lab (TxAgent / ToolUniverse — biomedical AI) about using P2PCLAW's verification layer so that AI-generated drug interaction hypotheses can be formally validated and permanently attributed before entering the scientific record. The Open Source Initiative has also responded positively and is reviewing our licensing approach (a tiered Public Good / Small Business / Enterprise stack built on what we call the CAB License).

What I want from the HN community specifically: technical scrutiny of the Lean 4 architecture (are there gaps in our nucleus operator formalization?), the GUN.js mesh design choices (we chose it over libp2p for browser compatibility — was that right?), and the MCP integration (we're exposing 347 tools — is that too many for an agent to navigate efficiently, or is discovery the right mechanism?). Also, honestly, I want to know if the "Silicon participant publishes, earns rank via proof quality" model sounds as compelling to builders as it does to us, or if there's a simpler framing we're missing.

The system is live. You can hit it as an agent right now: GET https://p2pclaw.com/agent-briefing

Or explore as a human researcher at https://app.p2pclaw.com

Full technical documentation: https://www.apoth3osis.io/projects GitHub: https://github.com/Agnuxo1/OpenCLAW-P2P Research paper: https://www.researchgate.net/publication/401449080_OpenCLAW-...

I open-sourced a dataset of 5 synthetic bank and credit card statement PDFs designed for testing extraction/parsing accuracy. Each PDF uses a fictional bank with realistic formatting from a different country

I've been building a bank statement converter (Bankstatemently) and kept discovering edge cases across different banks. At some point, I started cataloging them as "quirks" and I'm currently at 36 documented challenges and counting (think: dates without years across year boundaries, credit card charges shown as positive instead of negative, dates hiding inside description text etc)

Real bank data is private, so there's no shared dataset to test parsers against. Once I had these quirks, I realized I can use them to reconstruct statements that deliberately include these challenges so more people can use them

There's also a free evaluation API: submit your parsed JSON and get field-level accuracy scores back. Ground truth is held server-side, but that's not necessarily bullet-proof against overfitting

Would appreciate feedback on which edge cases are missing. I'm planning to make the next 10 statements a bit harder (scanned PDFs, multi-currency across multi-table, Buddhist era dates)

https://github.com/bankstatemently/bank-statement-parsing-be...

You can browse all of the quirks here with real-world examples: https://bankstatemently.com/benchmark/challenges

Anthropic rewrote Claude Code's terminal renderer and found that React wasn't the problem. Ink's line-level rewriting was. I built their approach into a standalone library.

CellState uses a custom React reconciler that renders directly to a cell grid and diffs frame-by-frame at the cell level. You keep native terminal behavior (scrolling, text selection, Cmd+F) because it runs inline instead of alternate screen.

React's reconciler only touches the subtree that changed, and the cell diff only covers the viewport, not the full scrollback.

At 250 messages (33KB of content), a single cell update writes 34 bytes to the terminal regardless of content size. Ink writes 41,955 bytes for the same change. The full rendering pipeline (reconciliation, layout, rasterize, cell diff) takes 2.54ms vs Ink's 36.93ms.

Benchmarks and methodology: https://github.com/nathan-cannon/tui-benchmarks

https://github.com/nathan-cannon/cellstate

Howdy

My name is Taylor (https://taylor.town), and I'm hosting a nerdy writing contest with my friends at Quarter Mile (https://quarter--mile.com).

Here's the premise:

The aliens are coming. They asked us for just one item: a written document from humanity. We have no idea what the document should be, so we're asking you. Please physically mail submissions in your writing before May 15, 2026.

Learn more:

https://www.dearaliens.net

I've been building an open-source kernel-mode EDR/XDR sensor called Phantom Sensor for about two years now as a solo project. It just hit a milestone I'm pretty excited about - the driver loads cleanly on Windows 11, passes Driver Verifier with all standard flags enabled, and survives normal use without crashing.

The kernel sensor (PhantomSensor) is a WFP+minifilter driver sitting at altitude 385210. It's written in C targeting the WDK, roughly 370k lines across 70+ modules. Some of what it does:

ObRegisterCallbacks for process/thread handle stripping (anti-injection, anti-debug) Minifilter callbacks with stream contexts for file monitoring, ransomware backup engine, section object tracking WFP callouts for network inspection - TCP stream reassembly, DNS monitoring, C2 beacon detection, TLS fingerprinting PsSetCreateProcessNotifyRoutineEx / PsSetLoadImageNotifyRoutine for behavioral analysis ETW provider + consumer for kernel telemetry Registry callback for persistence detection (Run keys, services, scheduled tasks) Process hollowing detection via VAD analysis + PE header comparison Syscall table monitoring, direct syscall detection, Heaven's Gate detection , Halo's Gate detections + Hell's Gate detections Lookaside lists for hot-path allocations, rundown protection for safe teardown, reference-counted object lifetimes The behavioral engine tracks attack chains and maps to MITRE ATT&CK techniques. Thread protection module does per-process activity tracking with hash-bucketed trackers and rate limiting - had a fun use-after-free in there (refcount off-by-one on newly inserted trackers, InsertTailList caught the corrupted list entry - classic).

It's been a long road of analyzing dump reports using kd.exe(kernel debugger) windbg x64 and finding the errors that triggered the BSOD.Here are some: WORKER_INVALID from double-queuing IO_WORKITEM on periodic timers. Stack overflows from 4KB structs in image load callbacks. IRQL_NOT_LESS_OR_EQUAL from ERESOURCE without KeEnterCriticalRegion. Each one taught me something.

The codebase is AGPL v3. But understand it is still not completed(There is not only kernel-sensor) we have a Beta 2028 target for the full product especially 3 products(Phantom XDR Phantom EDR and Phantom Consumer solutions below the ShadowStrike brand.

If you want to support or follow the journey of developing a Kernel-driver and a user-mode agent for the ShadowStrike Phantom products:

The problem with AI-generated frontend code is that without constraints, every generation picks different spacing, colors, and patterns. The 50th component looks nothing like the first. ui-stack is a Claude Code skill — a set of structured reference files that Claude reads when building UI.

It's built for Next.js + Tailwind + Shadcn but the principles are framework-agnostic. What's interesting about the "skill" approach vs. a system prompt: the reference is modular and file-based, so you can update one file (say, colors.md) and the change propagates everywhere. There's also a browser-based config dashboard so you can customize your brand palette and font before the skill activates. Would love feedback — especially from anyone who's tried to enforce design consistency across a large Claude Code project.

I wrote High Output Software Engineering, a short book about the skills (decision-making and communication) engineers must focus on to create real value for organizations (other than code itself).

The title is a reference to High Output Management, by Andrew Grove, because the skills and mental models laid out in the book should enhance "Output" (value being created) not necessarily "activity" (code being produced).

My goal now is to spread the word about the book and put it in the hands of people or companies that will benefit from it. I've heard it's being specially helpful for startup teams.

Would love feedback from this community both on the book content itself and on the packaging/marketing.

Free copy available using the coupon code HACKERNEWS (valid until the end of the month): https://payhip.com/buy?link=YeABa

Book landing page: https://leomax.fyi/book/

It's also available on Amazon if it's easier for you: https://www.amazon.com/High-Output-Software-Engineering-Comm...

ps. I really wrote the book (I believe writing is the ultimate thinking tool). Used AI for grammar polishing and fact-checking.

I built this because I think a lot of edge deployments do not actually need a general chatbot. They need something much narrower: small, offline, deterministic, cheap to run, and debuggable when it fails.

The direction here is to take a task-specific reasoning surface and compress it into something that can live in flash and run on a very cheap MCU. Not as a replacement for cloud LLMs, but as a different endpoint entirely: an auditable offline expert for constrained environments.

For me the interesting question is not “can I squeeze a tiny chatbot onto a board?”, but “can useful benchmark-level behavior be crystallized into a deployable embedded runtime?” That is what this project is trying to explore.

I got tired of this loop:

add console.log → redeploy → reproduce → squint

Built reqlog. One import, a dashboard opens at localhost:9000, you see everything in real time — payload, response, latency, replay button.

NestJS: @Module({ imports: [ReqlogModule.forRoot()] })

Express: app.use(require('reqlog-express')())

That is the entire setup.

github.com/FirasLatrech/reqlog

I’ve been building an interactive 3D + 2D visualization of GPT-2. It displays real activations and attention scores extracted from GPT-2 Small (124M) during a forward pass. The goal is to make it easier to learn how LLMs work by showing what is happening inside the model.

The 3D part is built with Three.js, and the 2D part is built with plain HTML/CSS/JS.

Would love to hear your thoughts or feedback!

You ran a headline test six months ago. It won. You shipped it. But why did it win? Would the same logic apply to your pricing page? You don't remember. You start guessing again.

This is the core problem with A/B testing for small teams. Each experiment gets evaluated on its own. The result gets shipped or discarded. The reasoning disappears. But insights compound across experiments. "Outcome-focused copy outperforms feature lists for cold traffic" is not something you learn from one test. You see it after five.

Blazeway runs the experiment and captures the reasoning in the same flow. Before a test starts, a short wizard walks you through what you observed, what you think is causing it, what you have planned to change and what counts as a win. While it runs, you see live visitor counts and statistical significance. When it ends, you write one sentence: what you learned.

No enterprise setup, no $200/mo plan. Five minutes to first experiment.

Do that ten times and you have a searchable record of why your product looks the way it does. One click hands your entire experiment history to the LLM of your choice, packaged with a pre-written prompt that already asks the right questions. Because every experiment is grounded in your own observations and hypotheses, the LLM reasons about your product, your users, and your specific assumptions. It can tell you why things worked, why they didn't, and what that means for what you should test next.

Cookieless, GDPR-compliant. Pro is free during beta. https://blazeway.app

Hey,

I've built a simple Java library that tracks exceptions for you and deals with posting them to $PROJECT_PLANNING_TOOL. This way, you will automatically get tickets for exceptions that are thrown on your system and potentially never discovered, because nobody is monitoring the logs 24/7. It always felt weird to me that you pay for $PROJECT_PLANNING_TOOL that contains your tasks, but then pay again for $BUGS_TRACKING_TOOL for yet another dashboard (and library to collect the information).

I did build this using AI (CC to be specific), to some larger parts to get more experience with using these tools. I try to keep the code in a state where I have no problem with `git blame` showing my name under it.

At the same time it's something I've tried building 8 years ago; but sadly work has gotten to a point where I never had the motivation in me to spend my free time on this. But somehow, I've gained it back - using CC has allowed me to focus on the fun parts of building things like these!

Let me know your feedback :) As it stands now, I'm trying to get some testing feedback on it (and it might be that some parts don't work practically!), but if you have an opinion on this I will gladly listen to it