Building Noodle, a keyboard-first REST client for the terminal
I launched Noodle, a keyboard-first REST client for the terminal.
The idea started from a very personal frustration. I wanted API requests to live as files next to my projects, but I also wanted something more comfortable than maintaining a pile of curl commands. Existing desktop tools can be great, but I kept opening one for a quick request and then going straight back to the terminal.
So I built Noodle around YAML files on disk. A collection is a directory, a request is a .yml file, and the TUI sits on top to help browse, edit, send, and inspect requests.
The first release had the basics. Since then, I have been filling in the gaps that made the workflow feel incomplete:
- Command palette, collection switcher, and fuzzy request finder
- YAML and JSON editing with validation, folding, and variable completion
- cURL import and client code generation
- JSONPath response filtering
- Automation commands for running and auditing collections
- A documented skill for coding agents to work with Noodle collections
The biggest lesson so far is that the project is not competing on feature count yet. Tools like Postman, Insomnia, Bruno, Posting, and Yaak all have strengths. The reason I am continuing with Noodle is narrower: I care about a local, keyboard-first workflow where the requests remain ordinary files that can live in Git.
I am trying to be honest about what is still missing. Scripts, assertions, request chaining, export, OAuth, and a batch collection runner are all still ahead on the road to v1.
The next challenge for me is distribution. I can keep building features, but I need to learn whether this workflow solves a real problem for enough people beyond my own terminal.
If you have launched an open-source developer tool, I would love to hear how you found your first users and how you decided which feedback to prioritize.
A longer update with screenshots and the roadmap to v1:
https://noodlerest.dev/blog/what-changed-since-noodle-launched/
Bruno already proved your market exists: its growth story was developers fleeing Postman's cloud sync, and 'requests are plain files in Git' was the hook. So don't frame Noodle as a REST client with a TUI, frame it as the Git-native option for people who live in the terminal, and recruit users directly from the threads where developers complain about Postman pricing and sync. Your first hundred users are already complaining in public, you just have to go find them.
The ordinary-files-in-Git constraint is the strongest part. I'd put a one-command curl or Postman import ahead of adding more request features, because migration friction can kill the trial before someone even feels the keyboard-first workflow. I ran into a similar lesson building DictaFlow: fitting into the place people already work mattered more than piling on features. A tiny demo repo with real requests, env files, and a pull request diff would probably sell Noodle better than a feature matrix.
I like that you're optimizing for a specific workflow instead of trying to out-feature every existing REST client.
I'll be interested to see which part users keep coming back for after the initial trial. That usually reveals whether the product is really about being keyboard-first, file-based, or simply fitting more naturally into a developer's existing workflow.
That is the question I am trying to answer too. My current guess is that the combination matters: the files make the workflow fit Git, and the keyboard-first interface makes it practical to use every day.
The clearest signal will probably be whether people keep their collections in real projects and come back to run and update them regularly. That is what I want to learn from the next group of users.
That makes sense.
The interesting signal will probably be whether the workflow becomes part of how developers structure their projects, rather than just another tool they occasionally open.
That repeated integration into existing habits is usually where the strongest retention comes from.
Requests as plain YAML files that live in git is the right call, that is the same reason people put up with a terminal tool over a GUI one, the files being real and diffable beats convenience every time. On first users, the ones who stuck for me came from people who already lived in the terminal and were annoyed by exactly the workflow you are describing, not from broad marketing. Distribution past that group is the real problem though, that audience is small and vocal but it does not scale on word of mouth alone, so I would rather over invest in the handful of terminal native corners of Reddit and HN than try to make the pitch legible to GUI users who were never going to switch anyway.
That matches what I have been thinking. I probably need to focus on people who already prefer terminal and Git-based workflows instead of trying to convince GUI users to switch.
The roadmap is still about filling in the gaps around that workflow, with export and import, scripting, testing, and collection automation coming next. I’ll pay attention to which of those terminal users actually ask for, rather than assuming the priorities myself.
Your clarity on the wedge is the best thing here, and rare: "requests are ordinary files that live in Git" is genuinely differentiated against Postman/Insomnia, and you already know not to compete on feature count. Most founders can't articulate their wedge that cleanly. So the distribution question has a sharper answer than "find users."
A Git-native, keyboard-first, files-on-disk REST client has an ICP that isn't "developers." It's a specific tribe: terminal-maximalist devs who live in Neovim/tmux, version-control everything, distrust Electron GUIs, and feel friction every time they leave the terminal for Postman. Small, sharp, highly reachable, and they cluster in specific places. You don't need broad distribution, you need to reach that tribe.
Where they are: r/neovim, r/commandline, Hacker News (Show HN, heavily this crowd), lobste.rs, the TUI/CLI tooling community, and adjacent tools (Bruno users chose it for the same Git-native reason, they've already bought the philosophy, just not keyboard-first, your warmest audience).
On prioritizing feedback: weight by whether it comes from someone already in your workflow vs someone asking you to become Postman. "Add a GUI" is someone who isn't your ICP asking you to abandon your wedge. A tmux/Neovim user asking about request chaining or Git-diff-friendly output is your tribe telling you what completes the workflow. Prioritize the second ruthlessly, politely ignore the first.
Which terminal communities have you posted in so far, and did any one convert better? That's your channel.
Thanks, this is really helpful. I had been thinking about "developers who work with APIs" as one big group, but the workflow is probably the better way to look at it.
So far I have only posted in r/coolgithubprojects, so I do not really have channel data yet. Show HN is next, and I want to try a few terminal and Git-oriented communities after that and see where people actually care.
Your point about feedback also lands. I do not want to build a smaller Postman just because someone asks for a feature. I need to figure out what is missing for people who already like keeping things in files and working in the terminal.
Thanks again, this gave me a much clearer direction.
The workflow-over-demographic reframe is the whole thing, glad it landed. One tactical note for Show HN since it's next and it's your highest-leverage single shot:
HN rewards the origin story and the wedge, not the feature list. The title and first comment should lead with the exact frustration you opened your IH post with, wanting requests as files next to your project, not a pile of curl, not another Electron GUI. That specific pain is what makes terminal people go "finally, someone gets it." Don't lead with "REST client for the terminal" (sounds like one of many), lead with "I wanted my API requests to live in Git as plain files, so I built a keyboard-first TUI." The Git-native angle is your hook, put it first.
One more: HN's terminal crowd will immediately compare you to Bruno and Posting. Get ahead of it in your own post, name them, say what you respect, and state the one thing you do that they don't (keyboard-first TUI + files-in-Git together). Naming competitors honestly reads as confidence and saves the top comment from being "how is this different from X."
The batch-runner and request-chaining items on your roadmap are the ones your actual tribe will care about most. Those are the "I do this in CI / I version my API tests" workflows that only the files-in-Git crowd needs. Worth prioritizing over OAuth, which is more of a GUI-user expectation.
Sharpening that Show HN wedge-and-positioning is the kind of thing I spend my time on, I'm part of the team building Hivemind, an AI strategy copilot. If you want to pressure-test the launch framing before you post, it's worth a try: https://hivemind.myosin.xyz. Either way, good luck, post Tuesday-Thursday morning US time when that crowd is most active.
Love the “requests as files in Git” angle. That’s a real wedge vs Postman/Insomnia, not just another feature race.
For first users on open-source tools, what usually works for me:
Hang in communities where people already complain about the pain (terminal workflows, API testing)
Reply to “alternative to Postman/curl” threads with the specific niche
Ship one demo-worthy gif/video of the keyboard flow
Prioritize feedback from people who already live in the terminal. Feature requests from GUI-first users will pull you off your wedge.
I built the Make it RAIN app for the distribution/monetization side after shipping, so this distribution question is close to home.
Curious where your first stars/users actually came from so far?
One thing worth separating out: feature requests vs. workflow requests. "Add OAuth support" is a feature ask — easy to prioritize by frequency. But "I want to chain this request into my CI pipeline" or "I want Noodle to diff cleanly in a PR review" are workflow asks — they tell you how deep into someone's actual process the tool has gotten, which is a much stronger signal than raw request volume.
Given your "coding agent skill" feature, I'd watch for a third category too: people asking for things not for themselves, but because their agent needs it (structured error output, predictable exit codes, etc.). That's a different kind of demand signal than a human user complaining, and probably worth tagging separately as you collect feedback.
The distribution angle is interesting - you've correctly identified that the terminal-first audience is small but specific. What might help: make it dead simple for someone who uses curl daily to stumble on Noodle. The "requests live in git as YAML files" message is powerful enough that it should sell itself to people frustrated with GUI tools, but they need to find it first. Have you considered reaching terminal tool communities directly (vim/neovim plugin ecosystems, shell scripting forums, the few dev communities that still use forums instead of Discord)? Those tend to be more discoverable than general tech communities.
The line that stood out to me is the "documented skill for coding agents to work with Noodle collections." That might end up being a bigger distribution lever than any human-facing feature. Files-on-disk plus YAML is exactly the shape an agent can read, edit, and replay without you building a bespoke API for it, and API testing/auditing is a task people are already delegating to agents. The terminal-native crowd is the right first audience for validation, like the comment above says, but the agent-skill angle might be the one that actually differentiates Noodle from Postman/Insomnia long-term, since those tools are GUI-first and much harder to make legible to an agent. Worth tracking separately whether any of your early adoption comes from someone wiring an agent into a collection rather than typing requests by hand.