Can someone explain the revenue model and the problem being solved? Also, why would I, as a Melio user and bill payer, make a bank transfer to Melio instead of my supplier directly?

Thanks for these resources. It looks like all of them are for frontend-only cases though?

On the server-side you probably want some kind of transaction log or event sourcing / CQRS architecture...

The idea being that you don't write directly to a persistence layer (database) but rather that you trigger events onto some kind of queue. These events then persist in the queue for a time and then can be asynchronously acted upon. This allows for a number of interesting patterns, including undo, replay, etc.

Interesting, particularly useful for power users and high frequency usage products.

Have you researched which applications have the highest penetration of keyboard usage and why? Afaik most users even on desktop apps (e.g MS office suite) can only retain a handful of shortcuts. What's your strategy to train users to have a fully keyboard based navigation?

Btw did you use any open source library to manage keyboard shortcuts?

We have not found any reliable numbers on keyboard usage vs mouse input yet, but it would be quite valuable.

Compared to normal shortcuts the commands are easier to remember, because they mostly represent the verb for the action you want to accomplish. Instead of memorizing Ctrl + E or similar for a new article, you type /write or an alias like /new. This way you only have to know what actions are possible, without connecting them to an inconclusive key combination. Most commands will auto-complete after the first two letters, so you are not losing that much time either.

Our frontend is build on Vue.js and the shortcuts are handled by global JS events.

For thousands of transactions per month yes, API would probably be the way to go, but for up to a few hundreds we found spreadsheets work well and allow for easier bulk changes than other accounting softwares.

I personally also like software that allows you to become a power user. GnuCash is one of them, but unfortunately not accessible to the vast majority of people –- too nerdy :P (not a criticism!).

Most people don't want to learn accounting tbh, not even that – they hate doing it.

> Most people don't want to learn accounting tbh, not even that – they hate doing it.

How is it accounting tho? If anything it could be classified as tracking your income and expenses, but you would be doing that with a spreadsheet too.

I wrote about GnuCash a few years ago at https://nickjanetakis.com/blog/using-gnucash-as-a-freelancer...

But there's a screenshot in there near the middle showing how I tally up costs for Netflix. It's pretty much exactly like a spreadsheet. In a way it's even easier than a spreadsheet because a lot of columns are auto-filled out for you like the dates and all of the totals get auto-calculated for you. It takes like 3 seconds to make a new entry.

I'm running Django in the backend with Postgres.

That's right, I'm using react-virtualized right now with a customized react-datasheet. I found it's a good first iteration, as even fully rendering 100 rows will result in pretty poor performance, so the windowing technique is definitely a must.

That said I'd really like to reach Google Sheets-like performance. Do you know how it's built?

Haven't looked at Handsontable or agGrid, will check them out.

An excellent decision, I guess. I'm somehow thinking way too much about such details instead of starting any project. In my previous job, we have used PHP at the backend, but somehow, I like the syntax of python much more. And the community and number of projects around Django are just mind-boggling. So you are probably using Django-REST for the API?

With react-virtualized, you are already on the right path as virtual rendering - rendering only the currently visible cells - is the key in regards to the performance of DOM-based approaches. But if you want to reach google sheets performance, there is probably no way around canvas-based rendering (e.g. https://github.com/fin-hypergrid/core or https://github.com/TonyGermaneri/canvas-datagrid). Office 365 seems to use a canvas-based approach as well. The problem with the canvas-based approach is that interaction like mouse clicks and key navigation is a lot more complicated. I think one of the fastest DOM-based grids out there is https://github.com/6pac/SlickGrid. But there shouldn't be too much difference in performance to react-virtualized as both are DOM-based. Often these components are called "grid" if you search for alternatives. Feel free to contact me if you have some specific questions :-)

I think the limiting factor on my side is the complexity of the DOM – each cell contains a few more nodes, as opposed to most of the demos you will find which usually contains a simple node. Also, I'm not virtualizing horizontally yet, that's another potential perf booster as some of my sheets have lots of columns. Thanks for the suggestions, I'll hit you up to discuss more.

Arf... screwed this one up. :/

Hey – thanks for this. That's exactly right, the phase of switching from spreadsheets to a double-entry accounting software should not be painful.

With WeKeep you can continue recording stuff as you were doing in a spreadsheet, but your accountant can also do more advanced journal entries where needed (e.g. record equity, accrue expenses, write off bad debt, ...).

Great to hear! Yes a Stripe integration is the next obvious thing. Do you use anything to track your financials right now?

Thanks for the feedback! That's right, this is a cloud-based app. Mind if I ask, why was your experience poor with Quickbooks?

Quickbooks sent me over the edge when they forced me to buy a new version - they made the old version stop working.

On top of that it comes with all kinds of crap I will never use. I use it because my accountants are (were) simpletons who only knew that.

All that stuff on the main screen with the arrows.. while I appreciate an attempt at a GUI ( I usually prefer) I don't need any of those things and they waste space on the screen and cognitive time sorting them.

I had bought the pro software years ago, non-cloud. They bricked it, forced to buy again, and kept pushing for the cloud option. I hate cloud options.

I did enough QB learning to find it's possible to take a spreadsheet and import expenses.. I almost started doing that instead of buying the new software so it could download from my banks.

If I used the payroll stuff I could see paying to update - otherwise it's just a huge program downloads a csv from my bank and puts a few same expenses in columns to export to my accountant - at least for me, and it's over priced for that.

I would make custom GUI screens for different businesses and have a preview with one-click change - if a business does not use the software for invoicing, take all that crap off the screen and put it behind a menu - this could make graphics larger and simpler.

I would have totally different GUI's for a conststruction business compared to a hair stylist compared to a dentist compared to web dev.. sometimes I think of these things and sigh.

So.. export to a format that accountants can use, sadly needs to be a thing that is prioritized.