←back to thread

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

(specific.dev)
29 points fabianlindfors | 2 comments | 15 Oct 25 17:21 UTC | HN request time: 0.449s | 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

1. hbrn ◴[16 Oct 25 00:30 UTC] No.45600141[source]▶
Funny, I've spoken about something like this to a colleague couple weeks ago. This could be a future of software development we're headed towards, if the DX is done right.

There are definitely cases where the spec is much easier to understand than the code that implements it.

Think systems with complex lifecycles or lots of required boilerplate.

Have you thought of embedding the specs into existing code?

E.g.

  # @spec: if any method takes longer than 1s to execute, a warning must be logged

  class X: ...
replies(1): >>45600390 #
2. fabianlindfors ◴[16 Oct 25 01:08 UTC] No.45600390[source]▶
I think specs embedded into existing code is a good idea as well, in fact there is some work being done in this area, like the Kiro editor: https://kiro.dev/

We have gone the all-specs route for now because it gives us an opportunity to try build that DX that you mention (which will be critical), without having to adapt to existing codebases that are no covered by specs.