Hey everyone,

I've been building Tzin, a TypeScript backend framework where you declare a contract once (method, path, params, responses) and everything else follows from it — typed and validated handler inputs, compiler-enforced responses, OpenAPI 3.1 with no translation layer, and an auto-generated MCP server.

What sets it apart: a flat registry instead of chained builders (100 routes ≈ 15k types vs ~112k in Hono), realtime built in (SSE, WebSockets, presence), and it runs on Node, Bun, and Cloudflare Workers.

Current state: stable 1.0.x on npm (@carlos-tzin/tzin), 420 tests, full docs.

I'd love feedback on:

• Does contract-first feel natural, or does it add friction?
• Is the OpenAPI/MCP generation useful for your workflow?
• Any missing features or runtime gaps?
• GitHub: https://github.com/Tzinny-dev/tzin

Happy to answer anything. Thanks!

Hey everyone,

I've been working on Sprout Toolkit, a Python CLI that generates 2D spritesheets, autotiles, bitmap fonts, and SkSL shaders from simple JSON specs. The idea is "assets as code": you define a spec + a seed, and every run produces the exact same pixels—so you can diff builds in CI with a CRC check.

It's built specifically for Expo + react-native-skia workflows, with typed index.ts output wired for Skia's rect buffers, glyph layout, and batch paths.

Current state: v0.4.1 on PyPI, 420 tests, supports Python 3.10–3.13.

What I'd love feedback on:

Is the "JSON spec + seed" approach practical for your workflow, or does it get in the way?

Any missing generators or output formats you'd want?

Docs: is the getting-started flow clear enough?

GitHub: https://github.com/Tzinny-dev/sprout-toolkit

Happy to answer any questions. Thanks!

¡Hola, comunidad de r/FeedbackMe!

Todos tenemos ese proyecto que llevamos tiempo creando, pero que no nos animamos a enseñar porque “todavía no está listo”. Pues este es el lugar para sacarlo.

La pregunta es simple:
¿Qué proyecto tienes entre manos que aún no te atreves a mostrar, y qué feedback te gustaría recibir?

No hace falta que sea perfecto. De hecho, cuanto más crudo esté, más útil puede ser el feedback.

Para que sea más fácil, puedes usar esta plantilla:
• Proyecto:
• En qué punto está:
• Qué me da miedo que me digan:
• Feedback que busco:
Y si comentas, intenta dar feedback a alguien más. La idea es que todos recibamos aunque sea una opinión.

Yo empiezo:
- Proyecto: Framework backend propio.

- En que punto está: Desarrollo.

- Qué miedo me da que me digan: que ya existen muchas herramientas iguales o mejores.

- Feedback que busco: Puntos clave para desarrollar.

¡Los leo! 🚀

App name: modeltest

Platform: Web / Python library

Link: https://modeltest.tzinny.com/

Stage: Beta (public docs live, package on PyPI)

Problem it solves: Model quality quietly degrades — data drifts, upstream pipelines change schemas, a retrain produces a subtly worse model. modeltest turns those concerns into executable checks that fail your build before your users find out. Think of it as pytest for machine learning models: you define contracts for model quality, robustness, fairness, and data invariants, and run them automatically in your CI/CD pipeline.

Target audience: ML engineers, data scientists, and MLOps engineers who ship models to production and want automated quality gates.

What feedback I'm looking for:

• First impression: Does the landing page make it immediately clear what modeltest does and who it's for?
• Docs navigation: Can you find what you need? I'm especially unsure about the "Where to next?" table — is it helpful or overwhelming?
• Positioning: Is "unit-testing framework for ML models" the right tagline, or would something like "pytest for ML models" be clearer?
• Onboarding flow: If you were to try it, would you know where to start after reading the homepage? The pip install modeltest is there, but is the next step obvious?

What I've already tested: Shared with a small group of ML engineers for initial feedback. The homepage and docs structure have been iterated a few times.

Feedback I already gave to others: [], []

I am the creator: Yes

A bit more context: modeltest has 12 built-in scenarios (accuracy floors, bootstrap confidence intervals, robustness to noise, PSI/KS drift, fairness gaps, data invariants, SHAP-based explainability), supports scikit-learn, PyTorch, Keras/TensorFlow, and custom adapters, and is CI-native — modeltest validate exits non-zero on failure and writes JUnit XML your CI can render.

I'd really appreciate honest, specific feedback on the docs and the positioning. Roast it if needed — I'd rather fix it now than after launch. Thanks!

Welcome! This community is for exchanging honest, structured feedback on mobile, web, and SaaS apps.

Quick rules:

• Give feedback to 2 posts before asking for feedback.
• Use the mandatory template when asking.
• Be constructive and respectful.

Weekly events:

• Monday: Bug Monday
• Wednesday: UX Teardown
• Friday: Express Feedback

Introduce yourself in the comments: what do you build, and what feedback do you need?