HN user

duckerduck

85 karma

x.com/Jan_Schutte

https://bsky.app/profile/janschutte.com

https://janschutte.com/

Posts5
Comments29
View on HN

They kind of already have a central point with 'ssh exe.dev', which hosts the interface for provisioning new VMs. But yeah, still one extra step for the user.

When I was very young I installed OpenSUSE on my underpowered windows PC, it was really a hacker man experience that is engraved in my mind as a core memory. As a child I just thought it was cool to have a new and faster desktop, but as I've grown older I've stayed with Linux for its ideas and principles. Hopefully these laws can be overturned...

I'm building a Typeform/Google Forms alternative that integrates into existing applications and stores data in your own database. It allows you to define forms in JSON Schema or JSON Forms. Forms can be added or removed dynamically, and submissions are sent to your backend and in turn stored in your database.

Built using our full-stack library toolkit Fragno [0].

[0] https://fragno.dev/

I'm building a Typeform/Google Forms alternative that integrates into existing applications and stores data in your own database. It allows you to define forms in JSON Schema or JSON Forms. Forms can be added or removed dynamically, and submissions are sent to your backend and in turn stored in your database.

Built using our full-stack library toolkit Fragno [0].

[0] https://fragno.dev/

Congrats on getting to beta!

I very much relate to the problems you're trying to solve, so much so that I have created a Stripe integration library [0] that has very similar DX to flowgrad! (not nearly as feature rich however). I've also written a blog post as to why I built it[1].

Key difference is where the final billing information is stored, our library also ships db schemas and the webhook handlers write to that local db.

You should also check out our (open source, MIT) library[1] this is built on, it could be useful for you guys!

[0] https://fragno.dev/docs/stripe/quickstart

[1] https://fragno.dev/blog/split-brain-stripe

[2] https://fragno.dev/docs/fragno

I’m working on “Stripe Integration as a Library.” It seems that whenever someone uses Stripe, for example for subscriptions, they go through the same few steps: creating a database table, setting up webhooks, and implementing the events they care about. The challenge of course is that everyone uses a different stack.

I’m building this using our framework for stack-agnostic JS/TS libraries. On the database side, we currently support Drizzle and Kysely, with Prisma support coming soon.

https://fragno.dev/docs/our-fragments/stripe/quickstart

Inspired by the Stripe integration built for better-auth.

Wow, thanks for sharing, that really takes me back. I was so hyped when I saw this as a kid, my dad and I made a mount for my glasses with two IR LEDs and a battery. I remember that I was super impressed with the effect.

I think semcheck has a different use-case. AI is inherently imprecise, if you need formal mathematical verification, AI isn't suitable for that. What semcheck does give you is a very simple way to start verifying specifications, and it's best used in combination with AI-assisted development workflows where you're already spending a lot of time writing specifications (i.e. prompts).

I'm working on a development tool for specification-driven development. It uses LLMs to verify that your specification files and implementation do not drift. More specifically, I am trying to lower the number of false positives I'm currently seeing. I find that the LLM will hallucinate issues when there are no discrepancies, or become forgetful in the case of long documents (like RFC texts). The first step in improving this is to expand my evaluation suite so I can reliably measure improvements.

https://github.com/rejot-dev/semcheck/

It seems that many in the field are converging to similar ideas. With AI the emphasis seems to be more on defining clearly what to build rather than how. I made a similar experiment [1] recently where I setup "rules" between code and spec and have the LLM check that they are the same, I think similar to how Kiro uses hooks.

[1] https://news.ycombinator.com/item?id=44432215

I've made a utility that uses LLMs to compare specifications against implementations, called "semcheck" (semantic checker). I’ve often found that even though I set up Cursor rules or CLAUDE.md files, the implementation tends to drift away from these documents. I built this utility to be run as a pre-commit or CI step to check that they are still the same.

Repo: https://github.com/rejot-dev/semcheck/