> 4. Budgeting/reporting.
> 5. Some sort of sane forecasting. You’ve got N months of data from a customer, why can’t you tell them in 6 months this account is expected to have $x in it?
I work on a methodology engine and have implemented both of these, at least on the data side, and they are essentially aspects of the same thing.
Fundamentally, what's hard is user trust. If they see numbers that don't make sense, explaining that "technically you told us this and this which all adds up to that" sounds like "we can't do arithemtic" to users.
The budget needs to agree with the forecasts. And the forecast doesn't quite semantically "fit" the budget; your forecast shouldn't "know" about the future or it can't give faithful metrics whereas your budget is supposed to plan ahead.
It also gets tricky when people use the damned thing, because your system needs to be resilient to users not doing the things they promised to do. For example, if they promise to deposit $500 in projected account A, but instead deposit it in tracked account B, you would project that the money lands in A, and also report that there's $500 more in B. So now those totals are off.
And budgeting itself is a surprisingly tricky problem. There are so many techniques to make a budget work that selecting good ones is hard. And users will say, "oh, I always want to spend $500 on this," and when that results in something stupid, "well, obviously not then." Even without that, it's hard to make the budget not do weird stuff that gives a user a WTF moment. The most counter-intuitive stuff tends to happen when the person is running low on funds, but that's also the raison d'etre of a budget.
> 3. The ability to sync transactions from my bank.
> 6. Sane APIs.
Between not making money off the APIs, having the user get frustrated being bounced between my support and the competitor, and that the APIs become another component that must be secured and administered, I'm not surprised APIs are uncommon.
Which makes me sad.