DEV Community: Sara

Small shift in how I discover web apps

Sara — Thu, 25 Jun 2026 14:29:01 +0000

Lately, I’ve been trying to simplify how I find and evaluate web apps for side projects. Product Hunt and Google still help, but they can feel a bit noisy when you’re just looking for something specific or lightweight.

I recently came across a different approach: instead of browsing through generic lists, I found myself using a more “store-like” experience for web apps. It reminded me of how app stores reduce decision fatigue by giving structure (categories, quick previews, etc.), but applied to browser-based tools.

One example I stumbled on is Unstore. What stood out to me wasn’t just the catalog itself, but the idea of treating web apps like installable resources you can quickly explore and compare without digging through long blog posts or SEO-heavy landing pages.

It made me rethink how we surface tools to developers and indie makers. Discovery is still a bit chaotic on the web, and having curated, structured directories might be a small but meaningful improvement.

Curious if others are using something similar, or if you still rely mostly on search + bookmarks for finding new tools?

Maybe not every side project needs to be a SaaS

Sara — Wed, 24 Jun 2026 17:09:31 +0000

For a long time, I approached every idea the same way: “Could this be a product?”

Which usually meant jumping straight into: authentication, pricing, dashboards, onboarding…all before the core idea was even properly tested.

Lately, I’ve been trying something different. Just building small, single-purpose web apps.
Tools that:

solve one specific problem
don’t require accounts
are instantly usable
don’t try to be anything more than they need to be

And honestly, it’s been a much better experience. Faster to ship, easier to maintain, and often more useful.

The interesting part is: building these tools isn’t the hard part anymore. Distribution is.

Most of these apps end up:

buried in GitHub repos
shared once on social media
lost in bookmarks

Which makes them hard to rediscover, even when they’re genuinely helpful.

I’ve been thinking there should be a better way to browse and use these kinds of apps, almost like a lightweight layer on top of the web. Something closer to a web app store.

I came across Unstore while exploring this idea, and it’s an interesting take: a collection of small apps you can just open and use without friction.

Feels like it aligns well with how we’re starting to build: smaller, faster, and more focused.

The real bottleneck in dev workflows isn’t code, it’s tool discovery

Sara — Tue, 23 Jun 2026 15:16:54 +0000

We spend a lot of time optimizing our code, our stack, and our architecture.

But there’s a smaller friction point that shows up almost every day and rarely gets talked about: finding the right tool when you need it.

Think about how often you do things like:

format JSON
generate mock data
test an endpoint
convert file formats
validate something quickly

None of these tasks are hard. The tools exist. The problem is the gap between needing it and getting to it.

For me, that gap usually looks like:

Pause what I’m doing
Try to remember a tool
Open a new tab
Search
Click around until I find something “good enough”

It’s only a minute or two, but it breaks flow. And it happens multiple times a day.

I used to rely heavily on bookmarks, but that turned into a mess pretty quickly. Either I over-organized and never used it, or I stopped maintaining it altogether.

Recently, I’ve been trying a different approach: instead of storing tools, I rely on places that make them easy to rediscover on demand.

While exploring this, I came across Unstore, which takes a more browse-first approach to web apps. It feels less like a database and more like a lightweight layer where you can just open something useful and move on.

What I like about this idea is that it matches how we actually work. Most of the time, we don’t need “the perfect tool”, we need something that works right now without breaking momentum.

It made me rethink how much of productivity is really about speed vs. how much is about reducing friction between steps.

Curious how other devs handle this: Do you maintain a system for your tools, or just rely on search and memory?

Stop Collecting Dev Tools. Start Building a Stack You Actually Use.

Sara — Mon, 22 Jun 2026 15:20:52 +0000

If you’re like me, you probably have a growing list of useful dev tools somewhere:

a bunch of bookmarked APIs
random GitHub repos
utilities you saw on Twitter or Dev.to
that one tool you swore you’d use again

But here’s the reality: most of these never get used twice.

The real problem isn’t discovery

We’re great at finding tools.
Every week there’s:

a faster way to test endpoints
a better UI builder
a smarter AI dev helper

The problem is retention.

After a while:

you forget what you saved
you duplicate the same searches
you rebuild the same mini-stack over and over

What actually works: a living tool stack

Recently, I’ve been trying to treat my tools more like part of a system instead of a collection.
Instead of saving everything, I:

keep only tools I’ve actually used
group them by workflow (debugging, UI, deployment, etc.)
revisit and refine regularly

Think of it like maintaining a personal dev stack, just outside your codebase.

A simple way I’m doing this

I’ve been experimenting with the idea of a personal web app store, where tools are stored more intentionally rather than dumped into bookmarks.

One example is Unstore, which lets you organize and revisit tools in a way that feels closer to managing apps than links.
Not a game-changer by itself, but paired with the mindset shift, it helps.

The takeaway

You don’t need more tools.
You need a better way to keep the right ones around.

Why “No-Login” Apps Are Gaining Popularity

Sara — Thu, 18 Jun 2026 14:47:45 +0000

There’s a quiet shift happening in how web apps are being built.
More developers are creating tools that don’t require accounts: no signup, no onboarding, just open and use.

The Problem With Logins

“Create an account to continue” is still one of the biggest drop-off points.
Even with Google auth or magic links, users hesitate:

They’re not ready to commit
They just want to try something quickly
They don’t trust the app yet So they leave.

The Rise of Instant-Use Tools

We’ve all used these:

JSON formatters
Image compressors
Text tools

They solve a problem instantly: no friction.
Now developers are applying that same idea to more complex tools: small, focused apps designed for quick sessions instead of long-term retention.

Distribution Is the Hard Part

When you remove accounts, you also remove built-in growth loops.
No emails. No dashboards. No retention funnels.
That makes discovery the real challenge.

A Different Way to Surface Apps

Traditional platforms don’t fit well with these lightweight tools.
You don’t always need a full SaaS listing or a big launch, just a place where people can find and use your app.
That’s why I find platforms unstore interesting. They lean into this idea of quick, direct access to web apps without the usual overhead.

Closing Thought

Not every app needs users, accounts, and retention metrics.
Some just need to be useful instantly.
And maybe that’s where the web is heading again.

Why the web application discovery problem persists (and how to fix it)

Sara — Tue, 16 Jun 2026 15:47:14 +0000

After working with web apps for a certain amount of time, one thing is inevitable:
There are way more tools available out there, but somehow the process of discovering the good ones has become even more challenging.
There is no shortage of platforms for discovering the right tools:

Product Hunt
Lists of curated web applications
Blog posts about "top tools"
Twitter threads about recommended applications

Distribution vs Discovery

Initially, I thought that this would be mostly a distribution problem, in other words, a matter of getting visibility if your app is worth it.
However, after looking into the matter a bit closer, I started thinking that it could also be a discovery UX issue.
Most of the tools have the same approach to discovery as social media platforms do:

Chronological listings of launches
Upvoting mechanisms
Sections with trending items It helps with hype, but does not help when one needs to make an exploratory discovery.

But what if the browsing experience were made better for web applications?

There's one concept that seems to resonate with me more lately, which is thinking about web apps as something more structured than an endless series of launches.
A little bit more like browsing through the App Store:

Categories
Structure in navigation
A more coherent browsing process
A method that doesn't depend on luck and virality so much

Recently I've seen an interesting attempt at a concept called Unstore. The thing that impressed me there was not only the tools themselves but rather how they were sorted.

Importance of this concept, particularly for builders

As a builder, it may matter a lot.
Because currently:

Visibility depends a lot on timing
All visibility is focused on the most popular tools
Other tools have a hard time being remembered over time

With discovery being made more structured:

Less popular tools can rise on their own
Use cases are easier to discover
Longevity becomes more important than initial buzz

Open question

I am interested in hearing other perspectives on this issue.
Is this just a problem of distribution, of making yourself visible as a tool provider?
Or is discovery itself inherently flawed?
Where do you turn when you are looking for new tools?

I've quit bookmarking tools (and it surprisingly worked)

Sara — Thu, 11 Jun 2026 16:30:58 +0000

Until recently, I used to store every handy developer tool I discovered.
But at a certain point, bookmarking just stopped working for me. Too many URLs, no actual system, and there would never be a time when I actually checked those bookmarks.
A different approach which was more helpful for me turned out to be treating such tools not as bookmarks to check out, but rather as applications that can be revisited. Categorizing them according to their usage and having them handy helped me more than I could have ever imagined.
There are some quite intriguing approaches to this, for example using the browser as a kind of private app store (unstore.io comes to mind when considering such an approach).
Such a minor change in my mind helped me minimize unnecessary searches.
I would like to hear your take on this matter.

Rethinking App Stores for Developers

Sara — Mon, 08 Jun 2026 17:12:04 +0000

As developers, we’ve gotten used to app stores that are heavily curated, closed, or optimized for consumers rather than builders.
But lately, I’ve been thinking: what would an “app store” look like if it were actually designed for developers?
Most of what we build today lives on the web (internal tools, side projects, micro-SaaS apps, AI utilities) yet discovery is still fragmented. You either rely on social media, directories, or word of mouth.

The problem with current discovery

A few patterns I keep running into:

Great tools get buried quickly after launch
Distribution depends too much on personal audience
Many platforms favor polished products over experimental ideas
There’s no “default place” to browse useful web apps like we browse npm or GitHub

A small shift in thinking

Instead of treating every app like a startup launch, what if we treated them more like packages in an ecosystem?
That idea led me to explore platforms trying to approach this differently: more open, less gatekeeping, and focused on utility over hype.
One interesting example I came across is Unstore, which positions itself more like a “web app store” than a traditional directory. The idea feels closer to how devs actually work: browse, try, use, move on without friction.

Why this approach makes sense

Lower barrier to sharing: Not everything needs a full Product Hunt launch
Faster iteration: Apps can evolve without relaunch cycles
More visibility for niche tools: Especially useful in the AI and indie hacker space
Closer to developer workflows: discovery through usage, not marketing

Open questions

I’m curious how this category will evolve:

Will “web app stores” become a standard layer like package registries?
How do we balance quality vs openness?
What kind of discovery actually helps devs vs just adding noise?

Would love to hear if others are thinking about this too, or if you’ve found better ways to discover useful tools lately.

Revisiting Web App Discovery

Sara — Fri, 05 Jun 2026 16:25:21 +0000

Web applications continue to increase in number. But there’s still nothing systematic about the process of discovering them.

Most of these applications appear via channels that have a short lifespan, such as Product Hunt or various forms of social media. Either you discover them while they’re being promoted, or they never become part of your knowledge base.

The next thing I find myself asking is: why isn’t web application discovery like visiting an app store?
Considering that web applications exist solely in a web browser, having an easier way to browse them would make sense. This means having some form of categorization, the possibility of using search functionality, and discovering them without the need for them to be trending at any given moment.

I’ve seen one project doing exactly that. It’s called Unstore. The main premise behind it is simple and straightforward: discovery without noise.
Not a perfect solution, but definitely pointing in the right direction.

The difficulty of finding good web apps

Sara — Wed, 03 Jun 2026 15:05:21 +0000

Despite the huge number of tools available today, it’s still surprisingly inefficient to find the right web app.
Most discovery methods have not really changed. You either get search results dominated by SEO-heavy sites, or you’re scrolling through stale “top tools” lists, which are rarely accurate to what’s actually useful today.

The Problem With Discovery Today

Some patterns keep recurring:

The best tools are not always the most visible
Many directories seem bloated or stale
It's too much work to find niche or lightweight apps In reality, lots of good tools get buried, and mediocre tools get traffic.

What can help

Better discovery usually comes with experience:

Not huge directories but smaller, focused collections
Not just search, but browsing categories
Platforms centered around web-based tools instead of comprehensive SaaS ecosystems

A Small Change of Strategy

I’ve been considering more curated or niche aggregators than general-purpose lists recently.
One example is Unstore, which is focused on web apps only, so it’s easier and less noisy to browse than normal directories.
It feels more like browsing a lightweight “store” of tools than a massive catalog.

Open Question

As web apps proliferate, discovery is becoming less of a solved problem and more of a problem.
How do you currently find new tools that you actually end up using?

Why Is Finding the Right Web Tool Still Hard?

Sara — Mon, 01 Jun 2026 17:12:49 +0000

Something I've learned working on my own and exploring products: the issue is no longer about finding tools.
It's about finding the right tool.

The market for high-quality web applications has grown into a huge variety. New web tools are launched each week, but discovery still feels like a chaotic process. In the majority of cases, it requires accidental discovery or choosing the first search result on Google.

Until it stops working, that is.

Since landing pages are geared towards selling, not comparing, and once you open 4-5 tabs with similar options, choosing becomes surprisingly hard.

It seems that there is some fundamental thing we don't have in the ecosystem compared to others, and that fundamental thing is a more systematic way to explore tools.

Recently, I've been researching projects aimed at improving the experience of finding and choosing web applications by making the entire ecosystem more discoverable. One such project is Unstore. I'm not claiming it's the solution, but it's definitely worth a look.

At this point, having the ability to create an excellent tool is just the first step. The more important part is ensuring that users can find the tool.

And that problem remains unsolved.

The Hidden Element of Developer Productivity That Nobody Talks About

Sara — Thu, 28 May 2026 16:58:08 +0000

In conversations about productivity, here’s what everyone talks about:

Faster frameworks
Better tools
Good coding practices
Automation
AI assistance

There is, however, an aspect of productivity that people often overlook.
It quietly takes up most of our time.

The part that’s never measured

That’s not coding. That’s all the stuff that goes into writing code:

Searching for libraries
Evaluating different technologies
Researching alternative approaches
Reading documentation
Having twelve tabs open that you will never go back to again

That’s the invisible element of software development.
We underestimate it at our own peril.

The real constraint is not in the coding itself

In today’s world, writing code is not what takes the most time.
The time-consuming part is the decision: "What tool should I even be using for this?"

Options include:

10 authentication systems
15 UI frameworks
50 AI tools
Countless micro-tools

The issue here is not a lack of choice.
It is an abundance of choice without a proper filtering mechanism.

Decision fatigue is real

Each tool decision carries its own price tag:

Can this scale?
Is it maintained?
How’s the developer experience?
What trade-offs am I making?

Quick decisions take time to put into context.
Contextualizing decisions takes effort.
Effort means loss of focus. Loss of momentum.
Sometimes you can lose an hour just deciding.

This point is completely ignored in most workflows

We optimize:

build time
test coverage
deployments

But who optimizes: discovery, evaluation, and tool selection?
Despite being an aspect of every workflow.

What really helped me

This was not solved by being more disciplined.
My approach to finding and selecting tools changed.
Not through:

random Google searches
hopping between many GitHub repositories
creating an unorganized list of bookmarks

But rather by turning to more structured discovery.
Places where:

tools are pre-grouped for you
the categories make logical sense
you can skim fast without diving straight into something

For example, instead of starting from scratch, I may find myself browsing pre-made sets of tools on sites like Unstore. Not because it is “better” than anything else. Just because it's less effort.

What we’re looking for is not a perfect tool

But rather an acceptable tool that works quickly.
Perfection is expensive. Speed provides an edge.
An acceptable tool selected in five minutes is better than a perfect one chosen in two hours.

A small change that builds up

Since making tool discovery part of the process (rather than an auxiliary action), there have been some minor shifts:

Less tab swapping
More commitment to decisions
Higher output

Nothing major. It’s just smoother sailing. Time after time.

Key Takeaway

Developer productivity is not merely about writing code. It is about going from idea to decision to execution, most of which happens long before writing code begins.
This is the hidden side. And it deserves more attention.