←back to thread

Show HN: Specific (YC F25) – Build backends with specifications instead of code

(specific.dev)
29 points fabianlindfors | 1 comments | 15 Oct 25 17:21 UTC | HN request time: 0.209s | source

Hi folks! Iman and I (Fabian) have been building Specific for a while now and are finally opening up our public beta.

Specific is a platform for building backend APIs and services entirely through natural-language specifications and tests, without writing code. We then automatically turn your specs into a working system and deploy it for you, along with any infrastructure needed.

We know a lot of developers who have already adopted spec-driven development to focus on high-level design and let coding agents take care of implementation. We are attempting to take this even further by making the specs themselves the source of truth. Of course, we can’t blindly trust coding agents to follow the spec, so we also support adding tests that will run to ensure the system behaves as expected and to avoid regressions.

There is so much ground to cover, so we are focusing on a smaller set of initial features that in our experience should cover a large portion of backends:

- An HTTP server for each project. Authentication can be added by simply stating in the spec how you want to protect your endpoint.

- A database automatically spun up and schema configured if the spec indicates persistence is needed.

- External APIs can be called. You can even link out to API docs in your specs.

You currently can’t see the generated code, but we are working on enabling it. Of course, we don’t claim any ownership of the generated code and will gladly let you export it and continue building elsewhere.

Specific is free to try and we are really eager to hear your feedback on it!

Try it here: https://app.specific.dev

Show context
wslh ◴[15 Oct 25 19:48 UTC] No.45597513[source]▶
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).
replies(1): >>45597597 #
fabianlindfors ◴[15 Oct 25 19:54 UTC] No.45597597[source]▶
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

replies(1): >>45597723 #
wslh ◴[15 Oct 25 20:05 UTC] No.45597723[source]▶
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.

replies(1): >>45597854 #
1. fabianlindfors ◴[15 Oct 25 20:16 UTC] No.45597854[source]▶
> 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.