Why I Started Building Convertim

Over the years, I've used dozens of image converters.

Some were fast. Others supported an impressive number of formats. Many were free, at least to a certain point. But almost all of them shared one thing that never really made sense to me: converting a local file meant uploading it to someone else's server.

That might seem perfectly normal today. We've become used to doing almost everything through the browser. But the more I thought about it, the less logical it seemed.

Why should something as simple as changing an image format require sending that file across the internet?

Most of the time I just wanted to convert a PNG into WebP, optimize a few screenshots or prepare images for a website. Nothing particularly complex. Yet the workflow was always the same: open a website, accept the cookie banner, wait for the upload, wait for the processing, and finally download the result again.

It wasn't only about privacy.

It was about friction.

Every extra step makes a tool a little bit worse.

That simple observation eventually became the starting point for Convertim.

The problem was never image conversion

Building another image converter didn't sound particularly exciting. There are already hundreds of applications capable of converting files in a matter of seconds. The interesting part wasn't the conversion itself, but the unnecessary complexity that had slowly grown around such a simple task.

We've accepted as normal the idea of opening a website, uploading personal files, trusting that they'll be deleted afterwards and downloading them again a few seconds later. All of this for an operation that any modern computer can perform locally almost instantly.

What's surprising is that very little of that complexity actually benefits the user. It's simply the way these tools have evolved over the years. We assume that an internet connection is always available, that sending private files to external servers is acceptable or that creating an account is just another small inconvenience we have to live with.

The more I looked at that workflow, the more obvious it became that image conversion wasn't the real problem. The real problem was all the friction surrounding it.

The philosophy behind the project

When I started building Convertim, I wasn't trying to compete with large online services or create the converter with the longest feature list. My goal was much simpler: to build the tool I wanted to use every day.

I wanted to launch an executable, drag a few images into it, choose the output format and continue with my work. No accounts. No ads. No popups. And most importantly, without my files ever leaving my own computer.

A tool that simply does its job and gets out of the way.

I believe that's one of the defining characteristics of well-designed software. The best tools aren't the ones with the most features. They're the ones you barely notice because they remove work instead of creating more of it.

Fewer features. Less friction.

Software development often revolves around adding new functionality. Every release introduces more options, more settings and more configuration screens, as if a product's value could be measured by the number of buttons in its interface.

But we rarely ask the opposite question: what could we remove?

Every unnecessary click, every avoidable wait and every external dependency adds a small amount of friction to the user's workflow. Reducing that complexity is usually much harder than adding another feature, but the impact on the overall experience is often far greater.

That's the principle I tried to follow while building Convertim: simplify the workflow until only the essential remains.

Building the kind of software I want to use

Convertim exists because I needed a tool like this myself. It wasn't born from market research or a business opportunity. It came from repeatedly facing the same small annoyance during everyday work.

That doesn't guarantee it will become a successful product. But it does mean that every design decision, every feature and every improvement is trying to solve a real problem that I've experienced firsthand.

In the end, that's also the philosophy I try to apply to every project I build. Not creating software to impress people with endless features, but building tools that respect the user's time and remove unnecessary friction.

Because the best software isn't the one that gets your attention.

It's the one you forget is even there while you're getting your work done.