Going financial....

About a year ago I've joined a new startup called Cashews. I really liked the idea of providing users easy way to know how many can still they spend today without going broke by next salary, however I had 0 idea how should it work, since I dont have any financial education(and well, I've been broke by end of month many times) that seemed challenging to me and so I said - "Challenge accepted!"

Because it was a startup - we didn't have big budgets, team of managers, researchers, and all decisions were done by a team of 3(Hi Jonathan and Romano) and it resulted in really successful outcome, we were awarded with #1 Product of the day on PH badge.

What did #1 give us? First and most important - ProductHunt is a community of early adopters and people who wants to try new products before they reach wide audience or people who looking for better tools that currently exists on market. That means it's easy to get real feedback from users, without actually blaming you for doing something incorrectly or just showing wrong results. That also helped us to fix some bugs we weren't aware of, change UX to be even more user-friendly and generally it helped us to understand how awesome the Cashews is.

I was really anxious on how will it go, because the math behind calculations really complicated and the numbers not always obvious due to many variables involved. Surely, before releasing on ProductHunt we had long beta with lots of changes to our calculations, polishing the UI and UX(the UI/UX on most financial apps kinda complicated and usually flooded by features you most likely won't be using since the beginning). One of our beta users even reported that we helped him to find subscription which he wasn't using, but somehow it wasn't cancelled(that was a big win for us at that period)

How did we make it?

I had no ideas how to calculate user's spendable per period. First iteration was straightforward - take all user's income, take all expenses, subtract and divide by amount of days till end of month. But then - you understand that some people gets paid twice a month, or once in few months. Some people gets paid weekly. Some people gets paid in mid of month. First part of solution was - find proper, realistic spendings dataset. There are few publicly available online with depersonalised transactions. We tuned formula - however there still were edge cases when it didn't work. Another set of discussions, tuning and we end up with few different formulas for different user spending profiles. Looks good(more or less), but then we launch our closed beta, get some real user's and find out how differently people use their money and even how do they store them on their accounts or even having different banks for different purposes, such as - Bank1 for mortgage, Bank2 for leisure, Bank3 for savings, etc.

All previous work was discarded. We started over. Google spreadsheet was our best friend for couple weeks of trials and errors. That resulted in some very promising values that seemed to be correct according to our hand calculations. What also helped us a lot - visual debuggers. While working with list of database rows - its really hard to see whole picture of calculations. Our debuggers were simple SPAs which would actually breakdown calculations into smaller chunks, so we could understand where does the error comes from without need to export rows into spreadsheet and spending hours trying to understand why is it $1 instead of $25.

After months of work we finally got what we wanted. But it's not finished yet. With every new user we get more data. While 90% users have predictable spending patterns, rest 10% are different. And we constantly work to improve our calculations to cover as many spending patterns as possible. I won't go into details, but current calculations consists of more than 20 steps, and its growing up as we find new patterns and trying to make calculations more correct according to user's spending approach and their lifestyle.

Few technical and not so lessons I've learned working on Cashews

• Always use objects for api responses instead of arrays, even for most basic api endpoints, such as:

  {
  'items': ['A', 'B', 'C']
  }
  

  You never know when your client app will demand more data or just different format. Having object helps you to return even different responses depending on client app version.

• Always process requests in user's timezone. Make sure every request has user timezone, or you end up having many complaints that data shows incorrectly(most databases works in UTC timezone).

• Do not spend time on database query optimisations. Most likely database schema will change multiple times before you get final result. Save your time.

• I don't like to be Cpt. Obvious, but - write tests, cover api responses format, make sure that client will always get same response format as before.

• Do not be afraid to checkout your 2 days of work in favour of better solution. While working on cashews we discarded at least 2 different formulas which costed us literally weeks or even months in development time.

• Ruby on Rails still good choice for startups. Fast iterations to verify your ideas. Most likely you won't face any performance issues till you get your first 1M users.

• Google spreadsheet usually can save a lot of time when prototyping calculations.

• Do not overcomplicate your infrastructure until you get final result. Heroku will work well for most startups.

Summary

Am I happy with the final result? Yes, definitely. I've learned a lot not just about math and finances, but also how to plan your work when you not always know how to achieve best result. There's still lots of work to be done to cover as much users as possible, but the foundation we created makes it easy to introduce new variables into final calculation, add new integrations and basically just grow app but be bigger than just spendings predicting.