DEV Community: Ancer

GUI or CLI? Why We Built Both

Ancer — Sat, 27 Jun 2026 09:00:00 +0000

Software developers love debating interfaces.

Some people will always prefer a graphical interface, while others feel most productive inside a terminal window. The interesting part is that both groups are usually trying to solve exactly the same problem—they just have different workflows.

While building Convertim, we quickly realized that choosing one approach over the other would unnecessarily limit the tool.

For many users, drag and drop is simply the fastest way to work. Open the application, select a folder, choose the output format and click a button. No commands to remember, no documentation to read, and no setup required.

But developers and power users often have completely different needs.

They want to integrate image conversion into scripts, CI pipelines, automation tasks or batch jobs that run without human interaction. For them, opening a graphical application would only slow things down.

Instead of deciding which audience was "right", we decided to support both.

The graphical interface focuses on simplicity and discoverability, making common tasks accessible with just a few clicks. The command-line interface, on the other hand, exposes the same processing engine in a way that can be scripted and automated.

Neither interface is better than the other.

They simply solve different problems.

Good software should adapt to the user's workflow instead of forcing the user to adapt to the software. Whether someone prefers clicking buttons or writing commands shouldn't change the capabilities they have available.

In the end, both interfaces share the same goal: making image conversion as simple as possible while staying fast, local and predictable.

Sometimes the best engineering decision isn't choosing between GUI and CLI.

It's refusing to make users choose.

What about you? When a tool offers both options, which one do you reach for first: the GUI or the terminal?

Building Convertim: The Engineering Decisions Behind It

Ancer — Wed, 24 Jun 2026 09:00:00 +0000

When we use a piece of software, we usually focus on what we can see: the interface, the available features, or how quickly it gets the job done. In reality, much of a product's quality depends on everything the user never notices.

The chosen architecture, the way the code is organized, the dependencies that are included, the way errors are handled, or even the decision not to implement a certain feature often have a much greater impact than visible changes to the interface.

While building Convertim, we've made hundreds of small engineering decisions. None of them are particularly impressive on their own, but together they define the final experience of the product.

One of the earliest decisions was to keep all image processing local. From a technical perspective, it would have been easier to rely on remote services or external APIs for some conversions. But that would have required sending user files to a server. We preferred taking on additional engineering complexity to ensure that images never leave the user's computer.

We also wanted to avoid unnecessary installation steps. Many applications require setup wizards, administrator permissions, or additional components before users can even get started. Convertim follows a different approach: a single portable executable that can be launched and used immediately. Achieving that level of simplicity required considerable work behind the scenes, but it creates a much smoother experience for the user.

Another important decision was designing the application around batch processing from the very beginning. In real-world workflows, people rarely convert a single image. More often, they work with entire folders, photo collections, or website assets. That's why a large part of the internal architecture is built around job queues, concurrent processing, and scalable workflows without making the interface more complicated.

We also invested significant time in aspects that rarely appear in screenshots: project structure, separation of responsibilities, and long-term maintainability. It's invisible work, but probably one of the most valuable investments any software project can make. Features evolve over time; a solid architecture remains.

The same applies to automated testing. No user chooses an application because it has hundreds of tests, but those tests allow the product to evolve with confidence, catch regressions before release, and reduce the risk of unexpected bugs. They are an investment in the future, even if users never notice them.

Software engineering is often associated with using the latest technologies or following the newest industry trends. Our experience has been almost the opposite. The best decisions usually involve removing complexity, reducing unnecessary dependencies, and choosing solutions that will still be easy to understand and maintain years from now.

In the end, building useful software isn't just about adding features. It's about making hundreds of small decisions that make the product faster, simpler, more maintainable, and more respectful of the people who use it.

And interestingly enough, when those decisions are the right ones, users rarely notice them. They simply feel that the software works exactly as it should.

Why Useful Software Removes Friction

Ancer — Sat, 20 Jun 2026 09:00:00 +0000

When we think about improving software, our first instinct is usually to add something new. A feature, an integration or another configuration option often feels like progress.

But after building different products, I've come to believe that the best software improves by removing things instead of adding them.

Every unnecessary click interrupts a workflow. Every extra screen, mandatory account or confirmation dialog adds a little more friction to the user's experience. None of these decisions seems important on its own, but together they make a tool feel heavier than it should.

The applications I enjoy using the most are the ones that stay out of the way. They let me focus on my work instead of forcing me to think about the software itself. That kind of simplicity is rarely accidental—it comes from understanding the real problem and having the discipline to avoid unnecessary complexity.

As developers, it's easy to measure progress by the number of features we ship. But maybe a better measure is how much complexity we've managed to remove for the people who use our products.

In the end, the most useful software isn't always the one that does the most. It's the one that solves a problem so naturally that you almost forget it's there.

What's a piece of software you admire because of its simplicity rather than its number of features?

Why I Started Building Convertim

Ancer — Wed, 17 Jun 2026 09:00:00 +0000

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.

Why ancer exists

Ancer — Thu, 11 Jun 2026 09:00:00 +0000

We live in a time when building software has never been easier.

Every week there’s a new framework, a new library, or a new trend promising to change the way we develop applications. Technology evolves at an incredible pace, and too often it feels like the priority is following the latest trend instead of solving a real problem.

But most businesses don’t need the latest trend.

They need tools that work.

They need systems that are reliable, maintainable, and capable of supporting their growth for years to come.

That idea is what led to the creation of ancer.

Not as a traditional agency or a factory of quick projects, but as a software studio where engineering and product thinking come before noise.

Software Should Solve Problems

The best software is rarely the most impressive.

It’s not the one with the fanciest animations or the one everyone talks about on social media.

It’s the one that quietly becomes part of everyday work.

The one that automates repetitive tasks.

The one that prevents mistakes.

The one that saves time without demanding attention.

When a tool achieves that, it stops being just an application and becomes part of the workflow.

And that’s exactly the kind of software we want to build.

Architecture Matters from Day One

There’s a simple idea that reflects a common reality in software development:

The easiest software to build is often the hardest to maintain.

Many projects are created with only one goal in mind: shipping as quickly as possible. Everything works—until new requirements, new customers, or new processes arrive.

That’s when the problems begin.

Every change breaks something else.

Every new feature takes longer than expected.

Maintaining the product becomes increasingly expensive.

At ancer, we believe good architecture isn’t about making a project more complex.

It’s about making decisions today that will allow the product to keep evolving five years from now.

Choosing Technology for Stability, Not Popularity

We don’t chase every new technology trend.

We prefer mature, stable, and well-supported tools.

Technology is a means, not an end.

Choosing a framework simply because it’s popular is rarely the right decision for software that is meant to last.

We’d rather build on solid foundations than on short-lived trends.

Because maintaining a system for years is far more important than impressing people for a week.

Thinking in Products, Not Projects

Software development is often treated as a checklist.

Features get implemented, the project gets delivered, and everyone moves on to the next one.

We prefer to think in terms of products.

How they’re used.

How they evolve.

How they can continue creating value years from now without being rebuilt from scratch.

That means investing time in architecture, performance, user experience, and maintainability.

Things that rarely stand out in a demo but make all the difference once a product is in production.

This Is ancer

ancer was created around a simple idea:

Build useful software.
Web applications.
Internal business tools.
Automation.
Desktop applications.
System integrations.
Software designed to solve real problems and remain useful over time.

We’re not trying to build dozens of products.

We’d rather build a few and build them well.

The Beginning

This is only the first step.

Over the coming weeks, we’ll be sharing projects, technical decisions, lessons learned, and part of the development process behind them.

Because we believe good software doesn’t need to exaggerate what it does.

It simply needs to do its job well.

And that’s exactly what we want ancer to represent.