Who fromSpec is for: developers and technical founders

The fastest way to understand a tool is to know who it's not for. fromSpec is not a no-code builder. It won't help a non-technical user ship a black box they can't read. It produces a real codebase: entities, API routes, data models, a chosen stack, and it assumes you want that, can read it, and will maintain it. If "export the code and open it in your editor" sounds like a feature rather than a chore, you're in the right place.

So who is the right place for? Three audiences, each using the same pipeline for different reasons.

The developer: delete the boilerplate, keep the control

Every new app starts the same way: auth, a data model, CRUD routes, a frontend shell, Docker, CI. You've written it a hundred times. It isn't hard, it's just hours, and none of them are the interesting part of the product.

fromSpec exists to compress that. You describe the app, shape the structured spec (entities and their fields, use cases, flows), and generate a working project in FastAPI, React (Vite), and PostgreSQL, or Next.js. The scaffolding you'd have hand-written is there: models, routes, pages, capability modules for auth, payments, and email, plus Docker and CI/CD config so docker compose up runs it.

The difference from scaffolding a template is that the output tracks your spec, not a generic starter. And the difference from prompt-to-code is that you never lose the thread: the spec is spec.json, version-controlled and human-edited, and the code is generated from it. You can read the spec in seconds and you own every file it compiles to. There's no runtime dependency on fromSpec sitting in your stack. Generate, push to your GitHub repo, and it's a normal project from there.

The developer's win isn't "AI writes my code." It's "the boring 80% is generated from something I can review, and I keep full control of the 20% that matters."

The technical founder: from idea to a codebase you can hire around

If you're a technical founder or an early CTO, your constraint isn't ideas. It's the distance between an idea and something real enough to test, demo, or build a team on. Hand-building the MVP burns the runway you need for everything else. Gluing together no-code tools gives you something you'll have to throw away the moment you hire an engineer.

fromSpec sits in the middle: it gets you to a real codebase fast. Because the output is conventional FastAPI and React, or Next.js, with a documented architecture, it's something you can hand to your first hire without an apology. They can read the ER model, the routes, the spec that defines it all. You're not asking them to inherit a generated black box. You're handing them a project with a paper trail.

And because the product is defined in the spec, you can keep moving after the first generation. Change the product by editing the spec and regenerating from it, rather than re-prompting an opaque tool and hoping it preserves what worked.

The team: a repeatable way to start things

For a team, the value is consistency. Internal tools, prototypes, and new services tend to each get scaffolded a little differently depending on who started them: different auth wiring, different project layout, different conventions. A spec-driven pipeline makes the starting point uniform: same structured spec format, same stack choices, same generated architecture. New projects begin from a known shape instead of a blank directory and a personal preference.

That repeatability is also reviewable. Because every project starts from an explicit spec.json, a reviewer can reason about what a service is before reading how it's built, and the architecture, ER diagram, and API surface come generated alongside the code. The spec is a small, structured file, which means it slots naturally into the review habits a team already has: it diffs cleanly, it's legible in a pull request, and a change to the product reads as a change to a handful of fields rather than a sprawl across dozens of generated files. For a team lead, that's the difference between approving an intention and trying to audit an output.

Bring your own model

One thing all three audiences share is that fromSpec doesn't lock you into a specific LLM. You bring your own key and choose the provider: OpenAI, Anthropic, or Google.

You can even route each step to a different provider. Spec generation, preview generation, and code generation are configured independently, so you can point the heaviest step at your strongest option and a cheaper one at the lighter steps. Because you're calling your own keys, you control the spend and the data path directly. fromSpec isn't reselling you tokens with a margin on top, and it isn't a fixed-provider product you have to take or leave. As models improve, you swap the one you point at and the pipeline doesn't change.

spec generation      →  your own provider   fast & inexpensive
preview generation   →  your own provider   cheap, fast UI
code generation      →  your own provider   strongest, correctness matters

You own what you generate

For technical users, ownership is non-negotiable. The generated code is yours. There's no runtime tether to fromSpec, your app doesn't phone home, and it doesn't stop working if you stop using the tool. Push the code to your own GitHub repo, run it under docker compose up, deploy it on your own infrastructure. fromSpec compiled the project. It doesn't hold it hostage.

Who it's not for (honestly)

• Non-technical users who want to avoid code entirely. The whole model assumes you'll read and own a real codebase. If you never want to see the code, this is the wrong tool.
• Throwaway one-offs where structure is overhead. If you genuinely just need a disposable script, the spec-first discipline is more process than the task deserves.

That narrowness is deliberate. fromSpec is sharp about being a structured pipeline for people who build software and want to keep building it: developers and technical founders who'd rather skip the boilerplate than skip the control.