DEV Community: Dominik Kopócs

You Don’t Need Another Productivity Tool

Dominik Kopócs — Sun, 30 Aug 2026 10:09:43 +0000

I like tools, probably more than I should. Task managers, note-taking apps, calendars, dashboards, automation tools, and workflow systems all promise some version of the same thing: less friction, better focus, more control. Sometimes they actually deliver it. The problem starts when the system designed to reduce work quietly becomes another system that needs work.

Every productivity tool introduces a maintenance cost. You have to learn it, configure it, decide what belongs there, keep it updated, and eventually integrate it with the rest of your workflow. None of this feels expensive in isolation, but systems accumulate. A task manager connects to a calendar, the calendar feeds a dashboard, notes are linked to projects, projects have tags, priorities, statuses, templates, recurring rules, and automation. Before long, you have built something surprisingly close to infrastructure.

Except this infrastructure exists to remind you to answer an email.

That is the point where productivity tooling starts becoming slightly absurd.

🕑 Optimization is not free

We tend to discuss productivity systems as if the only relevant question were whether they save time. But there is another cost that is harder to measure: cognitive maintenance.

Every system creates decisions. Where should this task go? Which tag should it use? Is this a project or an area? Should this note be linked to something? Why did this automation fail? Was this deadline updated everywhere it needs to be?

These are small questions, but small questions are exactly what productivity tools are supposed to remove. A system can therefore become technically efficient while making the workflow mentally heavier. The tool may work perfectly, the structure may look beautifully organized, and yet more attention is spent maintaining the system than doing the work the system was supposed to support.

That is a strange kind of failure because nothing is technically broken.

🌀 The productivity trap

There is a tempting loop in productivity tooling. Your workflow feels messy, so you introduce a tool. The tool helps, but also creates some friction. You notice the friction, so you add another layer of organization to fix it. Then you automate the interaction between the two. Eventually, you need rules for the automation, documentation for the rules, and some way of checking whether the whole system still behaves as expected.

At that point, you may have solved the original problem, but you have also created several new ones.

This is not really a criticism of productivity software. It is a criticism of the assumption that every workflow problem is a tooling problem. Sometimes the actual issue is too many commitments, unclear priorities, bad boundaries, or a process that should not exist in the first place. Sometimes the work is simply difficult and cannot be optimized away.

No app can solve those problems for you.

❎ Good tools should disappear

I increasingly think the best productivity tools become boring very quickly. You stop thinking about them because they quietly remove friction in the background. They do not require constant redesign, elaborate taxonomies, weekly system maintenance, or repeated migrations to the next supposedly better solution.

A useful tool supports the work without demanding too much attention in return. That sounds obvious, but the productivity ecosystem gives us a strong incentive to forget it. There is always another app, another framework, another dashboard, another integration, and another promise that this time the system will finally be complete.

The problem is that a perfect productivity system is probably impossible for the same reason perfect software architecture is impossible: the environment keeps changing. Your workload changes, your priorities change, your habits change, and the system that fits today may become completely inappropriate six months from now.

The obvious response is not to stop organizing work. It is to stop pretending that every new layer of organization is automatically an improvement.

🧩 Complexity should earn its place

Some workflows genuinely require complexity. Large projects, research programs, engineering teams, and operational systems often need structure, automation, and explicit coordination. The point is not that complexity is bad. The point is that complexity should earn its place.

Every tag, dashboard, integration, automation, and additional tool should remove more friction than it creates. If it does not, then it is not optimization. It is administration.

That distinction matters because productivity systems are unusually good at hiding administrative work behind the language of optimization. Reorganizing a dashboard feels productive. Migrating tasks between tools feels productive. Designing a new tagging structure feels productive. Sometimes these things are useful, but they can also become an extremely sophisticated form of avoiding the work itself.

This is probably why the most useful question before adopting a new tool is not:

What can this tool do?

It is:

What problem am I actually trying to solve?

And then, perhaps more importantly:

Do I need another tool at all?

Sometimes the answer will be yes. But probably less often than the productivity industry would like.

❓What do you think? Have you ever removed a productivity tool or system and found that your workflow actually improved? Where do you draw the line between useful structure and maintenance overhead?

The Pipeline Worked. Then the Research Outgrew It.

Dominik Kopócs — Sat, 29 Aug 2026 13:00:26 +0000

About a year ago, I was building a terminal-based workflow manager called Glyph.Flow.

It was mostly a learning project. I wanted to understand Python better, experiment with Textual, think about commands, state, configuration, logging, and all the small architectural decisions that suddenly appear when a script stops being a script.

Somewhere between then and now, the workflows became a little more real.

For my Master's thesis, I built a data pipeline to construct and process a cross-national research database from multiple sources. It had a clear purpose: take heterogeneous input data, transform it consistently, validate important assumptions, and produce the dataset I needed for the analysis. And it worked.

But this is no longer enough. I am not rebuilding it because the original system failed. I am rebuilding it because the question changed:

My Master's thesis needed a pipeline.
My PhD will need research infrastructure.

And I am slowly discovering that these are not the same thing.

A pipeline can be finished

There is something comfortable about building software for a well-defined research project.

You know the research question. You know most of the variables you need. You know which datasets are involved. You can define the transformations, produce the outputs, validate them, run the analysis, and eventually say:

Done.

Of course, research is never really that clean. Data sources change. Weird edge cases appear. A country disappears from one dataset. Another source changes a variable name. An indicator turns out to mean something slightly different than you thought. But there is still a boundary around the problem. A PhD changes that boundary.

Now I have to think about a system that may need to survive several years of research, new questions I have not formulated yet, datasets I have not discovered yet, and methodological decisions I will probably reconsider more than once.

Suddenly, "Does it work?" becomes a surprisingly weak design criterion.

The more useful questions are becoming things like:

Can I extend it without breaking old processing steps?
Can I tell exactly where an output value came from?
Can I rerun only the parts affected by a change?
Can I replace a data source without rewriting half the project?
Can I detect when something is technically valid but scientifically suspicious?
Will I still understand my own decisions two years from now?

That's a different problem.

The dangerous success of a working system

I think working software creates an interesting trap.

Once something reliably produces the output you need, there is a strong temptation to treat its architecture as validated.

But successful execution only proves a surprisingly narrow thing:

the system can currently do what you currently ask it to do.

It says much less about what happens when the scope changes.

This is especially important in research software because the code and the research process evolve together. A new theoretical question may require a new variable and a new variable may require another source. That source may use different country identifiers, time periods, aggregation rules, missing-value conventions, or definitions. Then a seemingly small analytical change starts travelling backwards through the entire pipeline.

The problem is no longer just transformation.

It is dependency. And provenance. And validation. And maintainability. And eventually, architecture.

From a research product to a research process

This is where my thinking has shifted the most.

For the Master's thesis, I was primarily building a research product: a reproducible database suitable for a specific analysis. Now I need to think much more explicitly about the research process that keeps producing and modifying that database. That means treating things I previously considered implementation details as first-class design problems.

Where should validation happen?
What should a processing unit actually be responsible for?
How should dependencies between datasets be represented?
Which transformations should be configuration and which should be code?
What information should be stored about every intermediate dataset?
When should a pipeline stop instead of trying to recover?

And perhaps the most uncomfortable question:

How much flexibility should I design for when I do not yet know what I will need?

Too little, and every new research question becomes a refactor. Too much, and I spend six months building a beautiful general-purpose framework instead of doing real social research.

I suspect the useful architecture is somewhere in the annoying middle.

Reproducibility is necessary, but not enough

Researchers talk a lot about reproducibility, for good reason. Given the same data and the same code, we should be able to reproduce the same result. But for a long-running research system, I think that is only the starting point.

I also want to be able to understand why a result looks the way it does. Which source supplied this value? Which transformations affected it? Which version of the processing logic produced it? What assumptions were validated? What changed since the previous run?

That starts sounding less like a collection of scripts and more like infrastructure. Not infrastructure in the "let's deploy Kubernetes for a CSV file" sense. Quite the opposite. The challenge is figuring out the smallest amount of structure that makes the research safer, more transparent, and easier to extend.

So this time, I'm designing before rebuilding

My instinct as a hobby programmer has often been simple:

See problem. Write code. Refactor when it becomes ugly.

That approach taught me a lot. Glyph.Flow itself was basically one long experiment in discovering architectural problems by running directly into them.

Research data is less forgiving. So before turning the current pipeline into anything larger, I want to spend some time defining what "larger" actually means. Not choosing frameworks. Not writing orchestration code. Not drawing an impressive architecture diagram with seventeen boxes. Just identifying the problems the system needs to solve. The technical implementation will come later.

For now, I'm starting with a more fundamental question:

What has to change when a pipeline stops being a tool for one project and starts becoming infrastructure for a research program?

Apparently, quite a lot.

Glyph.Flow DevLog #5 — From Alpha to First Release (v0.1.0)

Dominik Kopócs — Fri, 12 Sep 2025 22:25:02 +0000

It finally happened: Glyph.Flow reached its first non-alpha release.
When I started this little side project, knowing myself I didn’t expect to carry it this far. But after weeks of tinkering, refactoring, and fixing weird edge cases, I can finally call this one a proper release: v0.1.0. 🎉

🚀 What’s new in 0.1.0?

This release is about moving from “hacky alpha playground” into a usable foundation.

✨ Added

test command: runs automated checks for file integrity, configuration, and command functionality.
bigsample command: generates a large project tree for stress-testing.
New simple themes (crimson, arctic, desert) + hotkey T to switch between them.
Config now stores your last used theme.
A footer help bar with hotkeys, and it highlights itself when hotkeys are active.
Header info field showing project stats (total, completed, ongoing).

🔧 Improved

Cleaner command handlers.
Better internal messages.

🐛 Fixed

PDF export now properly handles CJK/Cyrillic characters.
Logs no longer get restored incorrectly after running clear + panel reconfig.

🧩 Lessons learned along the way

Undo/redo isn’t trivial: It’s easy to code “Ctrl+Z”, but making it memory-friendly and configurable took serious work.
Export quirks: Supporting multilingual output in PDF sounded trivial until it wasn’t. Unicode fonts and encodings fight back.
Theme switching: Handling Textual events and redrawing components was harder than I thought. It works now, but it’s just the first step toward a full theme engine.
And of course, the “easy” bugs are the ones that eat your entire day. Or night in my case...

👉 Check out the project here: GitHub

🛠 Roadmap ahead

The foundation is here, but I’ve got plenty of plans:

Advanced search filters (by type, regex, tags, date ranges).
Profiles: separate workspaces for different projects.
A proper theme engine.
Expanded TUI interface with dashboard, statistics, and menu navigation.

💡 Closing thoughts

This is the first non-alpha release, but it’s still just the beginning.
I’m excited to keep pushing this forward, and I’d love to hear feedback, ideas, or wild feature requests.

Glyph.Flow Devlog #4 – Import/Export, Config Overhaul, and the Road to 0.1.0

Dominik Kopócs — Sun, 07 Sep 2025 23:43:15 +0000

Two weeks ago I shared how Glyph.Flow reached a big milestone with the introduction of undo/redo feature. Now it’s time for another big step: v0.1.0a9 just landed, bringing import/export support and a completely revamped config and context system. This is the last alpha release before we hit the first real milestone: 0.1.0.

## 🚀 What’s new in v0.1.0a9

Import/Export – You can now move your Glyph.Flow data between sessions or machines with ease.
Export to JSON, CSV, or PDF.
Import JSON files with three modes: replace, append, or merge.
Config Overhaul – A brand new config handler makes settings more flexible and transparent. Cleaner initialization, clearer defaults, and better ergonomics.
Two-step Context Initialization – This lays the groundwork for more flexible UI handling and future TUI improvements.
Quality of life – More command aliases and some early bug fixes (like startup errors when data folders are missing).

👉 Full changelog here.

## 🛠️ Why this matters

Glyph.Flow is meant to be a minimalist workflow manager that still covers the essentials:

Portability (import/export makes it practical across machines).
Safety (undo/redo keeps mistakes reversible).
Transparency (config you can actually read and tweak).

Each alpha has been about laying these bricks. With a9, the walls are up. Next step: add the roof.

## 🌌 The road to 0.1.0

(Probably) next Friday I’ll be releasing v0.1.0, the first proper milestone. It won’t yet have the fancy TUI everyone is waiting for (or just me 😆), but it will be the point where Glyph.Flow transitions from “proof of concept” to “usable workflow manager.”

## Planned for 0.1.0:

Final polish on import/export and whole backend.
Stability pass on config handling.
README/Getting Started overhaul.
And then we can start looking beyond: TUI layouts, dashboards, and advanced search features.

If you like the idea of a minimalist, keyboard-driven workflow manager in your terminal, now’s the time to jump in:

- ⭐ Star the repo to follow along.
- 🐛 Try it and tell me what’s broken.
- 💡 Suggest features you’d want before 0.2.0.

👉 GitHub Repo

Next stop: 0.1.0 milestone. See you Friday. 🚀

Glyph.Flow Devlog #3 – Splitting Logs & UI Glow

Dominik Kopócs — Thu, 28 Aug 2025 15:15:57 +0000

Glyph.Flow just reached v0.1.0a7 🎉

This update focused on making the app more usable and a bit nicer to look at:

✨ Highlights

Dual-log system → one log for system/runtime messages, one for command output.
Animated panel adjustment (adjust) → smoothly toggle between log/output focus.
Custom RichLog with buffering + reflow on resize.
New header with live config info (version, autosave, logging) + pixelart logo.
Fixed the startup crash when no data.json was present.

The project is starting to feel more like a real TUI app and less like a wall of text. 🚀
Repo: GitHub

Glyph.Flow Devlog #2 – Hitting the Registry Milestone

Dominik Kopócs — Fri, 22 Aug 2025 21:00:39 +0000

Last time I shared why I’m building Glyph.Flow, a minimalist workflow manager in the terminal with Textual.
This week it’s time for an update on what I managed to get done.

GitHub

🎯 The Big Goal

I wanted to move from a rough prototype into something modular and extensible.
That meant one thing: a command registry.

🔨 What Changed This Week

Backend refactor: my massive 630-line app.py is now down to ~112 lines. Commands live in a registry, not tangled logic.

Command registry: all commands are defined declaratively, with schema-based argument parsing, aliases, and usage.

Logging: unified styling and message keys, with autosave and error handling standardized.

New config command: quick way to tweak settings on the fly.

Consistency: adding a new command is now just “add a dict + handler”.

😅 The Feeling

It finally behaves like a real CLI app instead of a spaghetti prototype — but I’ll be honest, it’s still a prototype.
The difference is: now the foundation feels stable enough to build on.

⏭️ What’s Next

More commands to migrate (delete, edit, schema, …).

Road toward a TUI interface on top of this backend.

Eventually, I’d like this to feel like a natural console companion for managing projects.

That’s it for this week’s log.
If you’re into command-line tools, or building things with Textual, I’d love to hear your feedback. 🚀

Glyph.Flow Devlog #1 – Why I’m Building a Workflow App in a TUI?

Dominik Kopócs — Tue, 19 Aug 2025 13:59:42 +0000

"Why build yet another workflow app? And why on earth in a TUI?"

That’s the question I asked myself when I started this project.

Over the years, I’ve tried countless tools – task trackers, kanban boards, Notion setups – but most of them felt heavy, clicky, or distracting. I wanted something much simpler: a workflow manager that lives entirely in the terminal, fully keyboard-driven, fast, and with zero context switching.

At first, I hacked together a prototype using plain curses. It worked… kind of. But as the project grew, I realized I needed something more structured and maintainable. That’s when I discovered Textual, and decided to port everything over.

So far, Glyph.Flow can:

define hierarchical workflows (Project → Phase → Task → Subtask),
save/load the entire structure as JSON,
render trees, tables, and ASCII views,
and handle commands like create, edit, delete, search, toggle.

The latest milestone (v0.1.0a4) brought two major improvements:

a layered logging system with INFO/WARNING/ERROR/SUCCESS/HELP levels
a command history module, so you can navigate previous inputs with the arrow keys.

Why might this be interesting?
👌🏻 Minimalism. Unlike most project managers, Glyph.Flow only cares about hierarchy and progress.

</> Terminal-native. It feels more like working with your projects than managing them through a UI.

👨🏻‍💻 Personal journey. For me, this is not just a tool. It’s a playground to learn Textual, experiment with structured logging, and design clean extensible systems.

Next steps:

Command registry (auto-help, cleaner dispatch)
Undo system (basic memento stack)
Better error handling
Export/import & statistics
And eventually… a polished Textual TUI dashboard

This is still very alpha, but it’s already fun to use, and I’m excited to share the journey here.

👉 You can check out the repo here: GitHub
👉 Follow this series for future devlogs: Glyph.Flow Devlog #2 will be all about the command registry!

These changes laid the foundation for the next big step: the command registry, which will finally eliminate the infamous elif chain and make adding new commands a one-file operation.