Yeah, the 4-year forward projection was what got me hooked on moneywell in 2009, when I bought a "forever" license for them. I have since wanted a budgeting app that would have that feature too, so I built trackm.

Regarding the one-time fee and subscription, 100% agree. I delayed adding account sync because of the monthly / yearly costs. And also, because with the model of recuring rules looking into the future, I tend to use the app on a daily basis to correct things (payment is scheduled on 16th but is cleared on 17th so I need to update it).

When I add bank account sync, I'll have to think how to charge it. I still don't want to have a subscription for it, so need to think about it.

Finally, I don't do client-side encryption. There is encryption in transit (https / tls) and at rest.

I can't open any database without the user's password, so even if someone were able to exfiltrate the user databases, they still would need to know the encryption key used to read the data.

I am researching providers to be able to add account sync to trackm.net

I haven't done it at first because

(1) they all have monthly / yearly costs and I wanted a flat fee;

(2) I can't update the account without the user having logged in because of how the encryption works.

That's actually a fair point, regarding the implications of a one time fee.

Personally, I don't like subscription-based apps so didn't want to create yet another one.

And I built this around my personal needs so I plan to support it indefinitely.

Regarding long term improvements, there is a number of paying users that once I achieve, any new users are basically profit.

The service was built to be cheap to run and maintain so I could charge a one time fee.

Hadn't heard of it before, though looks similar in intent.

My inspiration for trackm was actually moneywell.app which i bought a license for in 2009.

The "look X years" into the future feature was pulled from it.

I no longer have a mac or ios device, so built trackm to fill the void.

I'm working on ripbox, a prototype cd player / ripper that than rip your CDs while you listen to them, back them up and then make them available for streaming anywhere.

My cousin has a large collection of CDs and the player is being built around his listening habits (listening to disk from start to finsh at home, individual tracks when on the go).

Agreed, but tools like https://sqlc.dev, which I mention in the article, are a good trade-off that allows you to have verified, testable, SQL in your code.

Ironically I started drafting this article in 2021, when I had to deal with a Django codebase littered with nested N+1 queries due to using the ORM in the most pythonic way.

Drizzle does exactly what I described in the article: it re-implements SQL in the target language (in this case TypeScript).

But you have raw SQL operator and all drizzle operations does is to build you the SQL query.

Well other orms do that as well ofc. But I feel this is a low level as it can get

Native sql with sqlc.dev

Not exactly what you want, but I've been using https://sqlc.dev to generate hydration code from SQL queries and loving it!