The Prototype Buys the Time
The first move wasn’t a spec. It was a Figma prototype.
Part of my role was protecting the development team from ideas that weren’t ready. A name and a direction isn’t a feature. It’s a starting point. Building something clickable first let me pressure-test the concept, think through what a real build would actually require, and surface the right questions before anyone was assigned to it.
The prototype did two things. It gave the concept something tangible to travel with, animated interactions, a real workflow, something that could be shown at a green industry conference and come back with signal instead of assumptions. And it bought the runway needed to figure out what shipping this would actually take.
What came back from the conferences was simple: they loved it. When can we build it? That was enough to get it prioritized. It was also when the real work started.
Building the Foundation First
Virtual Door Knock was a geo-location-based feature and Captivated didn’t store addresses on Contacts.
The platform was built around phone numbers. That was the entire data model. Getting VDK onto the roadmap meant solving a problem that predated the feature: Contacts needed address fields, and not every organization needed them. The solution was a toggle at the organization level. Address fields only appeared if the org had them enabled. A second toggle controlled geo-location specifically, adding lat/long fields to contacts and triggering automatic conversion for any address already in the system. If a client’s CRM already had lat/long data, we could import it directly rather than paying a third party to generate what already existed.
The import pipeline needed to expand too. Accepting address, city, state, zip, and lat/long fields sounds straightforward. Data validation is not. Partial addresses, inconsistent state codes, missing postal codes, edge cases that couldn’t be rushed. Getting the foundation right mattered more than hitting a date.
Captivated’s mobile apps ran on Capacitor, a framework that bridges web code to native iOS and Android. Relying on the device’s geo-location meant the version of Capacitor in production had to support it reliably. That meant an upgrade before testing could even begin. Not glamorous work, but without it nothing else moved.
None of this was in the prototype. All of it had to exist before a single line of VDK code was written.
Fitting VDK Into a Monolith
With the foundation scoped, the feature still had to work inside an architecture that wasn’t designed to support it.
Captivated organized its data around Organizations and Accounts. An Organization might be a single lawn care company with one Account, or a franchise with dozens representing individual locations. VDK was the first feature that needed to live at the Account level, which meant solving for a pattern that didn’t exist yet in the platform. One location could pay for and enable VDK without it surfacing across every other Account in the org. Access was then designated at the user level too. Not every person on an account was a field technician. Office staff and receptionists didn’t need a geo-location tab on their device.
Templates presented the same challenge. They lived at the Organization level, available across every account by design. VDK was the first feature that needed templates to belong exclusively to the account using them. Rather than restructure where templates lived across the entire platform, VDK got its own designated template type, scoped to the account, separate from everything else.
Every one of these decisions had to be made before the mobile experience could be designed. The feature the tech sees is two swipes and two taps. Everything underneath it took time to get right.