u/GuaranteePotential90

working on a pricing page redesign for a SaaS product and stuck on a pretty fundamental question: how do you actually decide what the "segments" on your pricing page should be?

by segments i mean the lens you split your plans by — could be audience type (individual vs team), usage volume (light vs heavy), commitment level (trial vs production), or just no segmentation at all and showing everything flat. some products do this with literal tabs, some just visually group cards, some don't segment at all and let the buyer scan everything.

a few examples of what i mean, for products that clearly made a deliberate choice here:

• linear / notion: individual vs team as the main toggle, seems to map well when team size is genuinely the thing that changes between tiers
• stripe : mostly flat, no real segmentation, just a long feature comparison, seems to work because their buyers already know what they need
• vercel / render (infra-ish) : hobby vs pro vs enterprise, feels more like a maturity/commitment ladder than audience type
• some usage-based apis : segment by volume tier, which is honest but kind of unsexy to a first-time visitor compared to "are you a team"

questions for people who have actually worked on this:

1. how did you decide which axis to segment by? did you look at your own plan data first (like "what actually changes between our tiers") or start with a narrative you wanted to tell and design plans to fit it?
2. do you prefer literal tabs (hide some plans until clicked) or a single page with visual hierarchy (everything visible, just sized/positioned differently)?
3. any segment framing you've seen that seemed clever but didn't actually convert better than just showing things flat?
4. for products where the "natural" axis isn't audience type (e.g. it's actually just usage volume or feature depth), how did you find language for that, that didn't feel as dry as "light/medium/heavy usage"?

not looking for a "just copy x" answer, more interested in how people reasoned through picking the axis in the first place, with real examples if you've got them

https://preview.redd.it/iqp1hbyizo7h1.png?width=1832&format=png&auto=webp&s=aeb219bd1a81a4082eaa178edd0931b66ec89b66

Been working on an open-source API client, and wanted to share an approach we have been exploring.

One of the main reasons we started this was frustration with legacy API tools like Postman. Over time they have become super bloated and opinionated, and they don’t reflect how developers actually want to structure workflows.

We wanted something more intuitive, composable and programmable, even if that comes with a learning curve. Examples: Obsidian and Notion.

What it mans practically is that instead of a traditional request builder UI (forms, panels, saved requests), the frontend is built around a Markdown-based programmable document.

API requests, docs, and scripts live inside the same .void files and are rendered + executed directly in the editor.

So rather than filling out UI forms, you are working inside a single file that is also executable.

This approach is more flexible, but also:

• less immediately familiar than tools like Postman, Insomnia etc.
• closer to “programming the interface” than using a GUI
• requires a bit more learning upfront

But in return, you get full composability and everything lives in version-controlled files.

Here is the tool: https://voiden.md/

The repo: https://github.com/VoidenHQ/voiden

questions:

• Would you prefer a flexible but programmable UI like this over traditional API clients?
• Where would you draw the line between power and simplicity in frontend tools?

https://preview.redd.it/reqly119il7h1.png?width=2810&format=png&auto=webp&s=7f4de2b78eb6da4fce16774b055b808110c0d3eb

Voiden is live on PH: https://www.producthunt.com/products/open-source-offline-api-client?launch=voiden-api-work-but-done-better

There are two things I want to ask:)

- If you are a developer or working with devs, QA or technical writers working with APIs, please share them the tool. Its meant to be an alternative to Postman that doesnt need a login and that treats API work like files, with reusable blocks.

- You can also simply support the launch and help the tool get in front of the eyes of more people that will need it!

Cheers!

Hey folks,

Built Voiden, an API tool to build, test, document and collaborate on APIs offline.

Most API clients I know of seem to be built for a different job than what most teams actually do. For example, in my team, we live on Git, our communication is happening on slack, our docs are written (and maintained) on confluence and after some time they always drift away from the actual requests inside Postman.

This is the reason behind the tool. The goal is to combine the flexibility of Obsidian-style files with the simplicity of curl. Recently someone also said it looks like Jupyter files+curl.

Features:

• Everything (specs, tests, docs) can be composed with blocks (endpoint, auth, params, body) that can be added, reused, overridden, and stitched together across executable markdown files. 
• REST, GraphQL, Web-sockets, gRPC supported
• We thought it was wild that all tools kept scripting in a thin JS sandbox. Voiden runs locally so scripts run in real runtimes: JS, Python, shell (and more being added).
• Multiple requests in a single .void file. You can group full flows together (create-pay-confirm), or full CRUD cycles. The file becomes an executable workflow where docs and tests live together naturally, and you can run one request or the entire sequence end-to-end. 
• CLI Runner to run directly from the terminal (now on beta).
• Added “skills” so tools like Claude or Codex can work directly with .void files using your own environment and subscriptions. Yeah, one of the perks of everything being file-based and Markdown-first. 
• Offline, Gt native, no accounts, no telemetry

This has been a passion project for over a year now, since open sourcing it has been super nice to see the community sharing ideas, suggestions and even contributions.

Built with Typescript and electron, licensed under the Apache License 2.0.

Here it is:

• GitHub Repo: https://github.com/VoidenHQ/voiden
• Download: https://voiden.md/download

One thing that I get sometimes is that the tool is so different from Postman or anything related so it takes some time to get used to. (Hey, at least no one is accusing us of copying).

Looking forward to feedback, thoughts and ideas on how to improve it further!

https://reddit.com/link/1tua8m5/video/pq8mtdsver4h1/player

Been thinking about this a lot lately. Most teams I worked with start with "just a few smoke tests" and end up with either a Postman folder nobody trusts or a half-broken CI suite that takes 20 minutes and everyone skips locally.

The thing that bit us hardest was slow tests, but mostly it was drift. Auth flows changed, env vars got renamed, someone added a required header, and suddenly the tests that "passed" were testing nothing because the setup steps silently degraded. We had to start treating request definitions, env config, and assertions as code that lives next to the service, not as artifacts in a separate tool. Once tests stopped being a parallel universe, the maintenance load dropped a lot, because PR reviews caught the breakage instead of a Monday morning slack thread.

The other thing that helped was being honest about what runs where. Fast feedback (single endpoint, one auth flow) stays local and runs in seconds. Chained flows and contract checks run in CI. Full end-to-end with real dependencies runs nightly or on demand. Mixing those tiers is what makes the suite feel like a tax.

Curious how others draw that line. Do you keep request definitions in the repo or in a separate tool, and how do you handle the auth/env setup without it turning into tribal knowledge?

Hey there,

Saw a similar post and I thought it was a good idea.

With some colleagues from a previous project we are working on a project called Voiden, its a new kind of API tool. The team is looking for contributors. Every Friday there is also an office hours session to discuss features, roadmap and help those starting out with OSS.

If this is interesting, pls join the discord community: https://discord.com/invite/XSYCf7JF4F
project repo: https://github.com/VoidenHQ/voiden

the main thing I am looking at is plugins: https://github.com/VoidenHQ/voiden/discussions/386

These are all ideas that could be useful. Feel free to pick one 😄

Thanks!

Bit of context first: I am a member of a 30 people+ team and most API clients we used felt like they were built for a different job than what we actually did.

Our team lives in Git, our communication is happening on slack, our docs written and maintained on confluence and after some time they always drift away from the actual requests inside Postman.

So we built and open sourced Voiden a few months ago: an API tool where all that: specs, tests, context and docs are always together in the same executable plain text file (markdown). We also made this Git native so that every change is versioned and tracked just like code.

The last change we have made is to add a Runner so that one can run the files directly from the terminal and CI/CD pipelines.

here is the tool: https://voiden.md/download

repo: https://github.com/VoidenHQ/voiden

So my main request is for Postman or Insomnia or other legacy API tool power users. Does this resonate and fit your workflows? Anything that you would consider or suggest adding?

https://preview.redd.it/tqcvszb5hg2h1.png?width=1666&format=png&auto=webp&s=3df8b8838c68c97243949d999c8d8bbf0578a31d

Bit of context first: I am a member of a 30 people+ team and most API clients we used felt like they were built for a different job than what we actually did. Our team lives in Git, and our docs always drift away from the actual requests inside Postman. The fear I kept hearing when discussing with the team and other devs was "I don't need another bloated API tool".

So we built and open sourced Voiden a few months ago: an offline API tool where requests live as executable markdown and are versioned in Git. 

https://preview.redd.it/9613dvtco32h1.png?width=2954&format=png&auto=webp&s=ff0a505f252717da18d2dad7f0232045166ba6d6

The original idea and inspiration is to combine the flexibility of Obsidian-style files with the simplicity of curl. The result is a tool in which everything can be composed with blocks (endpoint, auth, params, body) that can be added, reused, overridden, and stitched together across executable markdown files. 

Results so far: Since open sourcing, we got +12K installs, +1K stars on github plus a lot of feedback and contributions.

What it does today:

• REST, GraphQL, gRPC, WebSockets (as plugins, install only what you need)
• Ability to compose Requests with API blocks. Reuse, Replace & Version everything just like code.
• Postman and OpenAPI import so you don't redo years of work
• Built in terminal
• Pre/post request scripting in JS, Python or Shell
• A batch runner for chaining .void files with env selection and stop-on-failure
• Agent-friendly CLI, works with Claude and Codex skills
• We have also a few features in early access, such as the (much anticipated) CLI runner
• +more

Looking for feedback and ideas from anyone interested.

Getting started: You can import your Postman collections and openAPI specs: https://docs.voiden.md/docs/getting-started-section/getting-started/postman-import/

Github: https://github.com/VoidenHQ/voiden

Download: https://voiden.md/download

Spent about two years watching our own API work drift across four tools. Requests in Postman/Insomnia, docs in Notion, decisions buried in Slack threads, and a Git repo that knew nothing about any of that. Every time someone asked "is this endpoint still right?" we had to check three places and usually one of them was wrong.

So we stopped trying to glue them together and built the thing we wanted: an API client where requests, tests and docs live in the same plain executable markdown files inside the repo, composed from reusable blocks (endpoint, auth, params, body), runnable from the editor or CLI, offline, no account, no cloud sync.

Open source: https://github.com/VoidenHQ/voiden

https://preview.redd.it/fmdpwxk8rv1h1.png?width=1658&format=png&auto=webp&s=61521adc0753eb98aa1519f0854cae2bd21ac217

The bet is that if API work is just text in Git, it stops drifting because PR review catches it the same way code review does. Our first users, already crossed 11k installs, are mostly backend folks who were already fighting Postman's collection format in their repos.

The part I am still figuring out is positioning. Half the devs I talk to immediately get it because they have felt the drift. The other half say "curl and a README work fine" and they are not entirely wrong for their stage.

How have you handled selling a workflow tool to people who think their current workflow is fine? Do you lean into the pain stories or just wait for them to feel it themselves?

hey to everyone,

This open-source tool recently reached 1K GitHub stars and around 12K installs. Sharing here in case its useful to other TypeScript devs. It’s fully free and open source.

Its an offline API devtool and what is special about it is that requests live as executable markdown and are versioned in Git. 

Just to give a bit of a background, the inspiration is Obsidian-style files and curl. As opposed to to other tools I have used, everything in Voiden can be composed with blocks (endpoint, auth, params, body) that can be added, reused, overridden, and stitched together across executable markdown files. 

Since open sourcing, got a lot of feedback, ideas and contributions and most of the stuff added comes from this feedback: chaining requests, scripting, and structuring everything into reusable .void files. So mainly workflow stuff. The next big item we are looking to add is the CLI runner (maybe its one one of the things I hear more).

A bit of context for the workflows:

Scripting: I want to highlight this one cause in other API tools scripts live in a constrained JS sandbox. In Voiden nope. Since it runs locally, we were able to flip that and allow scripts to run in real runtimes: JS, Python, shell (and will add more).

Multiple requests per file (mini workflows): Putting multiple requests in a single .void file was an idea from a user. You can group full flows together (create-pay-confirm), or full CRUD cycles. The file becomes an executable workflow where docs and tests live together naturally, and you can run one request or the entire sequence end-to-end. 

Stitch (workflows across files): This is our take on the collection runner. Workflows (“Stitch”) are built from .void files that you can combine across scenarios. You define small flows (auth, setup, CRUD, etc.) and stitch them together into larger workflows (without duplications).

Agents: Added “skills” so Claude or Codex agents can work directly with .void files using your own environment and subscriptions. Yeah, one of the perks of everything being file-based and Markdown-first. 

+ We also built an SDK for community plugins and spent time improving performance, reliability, and keyboard-first DX (Electron-based, so we have been careful there).

For those that work with Postman or Swagger I wanted to make it easy to import and try this: https://docs.voiden.md/docs/getting-started-section/getting-started/postman-import/

Looking for feedback and ideas from anyone interested.

Github: https://github.com/VoidenHQ/voiden

Download: https://voiden.md/download

https://i.redd.it/om296279r21h1.gif

Hey there,

Built and Open Sourced Voiden, an offline API tool that we originally built to replace Postman internally in our team.

This is not a vibe-coded tool (although yeah we do use AI), but we recently added something that might be useful if you are building things with Claude or Codex.

https://reddit.com/link/1t66l0j/video/yc8ab78ezozg1/player

When you build and vibe code apps or tools, you often need to connect to other services, for example:

• logging users in
• fetching data from a database or a third-party service
• sending updates somewhere (like saving a profile or posting content)
• many other cases

These connections usually happen through APIs, so you need to test that their endpoints actually work.

For example:

• does login actually succeed and return what you expect?
• does a full flow like login → fetch data → update something → delete it actually work end-to-end?
• can you rerun the same sequence without manually clicking around every time?

This is the gap Voiden tries to close with AI skills, giving your agents a small “understanding layer” for testing APIs.

Once enabled, Claude or Codex can understand how API workflows are built, so they can work with full flows instead of isolated requests.

In practice, this means:

• you can build full API flows, not just single calls
• AI can modify or improve existing test setups instead of rebuilding them
• your API tests stay structured so you can rerun them

So instead of “generate a request and hope it works”, it becomes “build a flow you can actually rerun and trust”.

Especially helpful if you are new to APIs, because it makes them feel like simple step-by-step workflows instead of low-level technical calls.

It’s free, offline, and has no telemetry.

welcome to try and let me know your thoughts!

Repo: https://github.com/VoidenHQ/voiden
Download: https://voiden.md/download

Hey hey,

So I have a kind of a theoretical question. So one of the things I liked about md files is that they can be used for almost everything. Also, while building Voiden (an API IDE) it was mainly Obsidian and other markdown based tools that inspired me. Ok for my case, it was also curl.

Now lets go the main thing: One thing that turned out surprisingly easy is how friendly it became for agents. This was admittedly not intentional from day one since I didnt build it with agents in mind, I was mostly focusing on devs and qa folks. However, it was a nice add on.

Now, I keep seeing some comments and statements that markdown is more for human and json is the agentic language.

Also here: https://www.reddit.com/r/BlackboxAI_/comments/1sun5jq/companies_are_actively_stopping_writing/

What is your take? I find it strange but wanted to get some opinions from experts.

https://preview.redd.it/bquydfqbdhzg1.png?width=876&format=png&auto=webp&s=83d3c545c56c4fd5c58fae8ec099b88371dfbdef

https://preview.redd.it/4k1v7y3ea6zg1.png?width=1606&format=png&auto=webp&s=8c9183d586e1f84dfc8f4e389e381b153100d1bb

Repo: https://github.com/VoidenHQ/voiden

download: https://voiden.md/download

This is basically an API IDE, free and open source, for developers who want something simple, flexible and that adapts to how they already work.