Gravity Forms and GravityKit — a K2 Studio case study

Client: GravityKit (Katz Web Services) and Gravity Forms (Rocketgenius), USA
Years: 2013 — 2020
Scope: Development (backend), architecture
Stack: PHP and WordPress, React, Svelte

The problem

Gravity Forms is one of the most widely used form solutions for WordPress; it runs at universities, international organisations and large companies. GravityView sits on top of it and turns accumulated entries into an application: catalogues, tables, maps, search and editing of records directly on the site.

Working on a product like that differs from working on a site. A mistake cannot be rolled back on one server: an update goes out to every installation at once. Backward compatibility is not a preference but an obligation to thousands of other people’s sites and plugins.

What we did

GF_Query — the query engine for form entries introduced in Gravity Forms 2.3: joins, conditions and sorting instead of assembling SQL by hand.
The GravityView backend: showing entries on the site, filtering, search and editing with no administrator involved.
Compatibility and performance on other people’s installations, which cannot be tested in advance.

Result

Code from 2018 still runs today GF_Query went into Gravity Forms 2.3 and remains in the product: it executes on every site where those forms are installed. We left the project in 2020, and what we wrote keeps running every day, without us.

Why this one is us

Product development instils a discipline that client work does not demand: thinking about an update you cannot recall, and about compatibility with code you did not write.