I am available for long or short-term, part-time consulting engagements.
I love reading, and collecting quotes. The highlighting feature on the Kindle is nice, but there's no API to get at your own highlights, so I built a Ruby gem to scrape Amazon's Kindle site for my highlights.
In order to meet the demands of our customers for a more flexible approach to billing and invoice presentment, Chargify completely redesigned the way we handle subscription billing. This included adding the ability to define customer hierarchies, and allowing a customer to pay for a subscription that did not belong to them. This feature is essentially like replacing engine of a car while it was running. My role in this effort, as the Core Billing team lead, is to my team member are set up for success. This includes interfacing with our product and customer success managers, as well as the CTO, to work through the design and implementation of individual features, and the architecture as a whole.
Additionally, as an Individual Contributor, I am involved in the development of various parts of this re-architecture, using Rails, React, and Elasticsearch.
The Rapid Offer Builder allows Chargify merchants to preconfigure an Offer, which is made up of a product, any component combination on any of their price points, and coupons. Merchants can then configure their Public Signup Pages to use these Offers, allowing easy signup without burdening customers with choosing components and adding coupons. Additionally, Offers greatly simplify creating a Subscription via the Chargify API, since API users need only send an Offer's ID over the wire, instead of various product/coupon/component attributes. I contributed across the whole project, while focusing mainly on the changes needed to create Subscriptions from an Offer alone, and the changes needed for our Public Signup Pages to work with Offers.
The first iteration of the dataset that drove Chargify's Subscriber Analytics did not give uers the ability to filter by products. As such, a user could only see how many subscribers churned across all their products, but within an arbitrary subset of products. Additionally, there was no way to see how many existing subscribers switched between products. Our efforts centered around introducing a new dataset, powered by Elasticsearch, that would yield such insights. In addition to playing the team lead role, I worked extensively on the data model and the back-end work necessary derive the data we needed from application events. We joked that we spent 2.5 months working on a dropdown, but it took a lot of work to build the dataset we needed to make the product filtering dropdown a reality.
Previously, a Chargify subscription could only have one "active" coupon. This limited our merchants' ability to customize their product offerings. With the multi-coupon feature, merchants can "stack" multiple coupons on a subscription. A coupon can discount either "full-price", or "compound" with other coupons. In addition to leading the project, my work on this feature was mainly in the back-end: reworking the data model and coupon discount calculators. Like the "component price-point" work, I also spent time cleaning up code that no longer made sense given the new data model relationships, and ensuring backwards compatibility with the API.
Previously, components (think subscription "add-ons") could only have one set of prices. With component price points, merchants can have multiple sets of prices for the same component. For example, they can have an "MSRP" set of prices for Widget, and a "Wholesale" set of prices for Widget. All revenue, for both of Widget's "price points", would be reported under the Widget component. This gives merchants more pricing options with less overhead, since they don't need to create a different component for what is essentially the same service, just to achieve pricing flexibility. In addition to leading the project, my work on this feature was mainly in the back-end: reworking the data model and component cost calculators, cleaning up code that no longer made sense given the new data model relationships, and ensuring backwards compatibility with the API. I did a little bit of the React front-end as well. Here's a nice write-up at TechCrunch about the feature: http://tcrn.ch/2GFI34w.
Gives merhcants insight into the performance and efficiency of dunning strategy. We hooked into the dunning lifecycle to generate data, which was then persisted into Elasticsearch. When viewing revenue retention analytics, that data is read back out by Rails and turned into props for the ReactJS front-end. I worked mostly on the Rails and Elasticsearch pieces of this feature, with a small bit of React.
Gives merhcants insight into their MRR (monthly recurring revenue). We hooked into relevant events in Chargify to generate MRR data, which is then persisted into Elasticsearch. When viewing MRR analytics, that MRR data is read back out by Rails and turned into props for the ReactJS front-end. I worked on the entire "stack" for this project: Rails, Elasticsearch, and React.
Allows merchants to configure the webhook events each endpoint receives, individually. The previous implementation had one list of subscribed webhook events, and each webhook received the same events. My first production ReactJS code.
Enhanced Chargify's existing Shopify integration by adding the ability for Chargify to automatically create new Shopify orders for merchants whenever a new customer signed up to a plan, or their subscription renewed. This was accomplished with a combination of Chargify's own webhooks and Shopify's Orders API. The integration is a separate app that, when enabled for a merchant, would receive webhooks whenever a Chargify statement was settled for their site, and then enqueue them for processing. Once processed, the webhook data would be transformed into the body of a proper Shopify Order, and created via the API.
An internal API and external interface that allows Chargify admins to send notifications to merchants with various levels of granularity (e.g. "send this message to all admins of Acme Online") or ("send this message to the owner of every site in the Chargify database"). Useful for communicating things like problems with subscription processing, new features, or upcoming API changes.
A dashboard designed to show the sales volume for merchant's products and components over time. This was my first time working with Elasticsearch in a non-trivial context.
Added support for the Cybersource and Chase Paymentech gateways. This involves working with ActiveMerchant.
Sole developer for TalentSoup, a marketplace connecting talent (actors, actresses, models) with producers of advertising imagery. Built using Rails (from 2.3 to 3.2), MySQL, Apache + Phusion Passenger. This was the first big app I built with Rails. I learned how to manage a growing codebase, implement subscription billing (using Chargify of course), use S3 for photo hosting, and set up Graphite + statsd for analytics. In addition, I was responsible for all server and database administration.
Built for TalentSoup. A project management app for photo producers. My first attempt at a multi-tenant architecture (ala Basecamp). Similar stack to TalentSoup (Rails 3.2, MySQL, etc.) but running on nginx instead of Apache.
Sensus Divinitatis News
Essentially a Hacker News clone for the Christian community to discuss trends in theology, apologetics, and church planting. Built with Rails 3.2. The fun parts about this app were implementing a time-based ranking algorithm, and writing code that "posted back" to blogs that were submitted to SD News.
Sensus Divinitatis Publishing
A publishing company in the Scottish Calvinist tradition. We published The Kingdom Has Drawn Near: Studies In The Gospel Jesus Preached and are working on another volume.
The love of craft beer taken a little too far. Homebrewing is a fun hobby, and has certainly enhanced my enjoyment of beer.