How I Got Tired of Switching Between Five Developer Tools and Built One Workspace Instead

Every backend developer has probably experienced this.

You open DBeaver to inspect a PostgreSQL database.

A few minutes later you need to upload a file, so you open WinSCP.

Then you SSH into the server using PuTTY.

Now you need to check whether an email service is working, so you open another SMTP testing tool.

Later you browse an S3 bucket using yet another application.

None of these tools are bad. In fact, many of them are excellent.

The problem is that they’re all separate.

For years I accepted this as normal. If I wanted to work on a backend project, I simply expected to have five or six desktop applications open simultaneously.

Eventually I started asking a simple question.

Why?

Why does modern backend development still require so many disconnected tools?

The Daily Context Switching Problem

Switching applications sounds like a small inconvenience.

It isn’t.

Every time you change tools, you also change your mental context.

Different shortcuts.

Different interfaces.

Different credential stores.

Different update cycles.

Different windows spread across multiple monitors.

The more infrastructure you manage, the worse it becomes.

A simple debugging session might involve:

• PostgreSQL
• Redis
• MongoDB
• SSH
• S3 storage
• SMTP
• Local AI tools

That’s not unusual anymore.

Yet most software still solves only one of these problems.

Existing Tools Solve Individual Problems

Database clients are good at databases.

SSH clients are good at SSH.

S3 browsers are good at S3.

SMTP tools are good at email testing.

But modern developers rarely work with just one technology.

We work across infrastructure.

Instead of needing better individual tools, I started thinking about needing a better workspace.

A Different Approach

Instead of building another database client, I decided to build a desktop workspace.

One application where I could:

• Connect to PostgreSQL, MySQL, MongoDB, Redis and LibSQL
• Browse S3 buckets
• Use SFTP
• Connect over SSH
• Test SMTP
• Keep credentials encrypted locally
• Use AI with my own API key instead of sending data to someone else’s servers

The goal wasn’t to replace every specialized tool.

It was to replace the workflow of constantly switching between them.

Local First Matters

One thing I cared about from the beginning was privacy.

Many developer tools increasingly depend on cloud services.

For infrastructure work, that isn’t always desirable.

Credentials are sensitive.

Database URLs are sensitive.

Server information is sensitive.

I wanted credentials to stay encrypted on my own machine instead of being stored on someone else’s servers.

For AI features, I chose a Bring Your Own Key model.

Developers use their own API provider and keep control over both costs and data.

The Biggest Lesson

Building the software turned out to be easier than explaining it.

When people hear “database tool,” they immediately compare it with DBeaver or DataGrip.

But that’s not really what I built.

The idea wasn’t another SQL editor.

The idea was reducing context switching for backend developers.

Sometimes the biggest productivity gain isn’t adding more features.

It’s opening fewer applications.

What’s Next

The project is still evolving, and I’m continuously adding features based on feedback from developers.

If you’re someone who regularly works with databases, servers, cloud storage, and backend infrastructure, I’d genuinely love to hear how you manage your workflow today.

Do you also find yourself constantly switching between tools?

Or have you found a better way?

The application eventually became Nexoxa Bridge, a local-first desktop workspace for databases, infrastructure, and developer workflows. If you’d like to see what I’ve been building, you can check it out here: https://asteron.nexoxa.com