The evolution of a core feature in the mobile apps.
Minimum Viable Feature
One of the most popular features of the Control mobile app was real-time alerts. Alerts notified our users each time a new event happened on their Stripe account, such as a sale, by way of the Control app.
I initially launched Control as an an Android app on Google Play with a singular integration into Stripe’s API. Our initial tech stack served as a simple conduit for Stripe webhooks. The Control service would intercept a webhook from a user’s connected Stripe and then convert that into a push notification. Push notifications were delivered to a user’s Android device via Google Cloud Messaging (GCM).
Launching iOS Support
Within a few months of launching our Android product , I had acquired a competing iOS product through an M&A. Consolidating this product with our platform and publishing via the Apple app store effectively doubled our market . My business could now target iOS users. With this expansion my developers integrated with Apple’s Push Notification Service (APNS).
Control’s mobile messaging stack.
Extensibility of Integrations
As my team started integrating more payment platforms, we needed a more sophisticated messaging broker system.
Each of our payment partners had a unique way of designing their data objects and the data stored within them.
Our customers required standardized push messaging for each broad type of event (sale, decline, new customer etc. ) .
As part of a broader data aggregation and normalization strategy, I created extensive documentation for all of the different types of data objects we would be intercepting from Stripe, Square, PayPal, Authorize.net etc. I then standardized the messaging we would deliver to the iOS and Android as meaningful, user friendly expressions.
As our tech stack evolved we improved the way we were integrating with 3rd party payment APIs.
Our architecture had scaled to handle the interception of thousands of webhooks per second , store those data objects, and then interpret it as required by the various user interfaces (iOS, Android and web apps).
This abstraction facilitated my data analytics strategy and also allowed us to produce business logic around the real time messaging.
With the architecture now in place, my team was able to create intelligent fraud alerts delivered in real-time to our users’ Control apps.
The Control API would intercept webhooks, interpret them based on conditional rules assigned within our business logic layer, and then provide our users with timely information about a high risk transaction along with the means to take action on that transaction.
Building an intelligent transaction system forced us to create complex and large scale QA & testing processes as we had to validate thousands of different scenarios.
Launch & Product Marketing Playbook
Once we had the new feature fully baked and ready for launch, I worked with our marketing and design team to create all of the related assets for the promotional push.
We had developed a Product Release Playbook which served to standardize and synchronize our activities around major feature releases.
A release would entail a wide span of messaging updates:
– Updates to our Intercom in-app lifecycle messaging
– Crafting of an email blast and press release
– Updates to our online support material
– Training of our support staff
– Updates to the content and creative of our website
– Production of ads in various formats for the ad networks Facebook, Twitter , Google Universal App install campaigns
– Updates to our Apple App Store and Google Play Store assets and content (including localization in 5 languages)
– Modifications to our SEO and bidding strategy
– Blog posts and relevant thought leadership articles
I maintained an extensive list of KPIs we used to measure the success of our product launches. The best validation though would be feedback directly from our end-users such as Richard Lazazzera from business blog ‘A Better Lemonade Stand’ who cited Control as his #1 business app.