The part that stood out to me wasn’t the terminal UI it was treating API requests as project assets instead of something that lives inside another app. That feels much closer to how developers already think about code.
Have you found people adopt Noodle because they want to stay in the terminal, or because they want their API requests to live alongside the rest of their project?
The strongest differentiator is probably not the terminal UI itself, though. It is that requests remain readable, version-controlled files instead of becoming data trapped inside another workspace.
I’d be curious how Noodle handles secrets and team environments. That seems like the point where a file-based workflow either becomes very powerful or very easy to misuse. A clean separation between shareable request definitions and local credentials could become one of the product’s best trust signals.
Treating API requests as standard files that sit right alongside your code in Git is a fantastic approach. Bridging the gap between clunky, heavy desktop apps and messy curl commands with a terminal-first client makes API testing feel super fluid without breaking developer flow. Awesome build!
"Delicious" for a dev tool — love the personality. But are you targeting terminal purists who'd never touch Postman, or developers who want to look cool in demos? The feature set looks the same, the ego hit is different.
5 Comments
The part that stood out to me wasn’t the terminal UI it was treating API requests as project assets instead of something that lives inside another app. That feels much closer to how developers already think about code.
Have you found people adopt Noodle because they want to stay in the terminal, or because they want their API requests to live alongside the rest of their project?
The strongest differentiator is probably not the terminal UI itself, though. It is that requests remain readable, version-controlled files instead of becoming data trapped inside another workspace.
I’d be curious how Noodle handles secrets and team environments. That seems like the point where a file-based workflow either becomes very powerful or very easy to misuse. A clean separation between shareable request definitions and local credentials could become one of the product’s best trust signals.
Treating API requests as standard files that sit right alongside your code in Git is a fantastic approach. Bridging the gap between clunky, heavy desktop apps and messy curl commands with a terminal-first client makes API testing feel super fluid without breaking developer flow. Awesome build!
"Delicious" for a dev tool — love the personality. But are you targeting terminal purists who'd never touch Postman, or developers who want to look cool in demos? The feature set looks the same, the ego hit is different.
The file-based workflow is an interesting constraint because it changes how API requests are managed.
What would convince you that developers are actively looking for this workflow, rather than simply accepting the tradeoffs of existing API clients?