mhashemi

And they're still sticking to the kitty 10 years later? There are kids launching apps born after the extinction of Google Glass.

AlternativeTo is full of SaaS apps! If you're not finding one, you should join and add it :)

Woooow, there are so many! Impressive list, but do any of them work?

Well, it's not a bad thesis in 2014. They seem to have had a pretty big hand in killing their baby in 2022, by bundling it with a crypto startup with a URL that already fails to DNS resolve <3 years later: https://a16z.com/announcement/investing-in-prologue/

Exactly. The PH docs make a big deal about having a video demo, too. Then they go ahead and hand-pick launches to feature that don't even meet that criterion. And for what?

Thanks! Pro-Duck Hunt. It's right there, not sure how they missed it.

ah, meant to link straight to the receipts. fixed, thanks!

Or zombified at least. Here's the meat: https://sedimental.org/product_hunt_is_dead.html#the-zombie-...

Hmm, DCA is one I think about a lot. Probably pretty easy to convert this research over: https://investor.vanguard.com/investor-resources-education/n...

The result won't be super surprising, but it'll be more specific.

I have a whole rant about this saved for a future blog post. The short version is that people need actionable belief. Charts are useful to demonstrate a concept, but at the end of the day, we want answers. I'm sure there's _someone_ you trust. Whether it's your dad or a friend or a podcast, I think the main gap is giving the user specific action. For example, https://finfam.app/heyfinfam/views/rent-vs-buy boils it down to Rent/Neutral/Buy. Most of the other featured views do the same, to eliminate the exact ambiguity you're describing.

Haha, spent many hours on the Bogleheads wiki, and I do love it. But yeah, I'd love it even more if it had fields I could punch values into. If only there was some sort of site for that...

Thanks! Yeah, far-flung plans for integrations. Currently I'm getting way more mileage out of letting other products do the integrations for me. I.e., I use Monarch Money and just upload the screenshots to FinFam which parses out the balances.

I helped build the first version of Stripe's Financial Connections product and while the alumni credit is tempting, I'd like to delay using it as long as possible... Too many error conditions and it's not like planning calls for that level of precision anyways.

Haha, re: finances, everyone wants to know this! Give or take, yeah! I just felt obligated to go all in with the dogfooding. It's probably TMI for most folks, but other users don't have to do the same: https://finfam.app/faq#faq-data_visibility

FinFam is private by default, but publishable by design. It's also totally valid to build/publish hypothetical/prototypical scenarios for the sake of demonstration.

Re: manual entry, the income and expenses were, yeah. The balances from the accounts are all ingested via our "Magic Sync" which is really just parsing from screenshots. Works with Monarch Money, works with spreadsheets. And you don't have to deal with the nightmare of "open banking" (I helped build the first version of Stripe's Financial Connections product and I'd like to delay using it as long as possible...)

Relatable. While I doubt I'd have been able to do all the frontend myself without an agent, it's still pretty early for LLMs + money.

It depends on where you're starting a thread, but assuming you're starting the thread in a view, then we prime the chat with:

- The user's configured financial literacy, education level, etc.

- The reasoning and actual results of the calculator as you see them

- Summary metrics from the space that the view is saved in

The last point is pretty critical. The idea is that you build your own context from the bottom up, exposing as much or as little as you want for the scenario you want to explore. Add the relevant assets/liabilities/income/expenses, and we have a little cash-basis accounting simulator that projects all that into a "scope" usable by the Views, as well as the chatbot ("Finn" http://finfam.app/finn).

Handing these metrics to the chat unlocks a lot of the magic of the chatbot as a "neutral explainer". Any creator can upload a spreadsheet, but as we've currently exposed it, Finn is meant to be moderate and just there to close any explanatory gaps that the creator may have left out, or not considered. If you're looking at a view about buying a second house, Finn's supposed to give you a gut check if you have particularly low cash reserves.

A lot of a financial advisor's time and role is filling gaps in your financial literacy, and a 24/7 chatbot is honestly just better at explaining the difference between a credit and debit card.

Haha, glad you like it! So, originally this was a B2B concept for a friend who was starting an advisory. Original model was around referrals, and advisor client funnels. That might still have a place, but tbd.

The B2C version you're looking at is an app store, so marketplace / app fee structure. Currently, when you save a View to your space, you're actually subscribing to updates. Instead of paying for a newsletter you have to read, digest, and model off, FinFam enables a paid subscription to a spreadsheet that gives you an answer. Skip the read, straight to the guidance.

For most people facing decisions with significant financial components, they keep an eye on the situation for weeks if not months. If they're subscribed to an expert's View, they can pay per update or per time period, kind of like Patreon.

I'm thinking we'll probably add some premium tier for certain SaaS features. E.g., similar to Figma, you can have X spaces, but if you want more, you need to pay more. Something tied to advanced use cases, # of chatbot convos, etc.

For now it's all available for the low low cost of bug reports. the more detailed the better!

Certainly useful for authoring, since that's what I do most now as a founder. Most of my code is pretty fresh. While I can give you some feedback, I probably wouldn't pay more than a couple bucks a month. Meanwhile the larger, older codebases at more mature companies have much greater need and budgets.

We're long overdue for tools like this. Especially with the (commendable) rise in code review. The downside of code review with large codebases is that I'd get pulled into parts of the codebase which my team ostensibly owned, but where no one on the current team had significant context. Usually these code reviews were part of bigger rewrites/refactors where the author/their tech lead knew more, but not necessarily all.

This turned into theater. We had no choice but to rubberstamp. The “review” was more of a heads up than a real review request because no one can get up to speed without becoming a blocker. Something to improve monitoring reflexes or reaction time in an incident. Frankly these days an LLM would easily clear the bar for the “review” part of those reviews. But even the LLM's context could be significantly enhanced with a tool like Tanagram that has actual architectural context. Looking forward to updates!

Huge, congrats. Render's been the best Heroku successor a dev could ask for. Looking forward to Cloud Object Storage in 2025! https://feedback.render.com/features/p/cloud-object-storage

If you're into this sort of thing: https://weatherspark.com/

Has all the breadth, and much more depth.

Took some convincing, but compliance is a pretty high-leverage angle. :)

All done, thanks again for looking out!

Just a bit of original author bias. If you know other projects, I'd be happy to merge em! https://github.com/mahmoud/calver

People like bigger numbers and newer releases regardless of exact versioning scheme.

SemVer makes that situation worse, by requiring a bigger major release to break some part of the API. Other failure modes detailed here: https://sedimental.org/designing_a_version.html

I was only asking why you say it comes crashing down, when the link cites multiple cases of successful parallel version maintenance with a version that is at least partially calendar-based.

As far as usability, time is a dimension no developer can escape. We develop software on a schedule and we deprecate it on a schedule. CalVer is tremendously semantic at that higher level. The semantics SemVer clings to suffer even under ecosystems which have mandated their use (go, node). The effect has been an over-granularization of APIs themselves.

I'm fine with agreeing to disagree for now. I'm also fine with the case that CalVer is not for everyone and everything. I'll leave it with this, a post seems to articulate a lot of your concerns: https://caremad.io/posts/2016/02/versioning-software/

It was written in 2016 by Donald Stufft, a maintainer of pip. Today, pip has been CalVer for a while and I'm not sure anyone has looked back. Try it sometime, and you might find the same. :)

You're quite right, and this site is being migrated this week. I was going to do it this morning, but there was a traffic spike for some reason? :)

A short list of SemVer's failures to communicate project maturity: https://0ver.org/

Why? The version number is determined by the original release date, and after that it's just a normal version number. Pretty sure the Teradata library linked does basically that. Python's manylinux standard is another example.

The whole point of CalVer as an alternative is that SemVer has sold folks a bill of goods with regard to software maintenance. Perpetuating the idea that people can blindly update will always create problems.

More discussion here: https://sedimental.org/designing_a_version.html

Good to know! It seemed to meet the criteria here: http://sedimental.org/awesome_python_applications.html

I'm curious if the userbase is overstated, but otherwise it seems to be well-known enough ;)

Linked the GitHub, but here's a post about why it was worth spending a few weeks compiling this list: https://sedimental.org/awesome_python_applications.html

Because most of these utilities were created to build things, and contributing to the stdlib has never been on one of those critical paths?

But really, @marmaduke's got it right. The standard library has a MUCH higher barrier to entry than PyPI. Have you seen python-ideas [1]? I truly do not have time to have it out with some of the more vocal elements of that group.

But, down the list:

- OMD might be a good fit for the collections module, I've chatted about it a bit with Raymond Hettinger on and off. He wasn't totally against it, so that's something!

- Exponential backoff is too opinionated for itertools, and generally a lot more high-level and conceptually modern than the rest of Python's built-in networking facilities.

- remap: I really like it, even though I'm typically not a big fan of functional programming in Python. But the Python devs are even less appreciative than I, with GvR disliking lambdas, and Py3 dropping reduce() from the builtins. Plus after years of watching Python core dev, it doesn't seem like the people with the time to work on core Python have much time left over to work with IRL complex APIs and other sources of dynamic nested data?

- Atomic file saving probably should go in the stdlib, but probably not relying on ctypes (on Windows) and I'm not going to pull out my old Windows laptop again just to start writing C.

- Traceback utilities: Probably the one I wish I had time to push for most. traceback's string-only approach feels really dated in the structured-logging age. I'd expect a lot of FUD around messing with error handling.

Maybe now that boltons is pretty popular it's worth giving it a go just to see what lies beyond the typical listserv response: "put it on PyPI and if it's popular, we'll see" :)

[1]: https://mail.python.org/pipermail/python-ideas/