Context: worked in the space a bit (~4 years, cumulatively), mech eng with a comp-sci minor, track the space from the outside now.
As others have pointed out, this is, as far as I've seen in the last decade, a very conservative industry in terms of taking risks and trying new things. Some companies build an excessive amount of infrastructure for these operations internally, some go entirely with legacy off-the-shelf stuff (think SAP, NetSuite/Oracle, etc), and some go with a blend of the above. I've seen little traction with modern software, but this is likely a byproduct of my only having seen some small number of companies' operations.
Sympathy for your personal hardship. That just sucks.
There was a facetious comment that was flagged discussing that, as a HN user who certainly makes $XXX XXX, you can't be having a hard time. It is interesting, though, that even folks on HN (who I think it's fair to assume skew towards the higher end of the income distribution?) are also having a hard time.
Note that I mean interesting in the worst way. I hear these stories from folks of all walks of life in the non-metropolitan region that I live in, and I've generally just chalked it up to not knowing the upper-class folks (the ones making $240K writing client-side TS at MANGA). I suppose I'll now read about these same struggles of affording, affording kids, planning to retire, and so on here on HN.
Having never worked on a multi-tenant SaaS app, is this how multi-tenancy is typically implemented (a per-tenant-database)? Is there a certain scale at which this becomes the ideal pattern? If so, has anyone made the shift from a single-database approach to a per-tenant-database approach?
Looks great, and I'm excited to try it for a personal project (nice free tier). It looks like it can act as the entire devops team for my single-person project.
Personally:
-sports: climbing gyms/trips/facebook groups/etc, bike groups (not exclusively biking alone), hiking trips, etc
Anecdotally:
-drama clubs/local theatre productions
-run clubs: while running is typically fairly isolated, there are social run clubs in cities that often go for a drink (no booze necessary) post-run
-book clubs: random collections of people that discuss a book together
-dinner clubs: sharing food with folks in a way where different people cook for others in turn
-partying: most places have a community of folks that enjoy dancing and/or recreationals
Note that I believe that the strong relationships can come from overcoming a shared struggle, so if you can think of something that's difficult and with one or more other person/people, you will probably form a community around it over time (co-founders and cohorts are a great example).
I've spent quite a bit of time building basically this exact tool within a greater app, and have to say that this looks amazing. Well done!
Now I'm just curious what you have in mind in terms of next steps, as you've done the technically hard part, and there are so many market options available.
Entirely understandable, and a major driver in my transition from industrial automation to web software (though industrial hardware work is so rewarding!).
Does Charm ever plan to be remote-friendly? Asking more for some talented friends living in a remote small town, though I've admired Charm from afar for some time.
I have a similar habit getting similar flak, but with another added reason. As a remote worker, going to a place every day (often leading to small interactions with others) helps replace replace some elements of working from an office (commute, small chats with other frequenters, the getting presentable ritual you mentioned, etc).
I'll append a gripe to this and say that employers should allow "work-from-home budgets" to be put towards credit at local coffee shops.
My org (small but growing team, web) manages developer setup, product and project documentation in Notion, and the docs often get created but not maintained, and the product documentation is mostly for recently developed segments of the app. Commenting is generally avoided in favour of clear, self-documenting code, with more complex methods warranting doc strings. We do not add a comment for every method and their parameters/returned values. Inline code is only used for complex segments of code.
Overall, I feel that our codebase is well-documented, but our product and projects could use better documentation to help new team members and people seeing a segment of the product for the first time in a while. I'm unsure as to where this should live, however.
As others have pointed out, this is, as far as I've seen in the last decade, a very conservative industry in terms of taking risks and trying new things. Some companies build an excessive amount of infrastructure for these operations internally, some go entirely with legacy off-the-shelf stuff (think SAP, NetSuite/Oracle, etc), and some go with a blend of the above. I've seen little traction with modern software, but this is likely a byproduct of my only having seen some small number of companies' operations.
There are a number of companies trying to innovate in the space in a variety of ways, but here are some modern manufacturing ERP companies: - https://fulcrumpro.com/ - https://tulip.co/ - https://oden.io/ - https://www.machinemetrics.com/