How We Decide Which Tool to Build Next

We get occasional suggestions for new tools, and it's worth explaining the actual filter we run every idea through before deciding whether to build it.

The first question: does it only need public data?

This is the non-negotiable one. If a proposed tool would require accessing anything behind a login — private accounts, direct messages, anything not visible to a logged-out visitor — it's rejected immediately, regardless of how useful it might otherwise be. This single filter eliminates a surprising number of the ideas we hear, because a lot of genuinely appealing feature requests quietly assume access to non-public data.

The second question: can it work without an account?

If an idea only makes sense with saved history, personalized settings, or anything that requires knowing who you are across visits, we're skeptical by default. It's not an automatic rejection, but it raises the bar significantly, because avoiding accounts is a deliberate constraint we've written about elsewhere, not an oversight.

The third question: is this a real, recurring problem?

We try to distinguish between "this would be neat" and "people keep running into this specific friction." The five tools that exist today each map to a distinct, concrete need — reading a post caption, reading a reel caption, checking a profile picture, saving a profile picture where permitted, and reading a bio. Each solves one clear thing. An idea that's really just a minor variation on an existing tool, rather than a genuinely separate need, usually doesn't get built as its own thing.

The fourth question: does it fit the tone of the site?

Even an idea that passes the first three filters might not fit if it nudges toward something more aggressive than what Instaustad is meant to be — closer to a growth-hacking tool than a reference tool, for instance. We're deliberately narrow in scope, and staying that way is a choice, not a limitation we're waiting to outgrow.

What happens to ideas that don't make the cut

We don't build a "maybe someday" backlog that quietly grows forever. If an idea fails one of these filters, it's a genuine no, not a deferred yes. We'd rather be honest that something isn't coming than let a suggestion sit in limbo indefinitely.

Anyone can say "we thought about it and decided not to." Explaining the actual criteria means you can predict, reasonably well, what we will and won't build next, which feels more useful than a vague promise to "keep listening to feedback."