Show HN: Forms – Easy custom database applications

I strongly disagree with that. You should align your pricing with the value the user receives. To do this optimally, you need to have a good grasp of who your user is, how much value he receives from the software and how the typical purchasing process looks like. For an early stage company, all these questions may not be answered yet, so it is best to wait and learn what the users do with the product before prematurely optimizing pricing at an early stage.

FWIW I did this for a client application and it wasn't real fun. Took a few tries to come up with something that was reasonable at column-level resolution.

Figure you need at least read and write permissions, you need to have table-level granularity, you want to have column-level granularity, you want to make it easy to manage groups of permissions (roles), but you also want it to be easy to create users with exceptions to those roles. For example, how would you create permissions for a group that gives you access to all of a table except a specific column?

You need, basically, ACLs, and afaik there isn't a standard recommendation for that yet (that I could find).

I settled on a roles table and a permissions table, with descriptors with wildcards for different operations (like, "read-client-address", "write-client-notes", "∗-client-∗"), and allow/disallow/inherit options. For instance, a "demo" account has "disallow ∗, allow read-client-∗, disallow read-client-name", etc. On login the permissions are loaded for the user signing in and then each DB operation checks to see if the operation is allowed() in a function that resolves wildcards and priority and does a few other tricky things.

There are probably better ways to do it, but anyway, the moral is that there should be a good reason for needing more granularity in permissions before someone decides to implement it.

That's a good point, the report builder doesn't support OR at the moment. The interface for that should be interesting.. We may just allow custom SQL queries and be done with it. We definitely plan to get into BI/analysis, I'll check those out.

We backup and log literally everything. The user actions aren't shown to Organization admins yet, but that's only because we haven't built a frontend for it. We're working on showing a list of actions taken by connected users. All changes to forms and submissions are also diff logged, and you can reset to any older version. The frontend for that has some minor bugginess that I'm working out, though.

Or just provide an OData feed so users can do that themselves in PowerBI (or whatever).

The regex is probably more useful for the text fields, but it's a validation regex for the content of the field. We check it both client and server side, to make sure the user-entered content fits it.

The "Done" in the lower left is actually purely design at the moment, all it does is take you back to the add fields menu. Someone suggested that we add it in case users are confused about exiting the panel for an individual field.

We're working on adding custom Javascript scripting partially for this purpose. The idea is to set scripts that will run at different parts of the submission process. For example, one script runs for the submission page and you can control the frontend. Another would run backend in sandboxed NodeJS with custom validation rules on each new submission.

Ideal Scenario:

Can iFrame the form on own webapp (pass an ID iFrame in url), use it to collect data through custom form. Then can access result of this data via an API.