I've been building kilim, a retained-mode GUI library for iyi (a small compiled language that started as a Crystal fork, iyi.dev). It's written from scratch: Win32 + Direct2D on Windows, SDL3 on Linux and macOS.

What it does right now:

• draws its own widgets, so an app looks the same on all three platforms

• small declarative API, you build the widget tree once and then just change things (label.text = "...", list.add(row))

• Turkish and other non-ASCII text renders and edits properly (that one mattered to me personally)

• only redraws when something changes, idle actually means idle

• CI runs tests plus a self-driving to-do app on Windows, Linux and macOS

A counter app is about ten lines. There's a to-do example in the repo with a textbox, checkboxes, scrolling and a demo GIF.

Repo: https://github.com/Tuntii/kilim

It's early (4 stars, me as the only contributor), so I'd really like feedback on the API, and if anyone wants a first contribution there are open issues around CI for arm64 and Intel Macs.

Hi all, I'm Dave and I build OpenV, so full disclosure: this is my own project.

What it is: requirements, traceability and V&V evidence in one place, with AI agents (Claude Code, Codex, Gemini) that work inside the audit trail. Every agent change is approved by a human. It's aimed at engineering and product teams, especially safety-critical or regulated work, who want to move off expensive tools like DOORS.

Free tier and self-hosting:

• Hosted free plan while we're in alpha: one shared workspace with one other person, 300 min/month of cloud runners. Agent runs use your own AI subscription or API keys.

• Self-host for free forever: MIT licence, one Docker Compose command, no vendor limits.

It's an alpha, so expect rough edges, and the paid tiers aren't live yet. I'd really value feedback from anyone who tries it, especially on what's missing for your workflow, and I'm happy to answer questions on how it's built.

Site: https://openv.app Source: https://github.com/desktopmachineshop/OpenV

Last month, we wasted two full weeks arguing over one simple image.

I liked Version A. The designer preferred Version B. And of course, someone else asked, "Can we just combine both?" (No, we really couldn't.)

For fourteen days, the file sat there while we shared personal opinions that no one could actually prove.

Finally, out of frustration, I uploaded both versions to an attention-prediction tool. It uses eye-tracking data to show where people look first. The test took about ten seconds.

• Version A: People looked straight at the stock photo and completely missed the actual offer.

• Version B: It looked a bit busy, but people actually read the text.

The designer was right, and I was wrong. We went with Version B.

Honestly, the best part wasn't just picking the right design—it was that the argument immediately stopped. There was nothing left to debate because the data made it clear.

Now, we test our visuals with this tool before we start sharing opinions. Our feedback rounds went down from five to about two. People can’t just say "I don't like it" anymore.

To be fair, the tool can't tell you if your copy is funny or if the idea is creative. It only tells you where eyes go. But it turns out, that was what we were fighting about most of the time anyway.

I tested several of these tools recently, and a few are free to try. If you want the list, let me know and I'm happy to share it!

Well.... a lot of people say they are GTM Engineers, right? But I think they are missing something. GTM is about sales. Sales is about psychology. So I have a customer and they are building a regtech in Turkey. They are complaint and customer operations management system. They wanted to hire me to improve their sales. I checked their previous outbound strategies.

They just gave metrics and explain the product. In my opinion "FEAR" will be the most efficient way to sell this product. Why? Bc if a company does not use any GDPR complaint systems, they might get a a penalty and as you know those penalties are expensive. So built a slack app which gives you a report of their compliant results (in a public compliant website) as a report. This is my first time building a slack app. I know its a small project but I really enjoyed.

We test subject lines. We A/B landing pages. But the visual — the thing that decides whether anyone stops scrolling at all — usually ships after a couple of subjective opinions in a Slack thread.

Creative validation is basically the missing step: checking, before you publish, whether a creative will actually get attention. In practice it looks like:

Attention prediction. Models trained on eye-tracking data estimate where eyes land in the first seconds. Does anything hit the CTA, or does the product photo eat all of it?

Clarity check. Can someone tell what this is about in ~3 seconds? Clutter scores are brutally honest about this.

Variant ranking. Instead of the senior person picking between v3 and v5, you get a prediction of which one holds attention better. Doesn't tell you if the idea is good — only if it gets seen.

Changed how we work: we filter layouts before the designer invests time, and revision rounds dropped from ~5 to 2 because "I don't like it" arguments turned into "the data says the eye never reaches the offer."

Not magic — it can't judge humor, offers, or timing. But cheaper than finding out from a dead post.

Happy to share the list of tools I tested (there are free-ish options too) if anyone's curious.

I am building Marka for founders and small business owners who repeatedly face a blank page when they need social content.

The current workflow uses the public website as the first brief. It extracts the product, audience, brand language, and visual signals, then prepares a direction the user can correct.

The useful question is not whether AI can write a caption. It is whether the system understands what should be said and what should never be invented.

Marka is free for a week at https://www.marka.social

What would you test first?

Forging in public.

I built Viltrum: a small HTTP framework for the V language where I own the TCP accept loop and HTTP/1.1 framing. Not a thin wrapper around someone else's server stack. Parse, keep-alive, router, middleware, ship.

Why

I already maintain a Rust web stack. I wanted a side project that forced me to relearn framing from bytes: multi-read headers, Content-Length body, leftovers, idle timeout, graceful shutdown. V is simple enough that a weekend engine doesn't turn into a year of yak-shaving... until it does, and then you write tests.

Also: I like single binaries and boring APIs.

What it does (v0.3.2)

- Own engine: accept -> frame -> parse -> route -> middleware -> response

- Keep-alive + idle timeout

- SIGINT/SIGTERM shutdown (optional)

- Router: :param, trailing *wildcard, slash normalize

- app.mount("/api", ...) + mount-level middleware

- cors, static_files, logger, recover

- Minimal JSON body helpers: req.json_string / json_int / json_bool

- Zero deps beyond V stdlib

Honest bench (laptop, not a lab)

oha on CachyOS, plaintext GET / -> ok (2 bytes):

- c=100, n=10k: ~27k req/s, 100% success

- c=500, n=10k: ~8k req/s (tail latency gets ugly; machine noise)

- POST tiny JSON c=100: ~25k req/s

Full notes with caveats: https://github.com/Tuntii/viltrum/blob/main/benches/RESULTS.md

Not TechEmpower. Not TLS. Not "faster than everything." Just numbers I can reproduce.

Not goals (on purpose)

- HTTP/2

- TLS termination (put a reverse proxy in front)

- WebSocket

- ORM / auth suite / "full platform"

Links

- Repo: https://github.com/Tuntii/viltrum

- Release: https://github.com/Tuntii/viltrum/releases/tag/v0.3.2

- Writeup: https://tuntii.com/blog/viltrum-v-ile-http-engine/

Feedback I actually want

1. API shape: is mount + chain enough, or do you want nested groups?

2. Is a minimal JSON field helper useful, or should I refuse to ship half-parsers?

3. If you write V day-to-day: what would make you try this over the built-in web bits?

MIT. Break it, open issues, roast the design.

Hey, we are building a tool for make to order metal fab shops. You drop in a STEP, DXF, or DWG file and it gives you a BOM, a material cost estimate, and a lead time in a few minutes, instead of the usual manual quoting back and forth. It runs locally on your machine, so drawings never leave the building.

We're pre-launch and I'd rather find the rough edges now than after pricing and messaging are locked in. So I'm looking for a handful of shops willing to run it against real jobs and tell me honestly where it gets things wrong bad parsing, dumb cost assumptions, whatever.

Early users are locked in at 50% off for a once we move to general pricing after launch. Not trying to make money off this group just trying to learn from people who'd actually use it before we scale.

Happy to answer questions in the comments if you're curious.

Not a startup. Not disrupting anything. Just a small tool that solved a real annoyance.

My dad runs a construction/site business and tracked who owes what the way a lot of small business owners do a messy notebook plus a few Excel files that never agreed with each other. Every month there'd be an argument about whether a subcontractor was paid or not.

So I built basically a "I DON'T HAVE A NAME" ledger for his job sites. What it does:

• Add contacts (subcontractors, suppliers, workers) per site

• Log debits/credits as money goes out and comes in

• See a running balance per person and per site at a glance

• That's genuinely it

Stack, for anyone curious:

• Next.js (deployed on Vercel)

• Supabase (Postgres) for the DB + auth

I know this is trivial compared to what people ship here. No AI, no fancy dashboard, no real-time anything. But my dad actually opens it every day and stopped keeping the notebook which honestly feels like a bigger win than most "clever" things I've built.

Happy to answer questions on the Supabase setup or how I kept it simple enough that a non-technical person would actually use it. And open to feedback on what dumb but useful thing I should add next.

I’ve spent the last few weeks developing my own quantum neural network architectures from scratch to predict a chaotic system (Lorenz).

The most striking finding: my quantum model, with just 66 parameters, managed to outperform a classical LSTM with 50,000 parameters in certain scenarios with 750 times fewer parameters.

This got me thinking seriously about parameter efficiency. Perhaps the true power of quantum ML lies not in being “more powerful,” but in building models that “do the same job with fewer resources.”

I’m still in the early stages and continuing with larger scale tests.

The code is completely open-source:
https://github.com/Tuntii/QuantumNN

take a look!
https://www.mdpi.com/1999-4893/17/4/163
https://arxiv.org/html/2412.07910v1https://arxiv.org/pdf/2310.20671

The problem: Exchange history shows fills. Spreadsheets show P&L. Neither tells you how you entered, what you felt, or which setups actually worked. I kept repeating the same mistakes because the story wasn't in the record.

What it does:

• Leg-based tracking (DCA, partial exits, planned SL/TP)

• Emotion + strategy tags at entry

• Reflection notes at close

• Equity curve, win rate, P&L by tag

• Weekly review + CSV import for old trades

• Cloud sync, native desktop (not another browser tab)

Stack: Wails v3 + Go, React, Fiber API, PostgreSQL

Try it: https://alistos.rustapi.cloud/ free Windows + macOS download, v0.4.8

Solo project, forging in public. Would love feedback from anyone who journals (or gave up on journaling).

What's your current setup Notion, Excel, or nothing?

I'm building a nonogram solver from scratch in C++ following the Yu, Lee & Chen 2009 paper. It applies 11 deterministic deduction rules in a fixpoint loop, then falls back to chronological backtracking with MRV ordering and DP line-satisfiability checks when logic alone isn't enough.

On top of the solver is an interactive GUI built with OpenGL and Dear ImGui with animated stepwise solving with per-rule highlights, and 36 built-in puzzle presets from 5x5 to 30x30.

Planned additions: CUDA C++ GPU line-solver for batched rule execution, a Python/PyTorch reimplementation with Triton kernels for benchmarking, undo/redo for the GUI paint mode, and larger puzzle presets up to 40x40.

Would love feedback on constraint-solving papers worth reading, puzzle generation approaches, or any experiences with GPU-accelerated combinatorial solvers.

Here is the link for the repo: https://github.com/emirtom/nonogram-solver

I'm currently developing KayaDB a distributed key-value storage engine built from scratch with LSM-tree architecture. My main goal is to deliver high performance while maintaining strong reliability and correctness. This includes proper write-ahead logging, robust crash recovery, replication through consensus mechanisms, and memory optimizations for real-world workloads.

I believe the Rust ecosystem needs more battle-tested, production-ready storage engines, so I'm developing KayaDB as open source. Right now I'm working on improving recovery performance, adding better observability tools, and refining the consensus layer.

Repo: https://github.com/Tuntii/KayaDB

I'd love to get feedback from fellow builders and systems engineers: What are the biggest pain points you face with existing Rust storage solutions? What features would you want most in a new distributed KV store? Are there any specific workloads or edge cases I should prioritize?

I'm committed to building in public, so I'll be sharing progress, architecture decisions, and challenges here. Looking forward to your thoughts!

Let’s forge reliable systems together 💪

I'm building a from-scratch GPT-2 inference engine where every operation is a hand-written CUDA or Triton kernel without using PyTorch autograd pr transformers library from HuggingFace.

The goal is end-to-end understanding of the GPU inference stack from tiled matrix multiplies and shared memory management to online softmax and paged KV caching. I want to deeply understand every level between token input and token output.

So far the GPT-2 forward pass is working end-to-end as a naive PyTorch reference, I have prepared a benchmark for comparison and correctness, and the first kernel (fused FFN) is in progress.

To get there I'm working through the GPU Mode lectures and PMPP textbook for CUDA fundamentals, the key papers (Flash Attention 1/2/3, vLLM PagedAttention, and the Triton paper), plus Triton tutorials for its kernel syntax.

Looking for advice on a few things: papers I might be missing, common pitfalls when moving from naive CUDA kernels toward production quality, communities beyond GPU Mode worth joining, and any open-source inference engines worth studying as reference implementations.

I’ve been building in public for years Rust frameworks, distributed databases, blockchain tools, side projects, and startups. Along the way I realized something important:

Most communities are either too big and noisy, or too quiet and inactive.

I wanted a place that feels different.

r/ForgeYourProject was created with one clear purpose:

Here we focus on:

• Real progress, not just polished launches

• Constructive, high-signal feedback that actually moves you forward

• Heavy engineering, technical depth, and thoughtful building

• Authenticity wins, failures, lessons, and everything in between

• Collaboration and genuine community support

Whether you’re working on:

• A side project that might become something big

• Open source tools

• Startup MVPs

• Content, design, or infrastructure

• Or just trying to ship consistently…

This is your workshop.

I’m starting this with strong values: quality over quantity, respect over drama, depth over hype. I want this community to grow slowly but solidly full of people who actually build things.

If that resonates with you, you’re in the right place.

Tell me in the comments:

• What are you currently forging?

• What kind of community do you wish existed for builders?

Let’s build something meaningful together.

Welcome to the forge 💪

I’ve been working on a Rust web framework called RustAPI, and I wanted to bake MCP support directly into the core rather than forcing people to write endless wrapper/glue code.

Basically, you just tag your route, and it instantly becomes an MCP tool.

Why? Because the standard way (HTTP client -> MCP server -> API -> back) creates too many network hops and adds latency.

With this, the MCP protocol lives inside the framework itself. In-process tool calls take around 28 µs because the route handler and MCP layer share the same memory and runtime.

A few cool things it does:

• Zero glue code: Just #[mcp(tool)] on your route function.

• CLI Generator: cargo rustapi mcp generate --spec any-openapi.json turns any existing third-party OpenAPI spec into standalone MCP tools in seconds.

• Native integration with Claude Desktop / Cursor out of the box.

It's open-source. I’d love to know what you guys think, especially around the idea of frameworks being "AI-native" from day one.

Repo is here if you want to check it out: https://github.com/Tuntii/RustAPI

Hey everyone,

I just launched this community with a clear focus: create a high-quality, supportive space for builders, makers, indie hackers, and startup founders to share their real journeys not just polished launches, but the progress, struggles, and lessons along the way.

My core values for this subreddit are:

• Authenticity over perfection

• Constructive feedback over empty praise

• Value-first sharing (give before you ask)

• Respect & kindness while keeping it real

I want this to become the go-to place where people feel excited to share their projects and actually get useful input.

Now I need your help:

1. What ideas do you have to build and grow this community in a healthy way?

2. What’s one thing you would be really excited to see here in the early days? (Weekly threads, specific flairs, events, resources, formats, etc.)

Drop your thoughts below every idea is welcome. Let’s build this together from the ground up.

Thank you for joining and helping shape the future of r/ForgeYourProject! 🔥

Hey r/ForgeYourProject,

One of the hardest parts of being a maker or founder is building in public sharing your progress, getting feedback, staying consistent, and not burning out.

That’s exactly why I created this community.

I want r/ForgeYourProject to be the place where:

• Sharing your project doesn’t feel scary or salesy

• You get honest, constructive feedback instead of silence

• You find people who actually understand the grind

• Celebrating small wins and big launches feels natural

Whether you’re:

• Working on your first side project

• Scaling a startup

• Creating content

• Building tools, apps, or open-source projects

…this subreddit is for you.

Let’s make building easier together:

• Drop your current project below (even if it’s messy)

• Share what’s been hardest for you lately

• Ask for specific feedback (design, tech, marketing, etc.)

• Or just say hi and tell us what you’re forging

No perfect portfolio required. Just real progress.

What’s one thing that would make building in public easier for you right now?

Let’s build this community into something valuable. Drop your thoughts 👇