[wslh]

Sorry but looking forward to the open source version. With all due respect to your work I assume that what you are building will be quickly reproduced as OSS. Also, for a backend I think a typical entity relationship definition or declarative DSL are better than AI (e.g. deterministic and less error/security prone).

[fabianlindfors]

That's fair! We have considered how we could offer an open-source version of Specific but haven't found a good model for it yet. We are definitely open to it though!

Curious to hear more about the entity relationship definition. The schema for the entities and relationships is naturally an important part of it but how do you define the logic needed around them? For example integrations with external APIs

[wslh]

Thank you for your kind reply. Now that you mention integrations with external APIs, I think it's fair to say that you should highlight that upfront in your webpage because it's a more clear pain point than building other parts of backends.

My two cents: in my experience with integrations there are many issues that you can't control yourself because third-party APIs are buggy, incomplete, etc. For top APIs there are, in general, good wrappers with tests to use.

[fabianlindfors]

> I think it's fair to say that you should highlight that upfront in your webpage because it's a more clear pain point than building other parts of backends.

Good point! We should do that :)

> My two cents: in my experience with integrations there are many issues that you can't control yourself because third-party APIs are buggy, incomplete, etc

Yes, I have actually spent a large portion of my career building such integrations and Specific has grown out of that. In my experience, working with specifications makes it much easier to focus on the behaviour of the API you are integrating with, instead of the code architecture or boilerplate behind your integration.