About Us

Our Mission

Empower every business to take control of their digital transformation

Our team is passionate about making software development more accessible, faster, cheaper and higher quality and we've been on this mission since 2006.

FormulaDB is the latest iteration of our technology which empowers non-developers to customize and build web applications, vastly speeding up the digital transformation of any organization.

FormulaDB Timeline

• 2006: generated UIs based on simple JSON metadata for simple SET/GET operations, all custom logic hand-coded
  • Noticed that customers are asking very often for Excel Exports
• 2007: first company created offering custom software development based on our internal framework
• 2009: Designed more strict API for implementing custom business logic: Ruby (Activerecord) for server side, Backbone.js on client site
  • Started wondering why business experts can build complex Spreadsheets but have difficuly understanding and reasoning with basic imperative programming constructs: variables, control flow
• 2012: Tried to build a metadata language for implementing custom business logic using jquery-like DSL for defining RDBMS-like triggers between domain model entities (tables), targeted at non-programmers but still techincal people: QA, Support, Deployment
  • Problem: imperative programming is difficult for non-programmers. Breaking down a task into imperative programming control flow statements, keeping track of mutating state, these are hard without formal programming training.
• 2015: FormulaDB concept started to take shape, use the same metadata approach as before: define Entities (or Tables) but the business logic should be defined in a pure functional domain specific language, no more imperative trigger definitions.
  • At this point it was clear why non-programmers can sucessfully use Spreadsheets: pure functional formulas, no state/variables to keep track of, no side-effects to keep track of mentally, a user could build a complex spreadsheet focusing on one formula at a time
  • However Spreadsheets have issues:
    • "Various studies report that nearly 9 out of 10 spreadsheets (88%) contain errors" ^*, because it is difficult to see what you have messed up 2-3 Sheets away when you change/add/delete a formula. (TODO: more research on this issue needed to better identify the root causes)
    • More importantly spreadsheets don't help users implement concurrency and business transactions
    • Spreadsheets also are not very user friendly for data entry and visualisation, users would need a full blow UI builder or at least a form builder.
  • The challenge for FormulaDB was how to enable users to work with familiar formulas/functions but in the same time allow them to implement business transactions, some classic examples:
    • inventory management with real-time stock positive validations
    • money transfers between accounts with real-time balance positive validations
  • The name chosen back then was MetaWiz (Metadata Wizard) instead of FormulaDB
• 2016: Actively started working on FormulaDB (MetaWiz back then)
• 2017: Kappa architecture Streaming plaform/framework PoC powered by Kafka Streams (Event Sourcing/CQRS).
  • The goal was to allow developers to implement custom business logic/transactions (mostly in the IoT industry) without worrying about scalability (failover, sharding), ACID, distributed transactions, etc. Ideally users would just implement the actual business logic without any boilerplate, the platform would make sure that logic would run in a event-sourced distributed scalable environment, providing consistency where needed (paying the associated performance penalties).
• 2017: FormulaDB, PoC powered by CouchDB/PouchDB with Formula Engine and Transaction Manager added on top offering ACID-like guarantees
• 2018: abstracted storage layer, added in-memory as a reference implementation and Postresql as the production implementation, dropped CouchDB for now
• 2018 Sep: joined Techcelerator
• 2018 Dec: Pre-Seed Round from Gapminder, FORMULA DATABASE company created
• 2019 April: started moving UI from an Angular-based form builder to a full blown website builder covering Intranet/Corporate as well as Internet use-cases
• 2019 June: moved the PaaS part of formuladb from VMs + docker-compose to k8s
• 2019 Oct: formuladb highly configurable CSS/HTML templates based on Bootstrap 4 with many new utilities and components 

Inspiration and Credits

A big "Thank You" to a lot of smart people and good technologies and algorithms who inspired us and continue to inspire us, we list here just a few in no particular order:

• Event sourcing/CQRS
• imperative vs functional vs declarative vs logic vs rules-engines vs visual (BPEL, BPMN, UML) programming
• Spreadsheets formula engines, Recursion
• Stream processing (Storm, Spark Streaming, Kafka Streams)
• DDD aggregates with eventual consistency using events
• Cassandra seamless massive scaling and constraints imposed on CQL to maintain predictable performance (e.g. partition key), tunable consistency, timeuuid, LWT
• Kafka consumer groups fail-over and load-balancing, Kafka Streams State Stores
• Kappa architecture (Jay Kreps)
• Turning database inside out (Martin Kleppmann), duality table-stream
• Persistent Data Structures, Clojure/Datomic (Rich Hickey), Immutable.js, Durable Persistent Data Structures
• Polyglot Persistence (Martin Fowler)
• Elasticsearch timestamped indexes, Kibana, curator
• https://www.reactivemanifesto.org/, http://reactivex.io/, rxjs and marble testing
• Key Value Stores, Document stores, Column-oriented Stores, Immutable data stores, CouchDB replication and conflict management
• CouchDB "Accountants don't use erasers", immutable data stores using append only files, conflict management, views
• PouchDB and LevelUP ecosystem
• Git, diff, merge, conflict management, consistency
• Database Cracking, auto-tuning databases
• Distributed transactions and business transactions: 2PC, 3PC, Saga pattern
• Consensus: Paxos, Raft
• Kafka transactions
• Graph Databases, graph traversal query languages (openCypher, Gremlin, GraphQL)
• Generated UIs, Apache Isis
• Flux architecture, Redux/Ngrx state stores
• HATEOAS
• Openstack, Kubernates, DC/OS: scaling an failover is being built into cloud tools, a cloud native DB could borrow functionality from these tools and not implement it internally
• Jepsen tests, Netflix Chaos Monkey, testing for distributed systems/databases

Core Team

Partners