If I were starting the ScrumDo project today, there's some pretty significant things I would have done differently. Here's a few of the technical items:

Server Side

Django REST Framework instead of Piston When we made the choice, both projects seemed pretty active, but it's clear DRF is the winner in the Django API framework space. We used it for the GetScrumban game, and it's a lot easier to work with.

More business logic separation Too much of our logic is in our API handler code and needs to get moved out to stand alone manager classes that can more easily be unit tested. All the new stuff we've been doing is in that direction, but I haven't bit the bullet and done a few major refactorings that I should. Right now, we rely on a lot of FrisbyJS to test those API calls instead of much simpler/faster pure python unit tests.

API structure For the API we use internally, we more or less followed a REST structure, and there are some pretty significant performance issues because of that.
I'd probably want to structure our API to more closely give exactly what a given piece of the UI needs to render. For instance, many times we don't need the entire card data structure for what we're doing in the UI, but getting it all is the only way to request a card. Or maybe a piece of the UI needs to make several calls to piece everything together, and it'd be nice if it could be batched into a single call. I've heard some good things about GraphQL that would make me want to take a look at it.

Client Side

Loader/Packaging Right now, we concat all our source files together minify them and serve them up. That means you load a lot of pieces that you might never use in an average session. It's partly that way because we migrated from JS->Coffeescript->Typescript over the years and each migration was done in pieces. I'd definitely want to use something like Webpack next time and be a lot more aware of the issue.

Dependency Management We've got a lot of third party dependencies, too many. 2.2MB (587KB gzipped) worth, and I don't even know if we use them all anymore. We need better inventory and tracking of them. For instance, JQuery UI is in there, but I can't for the life of me remember what still uses it. (mental todo - go remove it and see which tests break).

CSS deprecation We use Compass/SCSS, and I'm pretty happy with the structure of our CSS. But we're horrible about removing unused pieces. I'm relatively certain there is a good chunk of our css classes that are no longer used anywhere. We really need a better way of tracking and managing that.

Better model manipulation We do an ok job at having a sane data flow in the UI, but it's not formalized and varies a bit. Implementing some sort of more rigid structure would help prevent some classes of bugs. Been reading a lot about Redux lately, and it seems pretty good. Even a simple command pattern would be an improvement.