What is the balance of technology and services in Caplight's business model, and how does it affect the company's scalability?

I'll give you where we are right now and where I think this is going to go, because I'd be lying if I said that there wasn't a huge service component right now. We are taking the whole mantra of “do stuff that doesn't scale early” to an extreme. In some of the projects that we have going on, it's also helping us learn who our clients are at their core, in terms of what they really want and what use cases will be most applicable to solve real problems that they have, mostly as it relates to risk management. And it's also helping us learn who our partners are and which groups are going to be the most helpful in turning this into a marketplace that can actually be electronically traded.

All of the service part of our business right now is slowly already morphing into being automated. One example of that: our first couple of orders that came in were heavily manually presented to our client base to go run a price discovery exercise, meaning if someone came and wanted to sell a call option on some asset, we didn't know what the price of that call option should be. There are different places that you can look to tell what the price of the underlying stock might be, but that's not a one-for-one equivalent on a derivative of that stock. So what the team and I would do is basically go and run what looks like an auction process -- granted via phone calls and emails to clients -- but still an auction process, nonetheless. We'd go out to 25 or so people who made sense as participants in that type of auction, and we'd collect bids from them over the course of a week or so. If there was a match, then that would move on to the next phase, which was more of execution.

That is a very repeatable process that can exist in a technology venue, so one of the first tools that our team is building on the product side is, not surprisingly, an auction tool. And the learnings that we have from running a handful of these auctions manually and seeing which ones got the most engagement, which ones didn't and evaluating what those reasons are, has helped us build a really slick auction tool that's going to make it easier for the clients to get feedback on their price discovery questions a lot faster. That's one example.

I would say that similar thinking applies to initiatives we have on the data side of things. So, how do we pull in as much data from other places but also make the entire ecosystem better by sharing that data out in the right way with people? For modeling tools that we're building out, how do you work with a client to understand what the downside looks like on their portfolio? Build a custom Excel model for them, if needed, and then learn, when you see a couple clients ask for the same thing, that “Okay, this is actually a software tool as well.” That's something our team spent time building. These are all examples of us starting with something that is very clearly in the services category, but within iteration two or three of it, starting to figure out that this is something that follows the same set of steps every single time. This is a tech product.

Right now, I think that we split time pretty evenly between service-type work and technology, but I would be very concerned if we were just trying to build technology without trying to get these reps in front of clients and partners. At scale, what you're going to see us look like is a very dev-heavy organization, where there is probably always going to be a 3:1 ratio of people who are technical to people who are not. That's starting to play out on our team right now. We need an early support team, meaning we need people who can fill roles that look like compliance roles, that look like legal, that are not technical in nature. Even right now, we're about 50-50 engineering and non-engineering. I think that we need that core group that is non-technical to lay the foundation, but beyond that, we're going to be scaling by adding technical talent.