Building Noodle, a keyboard-first REST client for the terminal - Indie Hackers

Join

Likes

Bookmarks

15<br>Comments

Report

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/

GitHub:

https://github.com/wilfredinni/noodle

Carlos Montecinos

posted to

Building in Public

on July 20, 2026

Share

Say something nice to wilfrredinni…

Post Comment

I think this is a real niche, great work.

Claude Code has shown this kind of UI is hip. Related - can you integrate with agents? Seems like an obvious point to have a skill/MCP/Local MCP so agents can use the tool.

Good luck!

david_papermill

34 minutes ago

Reply

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.

GregoryScottHenson

3 hours ago

Reply

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.

ryanshrott

2 hours ago

Reply

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.

aryan_sinh

20 hours ago

Reply

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.

wilfrredinni

20 hours ago

Reply

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.

aryan_sinh

10 hours ago

Reply

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...