Not OP but authentication is easy, authorization is a cross-cutting concern that often requires custom code. E.g., there are people and teams, both of which can have different kinds of access to something (read/write). Sometimes teams have sub-teams. Do the sub-teams have access to the parent teams' resources and/or vice versa? Also what kind of sharing are you going to support? Do people have to have an account to view stuff shared to them or can you just send a link? There are some efforts to make custom DSLs for describing authorization policies, to avoid cross-cutting code[1].

Computed fields require different treatment at every level of the stack. This isn't inherently hard, but it is an extra feature these low-code/no-code platforms need. Where things get difficult is in migrations. It's common for a field that is computed at the beginning to become customizable, or for the computation to change. When that happens, what should the value be for old columns? Computed fields also often pull data from multiple other tables, which may require some combination of custom queries and database optimization.

[1] https://github.com/osohq/oso

One example, you're creating order form, which contains many order lines.

When we create a new order line, the tax, remainaining inventory for item must be dynamically computed before submitted and also to display after successfully saving.