Project Ricochet's Fortune 10 Client Project
The development experts at Project Ricochet use open source frameworks and technologies to build custom, real-time experiences for their clients. When a Fortune 10 healthcare client tasked the agency to create an internal software subscription service for their IT department, Project Ricochet looked to Reaction Commerce. We spoke with cofounder Casey Cobb and Meteor developer Dan Castellon, who told us more about their discovery process, their client project, and the benefits of building on Reaction.
Reaction Commerce: Tell me more about the client project you’re working on.
Dan Castellon: Back in 2015, we built a custom internal app for our client’s technical employees, who needed to keep track of employee software subscriptions. New employees would create a subscription by reaching out to this app, saying, "I need so-and-so software. Can you set it up for me?” The admin would then go in and trigger a new subscriber, key in information for the subscription, create an onboarding task, and someone else would open up the task in the app. Provision piece of software. Get it out to the user.
Six months ago, we looked into automating that process. Now, employee can go into a customized version of Reaction Commerce and order the software themselves. All of the products are managed by the company’s subscriber management system (SMS) and they come right into Reaction automatically. Users choose their software, fill out the information needed to provision it, and check out.
RC: Almost all of our dev partners weigh the costs and benefits of building something custom for their client vs. building on a third-party application. How did you ultimately decide that Reaction would be a good fit for this particular project?
Casey Cobb: When exploring a new project, our first step is to make sure we have all of our client’s needs clearly laid out. We went through our client’s requirements in a structured, systematic way, which also kind of forced them to pre-chew their food a bit.
From there, we did what we call a spike, where we wrap our minds around tricky things that we have questions about. We reached out to Reaction’s support team and talked about specific elements. Then we were able to go back and forth with the client regarding their actual needs. What’s cool about this process is that the client lays out their specifications in a way that’s not intimidating. We went through this process, and then arrived at Reaction being the primary viable choice for their needs. Would Reaction provide us with what we need? We determined that it would.
RC: What were some of your client’s table-stake needs?
DC: Multi-tenancy was one of the main reasons why our client wanted to go with Reaction, along with the image gallery feature and the shopping cart.
CC: Their biggest requirement was the ability to pay for things with a general ledger rather than a credit card. To Reaction's credit, it was very easy to swap out the default payment method for a company number that gets charged, rather than a credit card.
The client also wanted to see if they would be able to use Reaction for other aspects of their organization. Ultimately, they were looking to establish a successful model for long-term use throughout the entire company.
RC: Your team put a lot of custom work into this project. I know you touch upon this in your case study, but could you run me through the entire development process, from start to finish?
DC: The first step was to install Reaction Commerce and set up the base repo.
The second piece involved writing an integration between SMS and Reaction Commerce—figuring out how they would communicate with each other. Our client’s IT department didn’t want to go into both to create products, so the goal was to keep the SMS as our source of truth. We actually skipped the Reaction admin panel altogether by connecting to MongoDB. We also took advantage of remote-collections, a Meteor package. Once we had the first batch of products in Reaction, the next step was to set up a sync, so any time a product was updated in SMS, the image updated in Reaction Commerce.
The third step: build out a custom Product Detail Page. On the PDP, we had a custom order form where users can select who the order is for. Managers can place orders for their direct reports by 1) searching the first and last name of that person and 2) entering info relevant to the new subscription product detail tabs. I noticed that Reaction doesn’t come with product tabs—for technical details, terms of service, etc.—and that’s one thing they wanted.
Next, we built out a custom checkout flow, which basically featured more fields, mostly configured in SMS. SMS has this concept of entities and fields, so like a content management system, users can create fields and designate them to appear on the Reaction Commerce checkout. Users fill out all these fields and select what is called a billing geo, which ties back into who's going to pay for it.
We removed a bunch of default plugins that Reaction came with, like credit card payments, inventory management, reaction.json, and then added a bunch of backend customizations. To place the order, I had to override a couple methods that typically converted a cart item into an order. I added logic to take the order and fed it over to SMS. We've got an approval system there, so when a new order request comes in, someone in the SMS has to approve it in the app directly or through an approval email.
The user then gets a confirmation email, and their order status changes to ‘Approved.’ Once an order is approved, SMS takes over, and Reaction is done. All in all, it took about 2 or 3 months to get the minimum viable product up and running.
RC: What were some of the challenges you ran into while developing on Reaction? Is there anything we can improve upon?
DC: I had spent a couple months building out the MVP, but by the time I had finished, the API had changed significantly! That was a bit of a pain point. On the one hand, an upgrade means having to update your custom module or plugin to work on the latest version of the API. On the other hand, the updates did make a lot more sense for some of the API. For example, Reaction was using Blaze, but once the application switched to React, I was able to cut out a bunch of my custom overridden Blaze templates and remove a whole bunch of custom code, just because I could override specific React components. So it was definitely an upgrade for the better.
RC: You mentioned that your project was completed well under budget + a couple months ahead of schedule. Were there any other measurable wins?
DC: The project saves the admins a considerable chunk of time when setting up a subscription. Typically, it takes a good half-hour to get the subscriber's info loading, and then you have to set up the subscription itself, which involves filling in 30 to 40 fields. So much time is saved, even with just one person using the tool.
CC: One of the main reasons our client wanted to go with Reaction, Meteor, and Node.js in general was that things just develop more quickly. They were able to pop stuff out really fast. An internal champion laid out his requirements, had us develop in a really rapid way, and left with an end-product relatively quickly—they’ve just been raving about it. It’s been a win on all fronts: discovery, technology, team, process. It’s been a really awesome experience.
To learn more about Project Ricochet’s Fortune 10 client project, check out their case study, Reaction Commerce in the Wild: A Corporate Case Study.