I would pick the second option. CLI.

However, for CRUD B2B SaaS I think MCP works fine (if not better than CLI).

Project description: A general-purpose process composer.

What do you hope to build this month? It'd be nice to flush out some of the more minor UX quirks.

What kind of skills do you need? Anyone with strong Rust skills and who knows their way around various Linux distros.

Website: https://sysg.dev

Github: https://github.com/ra0x3/systemg

Things are time bound by instruction creation - at some point you still need a human to dictate the instructions that the orchestrated agents use. From there I've found that -- (1) derive a goal from the instructions (2) break that goal into tasks (3) order those tasks into a DAG (5) spawn the agents to work via the DAG -- seems to be doing everything I want it to do.

The goal wasn’t a production-ready framework, just a POC to answer: how hard is it to add WASM to MCP, really? Turns out: not that hard.

I’m skeptical of one-vendor-controls-all MCP tool marketplaces (e.g., Composio/Pipedream). An open, contribution-driven model (think GitHub Actions) feels like a much better fit for Rust + MCP.

WASM brings sandboxing, safer untrusted code execution, and easy binary sharing — and runtimes like WasmEdge [2] make things like DB or network access much more realistic.

Overall, pretty happy with how it turned out. Happy to hear any feedback. Also curious what other Rust folks think about MCP + WASM as a direction.

- [1] https://github.com/ra0x3/mcpkit-rs - [2] https://wasmedge.org/

Comments URL: https://news.ycombinator.com/item?id=46707120

Points: 1

# Comments: 0

I built Snuper[1], a small utility for inspecting and consuming live DraftKings prop data directly from their WebSocket feeds.

The original itch came from building a live sports app where I wanted real-time betting lines and prop updates without relying on delayed REST endpoints or polling. DraftKings already streams this data — it’s just not documented.

Snuper connects to the WebSocket, listens for message frames, and exposes structured prop updates in real time. No scraping, no headless browsers — just listening to the same stream the site uses.

What it does:

- Connects to DraftKings WebSocket feeds - Decodes and surfaces live prop updates - Useful for real-time dashboards, analytics, or experimentation - Minimal, transparent, and easy to inspect

What it doesn’t do:

- No automation, no betting, no bypassing auth - No attempts to modify or interfere with traffic - Read-only observation of publicly delivered data

It’s intentionally small and focused — meant as a building block, not a product.

Open to any feedback :)

Comments URL: https://news.ycombinator.com/item?id=46593412

Points: 2

# Comments: 0

I built a sports app called Arbitration[1] primarily for experiencing live professional games. The original itch was pretty simple: during close or rivalry games I’d constantly flip between two team game threads on Reddit to see how each side was reacting to the same play.

Arbitration puts both fanbases’ live reactions in one place, synced to the game clock. It doesn’t generate opinions or takes — it just curates what fans are already saying, in real time.

Feel free to checkout the first NFL playoff game of the year, Rams @ Panthers: https://www.app.arbi.gg/scores/nfl/20260110-8-5

For folks curious about the tech:

- Agents are used to curate and rank live fan posts (not generate content) - Live DraftKings props come from a websocket snooper[2] - Google Gemini is used only to structure and summarize live prop data - Rust backend, React frontend, anonymous sessions, no accounts. - Mostly built for myself, but figured others here might enjoy it. - iOS app coming soon!

Happy to answer questions :)

- [1] https://arbi.gg - [2] DraftKings websocket snooper: https://github.com/stonehedgelabs/snuper

Comments URL: https://news.ycombinator.com/item?id=46570192

Points: 1

# Comments: 0

If at the time when I was cutting my teeth on systemd, I had access to something more lightweight and "do one thing well", I think I would've gotten a lot more sleep :)

https://sysg.dev

https://github.com/ra0x3/systemg

I'm personally tired of getting stuck in config/deployment hell every time I want to deploy a long-lived web service. Sure I eventually learned how to use systemd, but systemd has SO many things baked into that I simply don't need. systemg is a lightweight process supervisor that features everything you'd typically want when running/managing production web services in the wild.

Would love feedback.

It kinda makes sense - "knowing how to code" in modern tech largely means "knowing how to build software" - not write single modules in some language - because those single modules on their own are largely useless outside the context of "software".

Comments URL: https://news.ycombinator.com/item?id=45518582

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44426744

Points: 5

# Comments: 1

At a certain point, huge prompts (which you can readily find available on Github, used by large LLM-based corps) are just....files of code? Why wouldn't I just write the code myself at that point?

Almost makes me think this "AI coding takeover" is strictly pushed by non-technical people.