Kevin Hurley grew up in a multi-kid house, which is where he got his competitive nature. He used to play 2 on 2 with his Dad and siblings at home. He went to school for electrical engineering, and funny enough, interviewed for a computer science job by accident, effectively stumbling into the trade. Outside of tech, he spends his free time with his fiancé, planning for the wedding, and visiting Manhattan beach for a good walk .Kevin was part of the team that attempted to launch crypto at Facebook. Although that didn't work out, they realized that the backbone of the system needed to be built on something more common - and something that was lightning fast.This is the creation story of Lightspark.SponsorsP0 SecuritySpeakeasyQA WolfLinkshttps://www.lightspark.com/https://www.linkedin.com/in/kevin-p-hurley/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
This episode is sponsored by P0 Security. Cloud governance is a problem facing many organizations. With P0's universal access governance platform, your security team can identify access risks and automate the user access lifecycle, all without interrupting developer productivity or disrupting production operations. Visit p0.dev to learn more and secure access for all identities, human and machine.
We started out by running a full L&D node for each customer. Obviously, that wasn't something that would be scalable or efficient long term. If you have to spin up an AWS pod for every single customer, if you have hundreds or millions of customers, that's obviously not going to scale well. So we started off taking that as we want to get something out on the market.
We want to be able to prove that we can actually simplify how Lightning works and make it so that customers can easily integrate. And from there, we'll be able to figure out how we scale better and actually make the right trade-offs later on. But we didn't want to overcomplicate things at the start until we actually felt like we had something that was going to be valuable. I'm Kevin Hurley.
I'm the CTO and one of the co-founders at LightSpark.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Who share what it takes to change an industry. Who built the teams that have their back. Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as we grow. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve, my dude.
Took off the shelf and dusted it off and tried to begin. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on CodeStory. I'm your host, Noah Labpart. And today, how Kevin Hurley is building open payments for the Internet. Enterprise-grade, secure, and on the Lightning Network. This episode is sponsored by Speakeasy.
Grow your API user adoption and improve engineering velocity with friction-free integration experiences. With Speakeasy's platform, you can now automatically generate SDKs in 10 languages and Terraform providers in minutes. Visit speakeasy.com slash codestory and generate your first SDK for free. This message is sponsored by QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Grotta, and Autotrader, you're in good hands. Join the Wolfpack at QAwolf.com.
Kevin Hurley grew up in a multi-kid house, which is where he got his competitive nature. He used to play two-on-two with his dad and siblings at home. He went to school for electrical engineering and, funny enough, interviewed for a computer science job by accident, effectively stumbling into the trade.
Outside of tech, he spends his free time with his fiancée, planning for the wedding and visiting Manhattan Beach for a good walk. Kevin was part of the team that attempted to launch crypto at Facebook. Although that didn't work out, they realized that the backbone of the system needed to be built on something more common and something that was lightning fast.
This is the creation story of LightSpark.
At LightSpark, our goal is to really help customers move money more easily and efficiently. If you look at the payments rails that exist today, they're generally pretty antiquated. They have existed since the 60s and 70s, largely unchanged.
And what we want to do is take those antiquated payments rails and bring them to the modern day, bring them to the internet age where you can move money just like you move data packets on the internet.
Instead of payments that take days to settle, are super expensive, don't actually work on weekends and nights, we want to have real-time payments that actually work like they do in the modern day, or like they should in the modern day. And we're doing that by building on top of Bitcoin and the Lightning Network. A bunch of reasons for that.
A lot of us actually came from Facebook, where we were building Diem. Coming from there, we realized that you really need something truly neutral and decentralized as a settlement network for payments globally.
We took that mission that we had at Diem of trying to build this global, interoperable, open protocol for money and bring it to something that we think can actually really take off and truly revolutionize how money works. That's why we ended up on Bitcoin and Lightning. Initially, our plan was to try to make Lightning very simple.
Take all the complexity of Lightning, abstract that away, and make it so that customers can onboard to Lightning really easily. And then we start to add new use cases to make it into something that is really valuable for our users and is something that they can actually use for real-world use cases.
Tell me about the MVP. And this will be interesting for that first version of LightSpark that you built. How long did it take to build and what sort of tools were you using to bring it to life?
Yeah, it took about a year. So we started in April is when we first started LightSpark. And I think it was probably around April of the next year that we actually put out our first product.
The initial plan was we were going to take L&D, which is a Lightning implementation, run that on AWS, and provide a really simple interface to run those nodes, to provide inbound liquidity dynamically, provide some machine learning for determining good routes, and make it really easy to integrate SDKs. What we found was that even trying to simplify it, it was still too complex.
We took that to customers and even those that had been in the Bitcoin space or the crypto space for a long time had a hard time understanding some of the core concepts of Lightning. Because in lightning, you have things like channels, whether pairwise channels.
The way I think about it is beads on an abacus, or if you ever went to the dentist in the US, they always had those toys where you had those beads that you pushed along a wire. That's what channels are, where sats are the beads on the wire, and it goes between point to point. And that concept is vastly different than what exists in really any other L2 or L1.
So it was really hard for customers to understand who do we open channels to? What are channels even mean? How do you get inbound liquidity? How do you make this work well? So we found that the first version was still too complex.
We quickly went back to the drawing board and tried to iterate on that and get it to something that was even simpler and that kind of abstracted the notion of channels entirely.
In building that MVP, and you touched on some of these in a high level, but I'm curious about decisions and trade-offs you had to make in that first version, right? And maybe it was something you learned, or maybe it was some hard decision you had to make as far as how you were going to approach it, what you were going to prove, all those sorts of things.
Maybe dive in a little more to some of those decisions and trade-offs and how you coped with them.
Like I mentioned, we started out by running a full L&D node for each customer. which simplified our stack because that's how L&D is packaged today. But obviously that wasn't something that would be scalable or efficient long-term. If you have to spin up an AWS pod for every single customer, if you have hundreds or millions of customers, that's obviously not going to scale well.
So we started off taking that as we want to get something out on the market. We want to be able to prove that we can actually simplify how Lightning works and make it so that customers can easily integrate. And from there, we'll be able to figure out how we scale better and actually make the right trade-offs later on.
But we didn't want to overcomplicate things at the start until we actually felt like we had product market fit and that we had something that was going to be valuable. I think another area that we had a trade-off was that we really just overcapitalized our nodes initially.
So until we actually understood the network better and could see the usage patterns of how our customers were using the network, the easy solution was just to throw more capital at the problem, make it so that we could make sure that we can route whatever transactions our customers might have and ensure they have a good experience no matter what their usage patterns might be.
Now that we've been running for a while, we can much more efficiently manage that. Once we've seen the usage patterns and once we've been able to understand better how customer funds might flow, we can make sure that we're actually connected throughout the graph really well without having to overcapitalize.
And actually, that's a huge advantage that we have is that we can use our capital extremely efficiently and not need to lock up a ton of money in individual channels.
This message is sponsored by SnapTrade. Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This episode is sponsored by Speakeasy.
Whether you're growing the user adoption of your public API or streamlining internal development, SDKs can turn the chore of API integration into effortless implementation. Unburden your API users from guessing their way around your API while keeping your team focused on your product. Shorten the time to live integration and provide a delightful experience for your customers.
With Speakeasy's platform, you can now automatically generate up-to-date, robust, idiomatic SDKs in 10 languages and Terraform providers in just a matter of minutes. SDKs are feature-rich with type safety, auto-retries, and pagination. Everything you need to give your API the developer experience it deserves. Deliver a premium API experience without the premium price tag.
Visit speakeasy.com slash codestory to get started and generate your first SDK for free. You've got the MVP. It's working. You're ready to move forward. Tell me about how you progress the product and mature it.
I think to wrap in a box a little bit, what I'm looking for is how did you build your roadmap and how did you go about and how do you still go about deciding, okay, this is the next most important thing to build or to address with LightSpark.
I think initially it was really how do we get something that we feel like the exchanges and others that haven't integrated to Lightning, how do we get something that they can easily do that and they can start to see the value of Lightning?
A lot of them, when we had talked to them initially, we tried to find out why weren't they using Lightning or if they were, why had they backed away from it at some point? It was a very common refrain that it was just too complex.
So that was our first starting point, was just how do you simplify that, making this something that you can integrate with a Stripe-like interface, where Stripe always used to advertise integrating 100 lines of code or 10 lines of code or whatever it was. We wanted to do something very similar. It won't take long to integrate. You can add support. You can start to see some real usage.
And from there, we want to build real-world use cases on top of it. And I think that's where it becomes a much harder problem is trying to find exactly what those use cases will be that will really catch on.
I think for us, it's really been how do we make money move more easily and fluidly and bring use cases that customers have today that can be made better by a solution that works all the time and is extremely low cost. As an example, we recently launched Universal Money Addresses, or UMA.
For a bit of context, to step back just a moment, there are a lot of real-time domestic rails, things like UPI, PIX, or SPAY, that are instant bank rails within certain countries. So for those that I mentioned, it was like India, Brazil, Mexico, but those are largely disconnected from each other. So actually like our friends at NewBank describe it really well, UMA is a global PIX.
It allows you to send money instantly between anyone in the world at an extremely low cost on this open interoperable system. NUMA is really just an extension of LNURL, uses human readable addresses. So you'd have something like $kevinatrain.com and I could send to someone else using their human readable address. And you can send from any currency to any other currency.
I think that's something that is maybe a little bit harder for some folks that have been in the space for a long time to really understand that you need to bring in the traditional rails to integrate them directly with the new rails. Otherwise, it's hard to gain adoption.
So what we're trying to do is make it so that folks that are on existing banking providers, for example, they can connect and use Lightning transparently. For example, I could travel to Mexico, go to 7-Eleven to buy something. I could pay using my UMA address. They could receive using theirs. And I would pay in U.S. dollars, for example. They would receive money in Mexican pesos.
And Lightning and UMA just glues those things together, makes it so that you have this globally interoperable cheap open payments rails where anyone can send any currency they want, receive any currency they want. And Lightning and Bitcoin is just the transparent glue that kind of meshes those things together.
And I think building out solutions like that that bring real world use cases is pretty vital to actually gaining adoption. To this point, Bitcoin and a lot of cryptocurrencies in general have been generally held more for you buy and hope that they'll appreciate.
But we want to bring real world use cases because we don't think that's the only use case that can exist for Bitcoin and other cryptocurrencies. We think that there are a lot of great things that can actually happen with them and the technology is really strong.
So I'm curious, you said we a few times, and I'm curious about how you went about building your team. What do you look for in those people to indicate that they're the winning horses to join you?
It might sound kind of cliche, but actually our primary hiring criteria is just, are they good human beings? Are they people that are willing to work together, be super collaborative, and just want to build great products?
I think everyone has probably worked with people in the past that just want to prove they're the smartest person in the room and they want to win every argument just for the sake of winning an argument. And we're very much biased against those types of people. We want people that will get in the room, will whiteboard together, and then it's time to go build something quickly.
We don't want to spend two weeks arguing on something that'll take a week to build. Obviously, if we're wrong, we want to be able to revert and move quickly in the other direction. But we want to work collaboratively, be really open and transparent about what we're doing. And we also want people that are obviously extremely skilled at what they do, and they can be pretty flexible.
We are a startup, so there's going to be hot areas that come up and fires that come up where we need folks to jump in on things and pitch in. So we want people to be willing to jump across the stack and help each other out when the time comes.
Obviously, we try to keep our roadmap relatively consistent, but we're going to have things that will pop up and we'll change the roadmap and we need to be willing to kind of jump around and move to whatever we need to. We also try to be as lean as possible.
We typically only hire when we're feeling a little bit of pain and really have a very clear plan for where we're going to use people going forward. And one of my first jobs, I felt like I was bored all the time. And I just sat around reading the articles on the internet and going for walks in the office. And I always wished I had more work and I would beg people for work.
And that's a feeling I never want anyone to have. And no one should ever have that at a startup like we are. But I think we want people to be busy and enjoy what they're doing and be passionate about what they're working on. I think if people are doing things that they enjoy and find interesting, they're going to do better, work harder, and we want people to really enjoy what they're doing.
This message is sponsored by QA Wolf. If slow QA processes bottleneck your software engineering team and you're releasing slower because of it, you need a solution. You need QA Wolf. QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes.
With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Drada, Autotrader, and many more, you're in good hands. Ready to ship faster with fewer bugs? Join the Wolfpack at QAwolf.com to see if they can help you squash the QA bottleneck. This message is sponsored by SnapTrade.
Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This will be interesting. My next question around scalability, you know, given my understanding of crypto and I think my audience's understanding of crypto.
So I'm just going to I'm going to ask it kind of blindly and just hear what you have to say. Was this built to scale from from day one or is there are there areas where you've had to fight this as you've grown?
I think we definitely are chasing that a bit. I think every company should be chasing that a bit. You don't want to over-engineer things from the beginning so that they're infinitely scalable before you see some level of product market fit. I think it's always good to have a tiny bit of buffer where you can scale to some degree.
But if you built it such that it can scale infinitely from the beginning, you probably over-engineered it. At the same time, you don't want to have to redesign your entire system every time you add new customers. So there's definitely a delicate balance there. But you don't want to spend so much time building the perfect system that it's going to take you years to get anything out.
And by that point, you're so far behind that the world has passed you by. So I think that we are in a pretty decent position where we feel like we started out good. at a place where we could get some determination on whether there was product market fit. Once we found where that was, we are at a place where we can now start to continue to scale the system more and more.
I think we're still at that point where you don't want to make it absolutely perfect and infinitely scalable, but you want to make it to a point where you can scale to the level of customer that you anticipate, plus some amount of buffer. And I think we're in a pretty good position there.
So as you step out on the balcony, you look across all that you've built with LightSpark. What are you most proud of?
Honestly, I'm most proud of the team. We've built such an amazing, strong team that really coalesces around problems and can ship quickly. And they're just amazing people that really work well together. It's never an easy journey as a startup, but this team is truly world-class. And I think it makes my life easier.
It makes all of our lives easier when we have a group that we can just get in a room together and brainstorm things and feel like there's no judgment on dumb ideas because I've had many dumb ideas in my time and I'm sure I'll have many more.
And I think it's healthy to be able to brainstorm things together and just throw things out, have others be able to build on those things and build great solutions on top of that. So I think that is probably the thing I'm most proud of. If I'm looking at like the technical side, it's probably when Coinbase integrated with us.
I think that was really a great validation of what we've been working on. So typically Coinbase builds things in-house. So for us to be chosen as their partner for Lightning was really an honor and helped show that we were on the right track to bringing more users and more companies onto the Lightning space. Let's flip the script a little bit.
Tell me about a mistake you made and how you and your team responded to it.
So I think when we first launched, what I mentioned before, we were trying to make it simpler than anything else out there. But I think we quickly found we just didn't go far enough. And when we shared it with companies, they still felt overwhelmed by the complexities of Lightning.
And channels themselves, again, were such a foreign concept that we quickly had to step back and rethink what we were doing and figure out how we can abstract that complexity away even more. I think the team did an amazing job coming together to change the interface that we exposed to customers, to make it much simpler, to fully abstract all that complexity away,
And I think when we spoke with customers, we really found that they didn't want to know or necessarily be deep into the intricacies of things that could happen in Lightning. So we needed to quickly pivot and make sure that we were providing an experience that helped them get on board quickly and easily while still being secure and safe for them to use.
So it was really just amazing to see how quickly the team came together and were able to make such core changes so quickly.
This will be fun to ask and, you know, anything about the Coinbase integration and choice there and just your clear passion for the space. Tell me what the future looks like for LightSpark, the product, and for your team.
We're going to keep building what we feel are amazing experiences on top of Lightning. I think we've gotten the core foundation to a point where we feel pretty confident that we can onboard partners easily. They can transact and have a very successful Lightning operation. But now it's time to bring these more use cases that can actually build a broader user base.
There's only so much that you can do if you're only planning on doing Lightning payments and sets. I think that you want to be able to do things like we're doing with UMA, where you can abstract even the Bitcoin portion of it away. And you can just see it as a global payments rails where anyone can transact in any currency.
And do this on an open network where I could be in Africa and send money to someone in Brazil and have it instantly land in their account at negligible fees. I think to see some of the fees that are being charged today and that it can take you five, 10 days for it to settle in your account is completely insane in this day and age.
And I think, honestly, we don't know all the use cases that will be here. I think we want to engage really heavily with the community and try to figure out What use cases are going to be the things that will take off? So we're building a platform here that we hope that others will use and bring about these new use cases that we can't foresee ourselves.
And we're obviously going to try to help build out as many use cases as we can. But I think what we need to make sure that we do well is build this platform in a way that college student in the dorm room can build the next great company on top of it and do that really easily.
Let's switch to you, Kevin. Tell me who influences the way that you work. Name a person or many persons or something you look up to and why.
That's probably a boring answer that you get all the time, but honestly, my family. My parents, I think, demonstrated the value of hard work throughout my childhood. And I always want to make them proud and be the absolute best version of myself that I can be. I think additionally, I had a brother, Justin, who passed away from a brain tumor. He was the most brilliant person I have ever known.
Absolutely an incredible mind, so well-rounded. He was actually in a similar space in programming. He was actually the reason I came out to California so that I could live closer to him. And I hope to just honor him by being able to build a company that will
hopefully stand the test of time and do something that will actually help countless people with more easily moving money and being able to expand the things that they can do with their own money. And I think I want to build something that's like a little bit of a legacy that I'll look back on and be proud of and that hopefully he's looking down and is proud of as well.
Last question, Kevin. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world. And can we show it off to you right there on the plane? What advice do you give that person having gone down this road a bit?
I think it's going to be a long road, probably longer than you expect, but the journey is honestly worth it. Just embrace the people that you work with. I think building relationships can be just as valuable, if not more valuable than the tech beneath an idea.
And it'll make the journey a hundred times, thousand times better if you actually learn from those experiences of others and build those relationships. And at the same time, I think make sure that you keep a focus. It's so easy to have a million new ideas that come up and you want to chase them all at once and show that you can build all these amazing things.
But then it can get to the point where you're doing so many things that you don't do anything very well. And finding that right balance of making sure you're doing things right. really well and getting actual signal on whether they're going to work. Still also exploring the right number of new ideas. You don't want to just do one thing and then miss out on something else.
But you also don't want to do so many things. It's so broad that you're not doing anything well. So finding that right balance is not easy. I don't think there's an exact science behind that. And for me, it's been you have to trust your gut and go with what you think will work. But there is no exact science to it. And you have to really strike that balance well.
That's fantastic advice. Well, Kevin, thank you for being on the show today. And thank you for telling the creation story of LightSpark. Thank you. And this concludes another chapter of CodeStory. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review.
Both things help us out tremendously. And thanks again for listening.