Allows for a GUI for tasks that need that better context or hand holding. But then the CLI is there when there is a workflow the GUI doesn't support comes up. Bonus of scripting being possible with the CLI too.
Challenges this approach has is that you have to have a test suite that exercises both workflows or due diligence to make sure they both work as development continues.
Also not all programs can be done acceptably with a CLI. Real time 3d games are an easy example of a GUI only task.
1. It tends to be bloated, with developers slapping framework upon framework, creating a mess of background wiring that is prone to a dictionary's worth of issues that will either frustrate the user or confound the person maintaining it.
2. UX Designers approach their jobs incorrectly; they assume they are smarter than the user. Interestingly, this might actually be true on paper in most cases, but the practical reality is that the user needs to do things the user's way, not the way the the developer wants them to.
If we could find ways to smooth those two glaring issues, I posit that we'd see a lot of problems with productivity and workflow melt away. Caveat; I'm not a software developer, so I'm sure anyone who is thinks I'm speaking out of school right now. Fact is, I've worked in a few different industries over 40 years, and one of the biggest thorns always seems to boil down to the software not being quite right for the team/application, so workarounds have to be invented, adding layers of complexity on what is already a decidedly fragile system.
This is just as true for CLIs.
In short, the system should be designed by people that despise the general state frontend development. It should still look good, I love a modern clean frontend (like Docmost for example), but not at the expense of snappiness and scalability.
To me, it’s obvious that if a certain command feels cumbersome (e.g., (1)), you can just create an alias, script, or panel to make it behave exactly how you want. In contrast, a GUI usually forces you to use the functionality as it was envisioned by the product team that designed it.
Ultimately, GUIs target the average user, providing a good experience on average across all users.
With terminal apps, if you are patient and willing to learn how to customize your shell, you can make an excellent environment which would offer a huge boost of productivity
(1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analogy: imagine if your toaster had buttons just labelled "1", "2", "3" and you had to refer to the manual for which meant toast, defrost, extra browning.)
(2) Command lines lack the visual persistence of the data you're operating on (like a list of files in a directory, or project/people data like in this program). If you rename a file and you then re-run ls and now everything appears in a slightly different place on the screen (because the previous listing had shifted up when you ran "mv") it's visually jarring in a way that just operating directly on the data isn't. Not-silly analogy: it's like how no-one today would dream of operating on a text file using a pure line editor like ed. (Even command-based editors like vim persist the file data in the main visual area.)
Command lines are much better than GUIs/TUIs for some applications, for example when called from a script, or where you might need to compose a complex command and then tweak and re-run it (in fairness, that might apply to OP's project). But I think techies sometimes get a bit carried away. GUIs are sometimes a legitimately better choice.