[HN Gopher] Show HN: Firm, a text-based work management system
___________________________________________________________________
Show HN: Firm, a text-based work management system
Author : danielrothmann
Score : 136 points
Date : 2025-10-15 07:01 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Protostome wrote:
| Getting people to use the terminal to do things instead of the
| bloatware produced by Google/Microsoft tools is almost
| impossible...
|
| I live in the terminal, but most people in my company, including
| developers rather stay away from it
| sunshine-o wrote:
| Yes I agree.
|
| My guess is that the console is a much better and natural UI
| because it goes in one direction and is less confusing and
| productive for humans.
|
| In the end we seems to move back to it through the chatbot
| paradigm, because it is in the end a console...
| danielrothmann wrote:
| It's an interesting trend. With the push for chatbot-based
| interactions, CLIs and plain text representations are making
| a bit of a comeback, since LLMs interface with those more
| easily than UIs.
| Propelloni wrote:
| We saw this in the early days of chat tools like Slack,
| too. /remind anybody? Today you, at least, get a floating
| help text if not a mini-GUI within the channel once you
| begin to invoke.
|
| So I'd wager we will see the same with chatbot interfaces.
| I furthermore predict that we will get taylor-made AI
| applications with a GUI that triggers specific "prompts" on
| unspecified datasets. "Prompt engineering" will become just
| another skill of professionals that have to use general
| purpose tools to built specific purpose tools... again.
| quietbritishjim wrote:
| To state the obvious (sorry):
|
| (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.
| 0xEF wrote:
| I don't disagree with you at all, but my biggest hangup with
| GUI-based software is twofold:
|
| 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.
| philipwhiuk wrote:
| > 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.
|
| This is just as true for CLIs.
| skrtskrt wrote:
| I think this blunkiness is in part because these things are
| often created and designed exclusively by frontend and full
| stack developers. IMO systems like these need strong
| backend developer influence, with highly scalable data
| models and and as much work as possible pushed server-side.
|
| 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.
| dannyfritz07 wrote:
| The approach I like the most is to first design a CLI that
| has the functionality you need. Then move that functionality
| to a lib and have the CLI now be a frontend for the lib. Then
| make a GUI frontend too.
|
| 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.
| cantor_S_drug wrote:
| Many people forget the main reason why Windows, Mobile, Webapps
| succeeded is because of convenience. The more easy to use the
| more better. Convenience is also the reason why Meta Glasses
| will be successful.
| brettermeier wrote:
| The main reason might be that terminals are ugly and messy, you
| can't find shit, everything melts together. Might be nice for
| power users, but those aren't so many I would guess.
| fellowniusmonk wrote:
| I live in the terminal. I've been using the terminal since
| before guis were an appreciable option.
|
| People who lionize the terminal are silly, it's objectively
| bad and the fact we use it at all is just the inertia of TTY.
|
| Trying to put GUIs in terminal, all this stuff, it's a hack,
| a sign of failure to make progress.
|
| In an alternate universe Emacs wouldn't be culturally anti-
| human and we'd have a data first gui instead of app siloing.
| Some Emacs custom setups are the fucking future, context
| switching, everything is so perfect, but because the interop
| is so bad you can't use it in your day job.
|
| But most OSS OS devs have spent all their time focused on the
| system part and not the operating part.
|
| Human factors and human interfaces are still mostly ignored,
| and that's just from a sole user perspective, most developers
| of UI don't treat the networked/relational aspect as a first
| class UX issue for an OS.
|
| And that's partly a failure of imagination, a failure of
| loving people as much as tech and also because distributed
| collaboration is fucking hard and most people just rewalk
| existing paths.
|
| Maybe LORO is the only truly interesting open source project
| right now, but Ai can't write those algorithms so even their
| implementation is under explored.
| ASalazarMX wrote:
| Reading all these opinionated comments about CLI vs GUI, I feel
| out of place as just a humble TUI fan.
|
| - CLIs are powerful but hard, basically an exercise in
| mnemonics.
|
| - GUIs are much friendlier, and can be faster than CLIs for
| certain use cases. While complex and bloated, they have their
| use cases to shine.
|
| - TUIs are basically less expressive GUIs, since they're
| limited to text, but you must go out of your way to make them
| bloated and slow; they usually are very snappy.
|
| All have their best and worst scenarios, no need to argue which
| is better. Use what fits best with your workflow, no size fits
| all.
| matthewcanty wrote:
| I'd be interested in defining my business using a DSL but then
| ultimately I'd want that to be translated into a UI.
|
| I'd love to simply map all the relationships between stock,
| assets, tools like invoicing, APIs all in a place like this.
|
| But I have to agree I think CLI alone would result in it being
| usable by only me.
|
| EDIT: just wanted to add I'm interested in where this project
| goes.
| danielrothmann wrote:
| I think that's fair. I'm personally happy with a text editor +
| CLI, but can acknowledge that is not enough for broader
| adoption.
|
| The project is structured as libraries such that you could
| build an editor separately, but it's not something that has
| taken priority for me (as the only user, so far).
| N_Lens wrote:
| Looks ambitious but previous attempts at "Ops as Code" haven't
| been promising.
| danielrothmann wrote:
| Healthy skepticism. I think firm differs from ops as code in
| the sense that it focuses on the structural aspects and
| representing the people-ops side in a way that machines can
| interact with too.
|
| To be clear, I'm trialing this out in my own small business.
| Whether it's ergonomic enough to add value and whether it's
| scalable, I don't know yet. So far, so good, though.
| ipnon wrote:
| It's good to experiment, and your boldness should be
| commended.
| actionfromafar wrote:
| Ehm, SAP ERP?
| 0xEF wrote:
| This is interesting, very similar to a project I am working on,
| which is a cli asset manager for a small repair shop. Basically,
| mine keeps track of service tickets, customers and inventory
| while being query-able to help identify trends in problem
| products or recall records for warranty disputes, etc. It's just
| a silly little project I started in my spare time because I got
| fed up with having to open up three pieces of software with
| clunky UIs and frequent crashes to accomplish what should be
| fairly simple and straight-forward tracking and analysis. My
| biggest hurdle was getting it to export to a nice looking PDF
| that could be emailed or printed later.
|
| While mine is functional, yours looks A LOT more refined, so I
| think I will play around with it and see if I can't adapt it to
| my needs.
|
| I try to work in the terminal as much as I can since that's where
| I'm most comfortable, but when it comes to business software like
| CRMs, HRMs or ERPs, especially geared toward smaller shops, the
| selection for terminal-based options is severely lacking.
| SuperHeavy256 wrote:
| Can you share the github link to your cli asset manager
| project?
| Thom2000 wrote:
| > My biggest hurdle was getting it to export to a nice looking
| PDF that could be emailed or printed later.
|
| If you can export to structured data such as JSON, I guess
| Typst would be a perfect fit for that job.
| DocTomoe wrote:
| I love the idea. More power to text-based tools, more power to
| the CLI.
|
| But ... why invent a new file format? Why not just make in JSON,
| so it is easier to integrate in other toolchains (e.g. having a
| python script add customers based on external APIs without having
| to write your own output generator)?
| sixtyj wrote:
| I've tried JSON, YAML, and TOML for storing data. Last time, I
| ended up with an 8,000-line JSON file. And I had to write an
| editor for it, because text-based editing caused more syntax
| errors than I expected (what a surprise :).
|
| But each of formats seemed nice at first.
|
| So I understand that sometimes it's easier to invent a new
| format. But compatibility with other formats can definitely be
| a problem lately.
|
| My question is: how does the proposed system handle multiple
| editors working on the same text file?
| mayowaxcvi wrote:
| Spent ages building my own work management system only to realise
| I was just taking the scenic route to eMacs.
| jaaron wrote:
| I was thinking the same thing: why is everyone reinventing
| emacs?
|
| gnu and emacs already have a long history of cli and text
| friendly solutions that LLM dev agents can easily use and are
| trained on.
|
| Or for structured data, just use a database. Dev agents can
| work with SQL just fine.
| fellowniusmonk wrote:
| The problem is that they aren't reinventing emacs.
|
| The first person that makes emacs for the hoi polloi will
| suck up all the emacs people as well just based on interop
| frustrations.
|
| I still can't believe that after seeing how slack just
| released irc for grandma's and pointy haired bosses that no
| one has done the same for a sensible defaults for normies
| emacs.
| actionfromafar wrote:
| Yes! An honest to God, real, opinionated distribution of
| Emacs, with only curated packages with rules and regression
| testing actually enforced by the package managers. That
| would be neat.
| 4b11b4 wrote:
| So glad emacs finally found me, I can't wait until I can look
| back 10 years from now
| bravura wrote:
| The text-based software that would eat work management is one
| that embraces the incumbents rather than avoid them.
|
| I want a bidirectional SaaS <=> YAML/JSON adapter. So that I can
| push and pull our CRM (and other SaaS utilities like project
| management) into a common (schematized) YAML format.
|
| The YAML then can be analyzed and modified using LLMs and/or
| stored in git.
|
| And then use the bidirectional sync to reconcile conflicts and
| push.
|
| So I can do work processes on the console, and still collaborate
| with people who want the native web UI.
| danielrothmann wrote:
| Agreed, this is on my mind as well.
|
| Thinking of Terraform, you have data blocks that can grab data
| from an external source. Still trying to grok what would be a
| convenient way of doing something like this - whether that gets
| generated to DSL, or if data pulled in dynamically as you build
| the org graph...
|
| Having your plain-text workspace as a unified structural source
| where you pull in data from external systems would be
| potentially powerful.
| rirze wrote:
| You'll unfortunately have to agree on some sort of state
| representation for each source and then delve into those APIs
| to extract that information
| montague27 wrote:
| Hi there, I've made my own text-based todo list with
| compatible web view which is kind of similar to what you did.
| (though far from completion)
|
| There's a sync engine behind it so the UX is extremely
| responsive.
|
| Link: https://mglogi.com/portfolio
| swoorup wrote:
| I would like the native web UI when I am being too lazy, and
| terminal when I am in the zone..
| kstrauser wrote:
| Huh. Could those be git submodules? Like you'd have all your
| personal state in foo/ and then clone the work state into
| foo/work/ .
| ipnon wrote:
| The age of LLMs is shifting the predominant modality of data
| towards plaintext. For people like us, it's easier to grok, and
| it allows all of the poweruser use cases. I think this is a great
| idea.
| aitchnyu wrote:
| Looking at the points you made and examples, I would cobble a
| similar tool with Django, writing only CLI commands with no HTTP
| endpoints. And most LLMs are already fluent in Django.
|
| - Schemas and relationships live in models.py, actual data is
| persisted in Sqlite - I can dump to JSON or XML with Django utils
| for LLMs - Query engine can simplify reuse Django syntax, like
| `Firm.objects.get(owner_name__like="john", date__gt=2015)`, fetch
| related names, aggregate subqueries - Format as tables
| baby-yoda wrote:
| The simplicity of text files is appealing - did you consider
| using a database at all or was it pure text from the start?
|
| Thinking about an LLM use case, not needing a query language
| should remove translation risk I'd assume?
| alchemist1e9 wrote:
| Makes me think of recutils
|
| https://www.gnu.org/software/recutils/
| virajk_31 wrote:
| CLI is cool but this won't work in real life, focus your energy
| building something else.
| runlaszlorun wrote:
| Please tell me you're a troll and this isn't what you actually
| think a useful comment looks like.
| kstrauser wrote:
| Right? On behalf of everyone working on projects to scratch
| an itch that won't go away: f- off and let us hack on what we
| wanna hack on. No one asked for or needs permission.
| wmeredith wrote:
| Thanks you! I rarely downvote on HN, but this earned one.
| ithkuil wrote:
| I'm curious to see if the advent of LLM assistants will result in
| a resurgence of "headless" systems
| n0um3n4 wrote:
| I forking love text-based apps, congratz!
| A4ET8a8uTh0_v2 wrote:
| While I do not think big corps would go for it, I believe you
| have something there that could:
|
| 1. Appeal to some of the crowd here 2. Potentially run in the
| background as meta layer for llm ( as crazy as that sounds, the
| annoying reality is that it is happening already, but in the most
| annoying way possible 'worst of all worlds' version )
| pjz wrote:
| This seems like it could be an rdf query tool, though offhand I
| don't know the ref to the right rdf schema.
| kkukshtel wrote:
| This looks very similar to a FoSS version of Tana:
| https://tana.inc/
|
| Which is well timed because I've been increasingly leaning more
| into Tana but also being like "it would really suck if this tool
| goes away". Having something that has the same ergonomics of Tana
| but is more open is really interesting.
| itsnowandnever wrote:
| things like this are so much fun. I mess around with projects
| like this too. I have a little "status" app that that's a web UI
| embedded into a Go binary that shows my current WIP and it
| updates my slack status with what my WIP is. so outside of
| standup everyone just knows what I'm up to
|
| I love little CLI tools for managing productivity
| cyanydeez wrote:
| I bet there's someone or some business with a curly brace in
| their name.
| kovek wrote:
| With cursor you can hit Cmd+K in the terminal and give a prompt
| for the agent to convert to a command in the terminal. Would be
| good if it could allow to do the same to generate SQL queries
| based on the databases schemas available. Then it would be a
| generic solution that would cover this use case.
___________________________________________________________________
(page generated 2025-10-15 23:01 UTC)