I'm wondering if you've done any performance testing. As you're probably aware, that is one of Contours biggest shortcomings.

Oh yes, I'm very aware. I've built Formulate with performance in mind.

I'm not anticipating any performance issues for the situations you've described. Just to be sure, I've created a task for myself to do some testing around the extreme situations you've described: https://github.com/rhythmagency/formulate/issues/39

Here are some things you might be interested to know or consider:

• Formulate does not use SQL by default, though the persistence layer is swappable, so you could support SQL if you wanted. By default, Formulate stores all information about forms in JSON files. They're organized and named so that in most situations, files are directly accessed without the need to scan all of the files.
• Form submissions are not stored anywhere by default (currently, there is only an email handler, but you can create your own). Also, all handlers are asynchronous, so form submissions should be return nearly instantly regardless of the size of the form or number of forms.
• If you do notice any performance issues, I will absolutely address them, though perhaps not right away. I am open to pull requests if you happen to have time to fix any issues you notice (Formulate is open source). I've created Formulate to have a low barrier to entry for contributors. Building is potentially as simple as cloning the repo and double clicking a batch file.
• Since the form builder is based on AngularJS, you might run into performance issues with a few hundred fields. However, just like Archetype, I imagine we could address those issues by conditionally rendering fields based on whether or not they are expanded.
• If you are curious about the things that can be swapped out or extended in Formulate, you can read about that here (will be expanded with further details in the coming weeks): http://www.formulate.rocks/extensibility

Let me know if that answers your questions. Thanks for your interest!