Editor's Note: Thomas Bukowski is Lead Engineer at Watsi.
Watsi is on a mission to "turn passion, ramen, and code into a movement to provide healthcare to every person on the planet." Watsi has now raised over $3.5M to fund medical care for patients across the world. And it all started with a small Rails site on Heroku. We sat down with Thomas, Watsi's Lead Engineer to talk about how they built Watsi.org and how they're scaling their global crowdfunding platform. Hear about they built their payments infrastructure (and their plans for Bitcoin), re-engagement emails, analytics, and their plans to take Watsi beyond simple donations. Listen to the interview in full:
When we talk about scaling we have this hybrid human and technology component. The hardest part of scale for Watsi, I think, early on was actually just getting enough patients to come in.
Getting our medical partners to submit things. Grace was just writing each profile by herself and have her having enough time to write these profiles. So we started bringing on more volunteers and then after a little while we brought in a volunteer manager. We built this whole human system to do things that humans are really good at doing, which computers are really bad at doing, like writing.
People take that for granted. But when you actually have to build one of these things it's actually really hard. The fact that you can use PayPal and not really think about all the things that surround our commerce system, be it fraud or money laundering, any of the stuff like verification of people who are receiving the money, any of the interactions with the banks.
Any of that kind of stuff, it's like, "oh I just call this API and it sends money. If it needs more money in my account it just draws it from my bank account." It's all automatic if you think about it. That's just amazing. No one else has really put it all together.
There's a whole side to Watsi, the data side. We have all this very detailed costing for medical procedures ... This is the part of Watsi, we're like an insurance company. We have all these agreed on prices with hospitals. If you submit this treatment, we will pay you this much money for this treatment. These treatments we'll accept, these treatments we won't accept. In that way we're very much like an insurance system....
There's also things that we can collect. Really simple things like the approximate annual income of the patient. It doesn't have to be exact dollar amount but just in the same bucket is great, so we get an idea of this treatment that I just did is roughly 10% of the annual income or 1%. Or 400% of their annual income. What is the ratio here?
Yonas: Do you want to just introduce yourself real quick?
Thomas: Basically I run engineering at Watsi and we're a global crowdfunding platform for medical care. That's it. First non-profit funded by Y Combinator.
Yonas: One of the most interesting things, I think, about you guys is that you're a startup but you're addressing a problem that not many startups are trying to go after. Just briefly, what drew you to Watsi? When did you join and what was that like?
Thomas: Right. I joined Watsi about a year and a half ago and I think the thing that was drawing me to it was that it was doing something that a lot of startups are not. You can say all you want about the Silicon Valley bubble echo chamber, but there are a lot of startups that we hold up to be really successful. They're addressing problems that ... I use Uber every day, Uber is great, but that's really not that big of a problem compared to something like healthcare. I really wanted to do something a little more meaningful and more impactful. And see what that looks like.
I think the other thing ... I was also looking for something where technology had large leverage, because again a lot of the problems we've looked at, we've looked at so much from a technology lens that you can add more technology but you only get a little bit of impact out of that. As opposed to looking at the outside, more broader places where people are usually not using technology, to solve, to attack a problem you can get a lot more. So you get a lot of bang for your buck, essentially.
So it was very much an impact thing, but not just a save the world kind of impact thing but also a, "hey, I can do this coding thing. What kind of impact can I have on the world with this coding thing?"
Y: Right. That's interesting. What's your background?
T: I've been coding for a long time. I started coding when I was 10 or 11. It's hard to say ...I've done a bunch of different things. I've mostly been an engineer or a designer, in the tech world. I've done a bunch of things. I've worked at New Relic fairly early on, kind of as a half engineer, half designer. I've worked on Pivotal Tracker at Pivotal Labs. Tracker is an agile project management tool. I did a lot of work on the college newspaper when I was in college, and that was a pretty serious journalism thing. That was pretty interesting as well. A lot of exposure to that side of things.
Y: Very cool. Can you talk a little bit, briefly before we dive into the tech side, about some of the things that Watsi does in terms of ... I know you guys just had your two year anniversary, right? Can you talk just a little bit about, give people a sense of the scale?
T: Sure, yeah. We've funded about just over 3000 patients and raised about three, three and a half million dollars, roughly, for patients' healthcare, so far. On the one hand that's great. $3 million is a lot of money. 3000 people is a lot of people. But again, compared to the size of the problem it's like a drop in the bucket. Also, I think, from the technology perspective it's not a ton of data. 3000 rows in a database is not really that big. Our focus is a lot more about building out a donation platform, a best-in-class donation flow, on the site and really working that stuff out. A lot more of the quality of things, as opposed to, "oh, we have just huge data" kind of problems.
Y: Is that sort of how you guys see the problem? Is it from an experience perspective that you guys just want to make it easier and the entire mission is to focus on the experience, to lower the barriers for people?
T: For now we're focusing on experience. The bigger picture, our vision is to bring healthcare to people who don't have healthcare. The numbers are kind of crazy, but it's something like a billion people who don't have access to healthcare in any sense. That's a pretty big number. We hope to be able to address a percentage of that someday. A realistic percentage of that someday.
I would always say, for now we're definitely focusing a lot of the experience side of things, all these things that are maybe not classically hard in a technical sense. I think that the scaling problems will come. It's actually kind of nice that we don't have it now. We can tackle things one at a time.
Y: Speaking of scaling, do you have any insight into what that initial, initial version looked like? Of the actual site?
T: Yeah. I mostly came in to that code base and that site.
The interesting thing about us is that, like a lot of startups these days ... When we talk about scaling we have this hybrid human and technology component. The hardest part of scale for Watsi, I think, early on was actually just getting enough patients to come in. Getting our medical partners to submit things. Grace was just writing each profile by herself and have her having enough time to write these profiles. So we started bringing on more volunteers and then after a little while we brought in a volunteer manager. We built this whole human system to do things that humans are really good at doing, which computers are really bad at doing, like writing. We'll actually do a lot on the operations side, so tailor this balance between how much the computer is doing and how much the human is doing. Who is good at what and what we can really ... what are the tradeoffs there.
It's interesting because we're applying technology to scale all these human processes. It's kind of interesting how we can do all these little changes that make humans a lot more efficient. It's a totally different kind of scaling things that you normally talk about when you're talking about scaling in the technology side.
Y: Yeah, and actually I want to dive into the process aspect of this. It sounds like you guys had the classic marketplace issue. You need both sides of it. But just stepping back in terms of the actual site itself, what was that built in originally? What did that look like?
T: Right. So Jesse was the original technical co-founder of Watsi and he originally built it on Rails and MongoDB.
It was Rails out of the gate. Mongo ... That was the start of it. The Mongo to Postgres transition happened before I joined. I don't really know why we did that. Postgres works really great as well.
We were always on Heroku. It's an interesting thing that most people don't know about YC startups is that you get this whole bundle of free credits for all these things, often to previous YC startups. So we have $50,000 in Heroku credits and I think we've used about 10 or $15,000 of it. It's kind of like, "well, Heroku is free," and it turns out it's really great. So we're like, "let's keep doing that for a while." This is one of the scaling things that we'll need to tackle at some point, but for now we're golden.
Y: I remember, I was looking back at your guys launch initially on HN. The site crashed and I guess you guys weren't expecting a lot of traffic.
T: I think the site never technically went down. I don't think it was even slow, actually we just ran out of patients. So it kind of crashed, again, in the sense that you couldn't donate on the site anymore.
So it was just like, "oh, that was it." Chase has been waiting for the moment when it's something technical that goes down. He has this tweet ready which is, "I love the smell of dynos in the morning." Which is pretty good. Heroku’s been great. It's been great and there's no dev ops fortunately at all.
Y: Yeah, let's talk a little bit about what's going on now from an architecture perspective. So you guys are on Heroku, Rails, Postgres, what else is in the mix there?
T: We've used Redis for a bunch of stuff, mostly ... Sidekiq for the queuing and things, but also just storing a whole bunch of sort of temporary, or just simple counts and things like that in there. That's more or less it. We send a lot of email through Mailgun. Then there's kind of a whole other part where we integrate services like Customer IO and Segment and Mixpanel, things like that. We use that quite heavily, because obviously to optimize the experience and do a lot of the donor re-engagement we do for email, for example. We have a pretty sophisticated integration of these email marketing tools or analytics tools. I think more so than a lot of people. Further than other people go, actually.
Y: That's really interesting actually, because this is part of the core benefit, the main benefit of going to Watsi is that you guys are changing that experience. It's no longer about, you give some money, you walk away...
T: Who knows what happens. Exactly.
Y: You guys are actually saying, "no, we're actually going to keep you up to date every so often." So the re-engagement piece is a big piece of what you're doing, right?
T: Right. What we always say is, really what we're selling is this email that we send you, that's like, "hey, this is what happened to the $50 you gave to Bob or whoever."
Y: And what does that re-engagement look like? Once the actual operation or the thing that you funded actually happened, whether it's an operation or a follow up, whatever it is, then you guys send that initial follow up. But what happens after that? Is there anything after that? Or is that ...
T: The flow looks like we have ... The hospital submits a patient and then we put it on site. Once they've been submitted they are free to perform the procedure, so usually you don't want it to be something that's blocking medical care. There's a lot of stories, actually, mostly in the US where people have died waiting for insurance companies to okay the procedure.
So we don't want to build ourselves in a system where ... We obviously don't want to be a blocker on someone getting care. When a patient gets care the only other thing we have to do is ask the hospital to submit an update on it.
Often they will do it immediately after a surgery or they would do it on a follow up visit. But they're like, "okay, here's what happened, here's how the patient is now, here's a quote from them or their family." That is what we can distill down to, a few paragraphs and that's an update we send to the donors. That's the whole flow.
And that other part is you submit a patient, and then you submit the patient before care and submit an update after the care. Then as a donor you're like, "I donated to this patient and then I get an update." It would just complete the circle in a way on both sides. And that's it.
Y: For all of that stuff you're using Segment and you're using a bunch of services through Segment.
T: Right, exactly. Everything goes through Segment. Exactly, yeah.
We used to send newsletters through Campaign Monitor actually. Yeah but now we've moved everything over to Segment, or rather Customer IO. You get customers put into Custom IO and if this is your first time doing it there's a whole bunch of drip emails that come automatically out of that.
What else? We use at a lot of things. Segment, again. As part of their launch for their new SQL product, they gave us that thing for free. So we use that a little bit. That can integrate with a whole bunch of ... There's easily two dozen companies that build things on top of Redshift that let you visualize data. We use Periscope a lot, for example, which is essentially a dashboarding tool. It's a really, really well built dashboarding tool. We run all our numbers off of that.
Y: All your internal metrics and everything?
T: Exactly, yeah. Even housekeeping things like, have we accepted too many patients for what we can cover in liabilities? We have to cover it before it's fundraised. All these internal housekeeping and operational metrics. We look through Periscope because we can put out both our production database as well as our event stream. So we can do all the things. And there's a lot of balancing to do that naturally. That's the holy grail, being able to be like, okay, here's the record of the truth in our database but also here's the event stream, which often is a little less precise. Being able to combine those two together you get some really interesting things.
Y: Everything in one view. Cool. From an architecture perspective, you guys are just running a Rails app. Do you have services that are part of that or is it just one main core app and that's it?
T: We've mostly kept it pretty simple. I think we've tried to have it be one Rails app. We're not quite as complicated where we're getting too much of the monolithic Rails app problem right now. So let's just keep it super simple and keep it pretty straightforward knowing that, again, at some point we'll need to break out the whole medical partner operations. The part of the site that no one sees, that requires log in and so many patients, that kind of stuff. We might have to break that out to a different app.
We're kind of like, let's just keep it really simple for now and then see where we are. We're still at a very experimental stage even though we have the core model solidified; we're not really sure what we'll look like in a couple of years. I think we'll always have a site where you can go on and pick an individual patient and say "I want to donate to this person's care" and then get an update afterward. That will always be there.
But we've talked about a lot of different things. We've talked about things like a part philanthropic health insurance system, for example. The management for that will look totally different than what we're doing right now. So we just keep things simple for now and just knowing that we're going to start doing things that may require us to get a lot more inventive, in a way. So let's not go too crazy. It's interesting, we're trying to keep things simple.
Y: Just to close the loop on your architecture and tools, for the devops side of things there's not much right? Because you're on Heroku…GitHub.
T: Yeah, we store all our code on GitHub.
Y: Any continuous integration?
T: Yeah, we use Circle actually right now. We used to run to run Travis. I think Circle's parallelism won us over. Circle's been pretty good. It's not afraid to show you, the guts of what's going on. Which is great because it's a product for engineers. Sure, what's going on, let's go in and dig in, take this thing apart. So it's pretty good.
Back at Pivotal, at some point we had something like 200 or 300 Mac Minis on the books that were running all these project CI machines. That’s great because you could just go in and be like, "what's happening with this computer that's running my code?" But the management and and the operations on the IT team was just insane. You had Mac Minis dying, you were buying more Mac Minis. Do you really want multi million dollars of Mac Minis on your books? Is that really a sensible thing to do? So eventually that all moved to the cloud. I've gone through a lot of time thinking about CI and how that should be organized. Circle seems to be doing a pretty good job, I think.
What else? We look at the site through New Relic a bunch as well. We use Honeybadger right now. That's pretty good. Mostly we just want them to send us the email when there's an interesting looking error. Again, we're at the scale where we can just get emails and not have it be too overwhelming. We pipe all our logs through Papertrail, which is pretty good. That's more or less everything on the devops side.
Y: So are you piping that stuff into instant messaging or anything like that?
T: No. We haven't set up PagerDuty or anything like that. It's more just email driven, and that's been okay. We haven't had a hair-on-fire scenario where we're like, "oh, okay now we need to set up."
Y: Well I meant messaging in the office ...
T: Yeah. We use Flowdock for the whole company, and that's been pretty good. Chat's been around for a while obviously, but what's really nice about Flowdock is the newsfeed style thing that it has on the right side. So we have an engineering room and all the Papertrail, CI, GitHub, all the things go into that feed and we can have little discussion threads off of each of the things that come up. Just talk about errors, talk about whatever in that space. Actually it works out really well. That's one of the main things that's stopped us from saying we want to use something like Slack, which is just a little more polished. Maybe they have more of a newsfeed now, but when I looked at it a while ago it was more or less just chat. Update: this interview was conducted on January 26, 2015. Since then, Watsi has moved everything over to Slack.
Another thing we have in Flowdock is what we call the Money Room. Basically every charge whether it succeeds that goes through Watsi, comes up in the newsfeed.
Y: Just webhooks through Stripe…
T: Yeah, exactly. Webhooks through Stripe. The interesting thing is, we actually get a lot of credit card fraud.
We've tried really hard to make the donation experience really seamless and simple and easy to use. But that also makes a really seamless, simple, easy way to test whether a credit card is real. It works really well from a fraud testing perspective because you don't have to enter an address, there's no shipping. You can just be like, "does this thing take $5? Does it take $100? Can I still make charges through this card?" So we actually get a lot of credit card fraud through that, which is kind of a bummer. We need something that's real time enough that we can actually take a look at the stream of charges and be like, "oh, all of a sudden we're getting a whole bunch of declines." Or you're trying out a whole bunch of different cards, things like that. So we use that quite a bit to keep an eye on things.
Y: Flowdock.
T: Yeah, Flowdock and Stripe integration. We need to be able to see a stream of charges in more or less real time. That's what we ended up with right now.
Credit card fraud is interestingly still a large enough problem that there's so many ... We've talked to a lot of people who are like, "oh, you should use this or you should use that…" We've integrated with Sift Science a little bit. They'll build a data model for you, basically. That's great. We've stopped short of really putting a lot of things in because, a few things ... I think we're still at the size where a false positive, someone who's not actually fraudulent being marked as fraudulent, is a pretty big deal for us. Again, our volume is not quite so high that we can't do it manually still. We just go through the list of charges per day. Everyone has a day where it's their fraud day. That actually still works out pretty well.
Y: Are you saying that you tried some of those services and you ended up with a lot of false positives? Or are you just scared that you would get ...
T: I think we're more worried about it. I don't think any one of those services would come in and say, "oh, we'll never get a false positive." But I think it's so valuable, the heuristics, on the human side, and then we can put one of those things and we also would know exactly, these are the things that tend to be really useful for identifying fraud. These are things that we should put into Sift, as opposed to putting in everything under the sun. In terms of parameters that we send. That was another one of those things where we know at some point we have to tackle that for real. For now it's okay.
For now it's good and actually it's nice to see, oh this is a new donor that came in and just donated a bunch of money. There's definitely qualitative value in looking through your list of customers, your list of charges. It's done okay by itself but that's something we definitely need to work on, fraud. It will be for the rest of Watsi's life, that's for sure.
Y: Speaking of payments, do you want to talk a little bit about how you are doing the checkout flow? Are you using the Stripe stuff, Checkout.js?
T: For sure. We built our own payment flow instead of using Stripe's Checkout.js. We also had ours before they really had Checkout.js as well. Of course we could make things much easier if we just used Stripe's checkout, but I think it's just not quite the same level experience. It's like, "oh it's this other thing. What is this thing that pops up? I'm not sure."
Y: What does that flow look like? I'm ashamed to say I haven't actually used this...
T: No worries, yeah. Basically you click a patient and then you're like, "I want to donate $5, $10" whatever it is to that patient. Then what you get is a really simple form: name, email, and then your credit card information. That's all on the form then you click donate and that's it. Again, we keep it really, really simple, right?
We support Stripe and PayPal. There's two options that we support. We support PayPal mainly because there's a decent amount is international donations. People from outside the US. The credit card thing is just not as popular as it is in the US where you just type in these numbers and then you get charged on the Internet. In a way it's kind of a crazy concept. So we support Stripe and PayPal. It's a pretty stand e-commerce integration, nothing too crazy.
Y: I guess I was just curious, what are some of the things you guys like more about your custom flow… Is it just from a UI perspective?
T: It's mostly from a UI perspective. It's that we could make it one step. That's something that's definitely not great about PayPal. We get so much more abandons. People want to donate with PayPal and then they just kind of fall off somewhere on PayPal's side of the process. They're on this totally different site, and ...
Maybe there's a newer API that's more Stripe-y now. More Stripe-like.
Y: But it's still worth it for you guys to accept PayPal?
T: Yeah, for sure. We've talked about ditching PayPal a lot. But internationally it's still the best one.
Y: I was going to say, internationally you probably don't have a lot of options. People are used to it.
T: We actually use PayPal for a different thing as well. We're just starting to. There's two sides. We're getting all these donations, but we also need to send money to all these hospitals around the world. We're lucky, since we're a 501c3 we can only disperse funds to other 501c3s. It's like this protected umbrella of money in the IRS tax bracket. Every medical partner that we partner with has a 501c3 that they are associated with in the US. So we're not actually sending money internationally.
That's actually great because there's a whole ... Currency conversions, money laundering, protections of all sorts of crazy things. PayPal is very ... If you go really dig into PayPal's APIs it's all these crazy exceptions and all these things can and can't do. You can't, for example, Singapore does not allow crowdfunding. The government does not allow crowdfunding as a form of economic activity.
Y: Okay, so you can't put money into a pot and have that go somewhere.
T: Right. You can't do like a Kickstarter. You can't do Kickstarter in Singapore, for example. That's kind of crazy. Things like that are pretty complicated but luckily all our money is within the US. We're starting to integrate ... We had to dig around and find the right API in PayPal's giant bucket of APIs. We're going to integrate with their MassPay API that will automatically transfer money to medical partners, which is currently a manual process. Update: "We're back to integrating with Stripe now for these funds transfers to hospitals. The MassPay API was really old and would randomly fail some of the time."
Right now, Dan, he goes at the end of the month, "all right, which patients were fully funded that we have sent updates for?" So there's at least 15 for this partner, and you add up all the numbers and you go into to PayPal and type in $16,000... Hopefully I'm sending this to the right email address, kind of thing. He's only made mistakes a few times, but when you make mistakes it's like, "okay, I just sent $16,000 to the wrong person. Or I just missed a zero. Or I added an extra zero." The consequences for making a mistake are so high it's not a good idea to have a human do it, basically.
Y: Right, right.
T: Or have a lot more safeguards around it. This is something that we can definitely automate. Basically we're very close to finishing automating the funds transfer. Every time the partner submits an update for the patient, once we approve it we'll immediately schedule a PayPal transfer.
Y: As opposed to doing it at the end of the day and maybe ...
T: Yeah. We do it once a month.
Y: Oh sorry. Once a month, okay.
T: Exactly. The other good thing about this is that we hope it will incentivize the partners to submit updates. Because essentially you submit the update and an hour or two later you get money. There should be a carrot thing going on there, hopefully.
Y: Right. That's what should be happening.
T: That's something we're actually pretty excited about doing. It's a classic engineering thing though. It's like, grab this code, all these exceptions, all these edge cases, don't make any mistakes.
We've moved about $2 million through the manual system already, so this thing is going to power Watsi for the foreseeable future. It's one half of the marketplace.
Y: I know that Stripe, they do power some marketplaces and they do have escrow…
T: We actually looked through a lot of that stuff. The interesting thing about Stripe is that you can't add funds into Stripe from your bank account. So to transfer money out from your Stripe account to sellers or whoever's on your other side of the marketplace, you only do it with your Stripe balance which you can only fill by taking credit cards.
My suspicion is that's actually a money laundering thing. If you're able to pump money through Stripe to anyone else, from any bank account, then there's a whole set of money laundering laws and policies and preventions you need to put in. But since it's only through credit cards and debit cards right now, as far as I know, then that has a bunch of that stuff built in already. That's my suspicion, anyway. So that doesn't really work for us because about 60% of our donations come through Stripe. But that's not quite enough... Eventually we're going to overdraw the account because that's not quite enough money to be able to cover the transfers. So we ended up going with PayPal which let's you send money from anything to anything.
Update: "Stripe is making a special case for us to allow us to add funds from our bank account.".
Y: In terms of the break down, you said 60/40. Is that kind of the split between US and international?
T: No, I think international is probably closer to 20%.
There's definitely folks that just don't want to put in a credit card number, or they're used to PayPal. In the tech industry a lot of people are like, "PayPal is so annoying, or they froze my account." It's actually an amazing, a great system that we can do this thing where we just automate sending money to a whole bunch of people. And it just works. It's this very well built out system for moving money around. It's actually great.
Y: Yeah, people take that for granted.
T: People take that for granted. But when you actually have to build one of these things it's actually really hard. The fact that you can use PayPal and not really think about all the things that surround our commerce system, be it fraud or money laundering, any of the stuff like verification of people who are receiving the money, any of the interactions with the banks. Any of that kind of stuff, it's like, "oh I just call this API and it sends money. If it needs more money in my account it just draws it from my bank account." It's all automatic if you think about it. That's just amazing. No one else has really put it all together. There's lots of other bits of it like Stripe or Braintree or Dwolla. They have all these little parts of it, but PayPal has all of it in one thing and it just all works.
Y: But they don't have the not take you off to their website flow.
T: I think they have a credit card flow now that's not a ... That competes with Stripe but it's the paying with the PayPal account balance thing that still requires the ... It's interesting…
Y: Two more things regarding payments. One is, any intention of supporting Bitcoin?
T: Everyone keeps asking us about that. We're thinking about it.
Y: You could probably just do that through Stripe, right? Or PayPal.
T: Yeah, that's right. Exactly. We take Bitcoin for our operational accounts. We fundraise separately for the operations of Watsi, what pays our salaries, versus what we fundraise for patients. So we take Bitcoin on the operations side because that one is more like a standard non-profit donation where you give someone some money and who knows what happens.
We're thinking about doing Bitcoin on the patient side, for sure. There's a lot of things to figure out. We've dipped our toe in there (e.g. we were one of the launch non-profits for Stellar, which is that new, non-Bitcoin crypto currency thing). We're very much waiting and seeing on a lot of these things. We're pretty close to the Coinbase guys. We're there, but we haven't quite prioritized from an engineering perspective.
It's really a matter of getting around to it. Essentially we're a finance company, we're a fundraising platform. What we should be really good at doing is moving money around and all the verification around money being moved around, that you're fundraising money for the right person. Bitcoin is a real thing, it's not going to go anywhere, we're definitely watching it. That's something that's going to mature over the next 5, 10, 15 years. We'll be right there when it's the right point for us to do it.
Y: Yeah. You guys have the patients on one end and you have money on the other end. You're just sitting in between and you're just routing it, right?
T: Exactly. We're much more like a non-profit foundation that gives grants or in the startup world almost like a VC firm that we're analogous to rather than a hospital.
Y: Very cool. Anything else on the payments side?
T: We have a monthly donation product called the Universal Fund, but it's actually...that's a scheduled Sidekiq job that runs at 9:30am on the 1st. That kicks off and does a whole bunch of Stripe charges.
Y: And that's an auto subscription?
T: Exactly. I think it's close to 800 Stripe charges now. It takes it a while to run. It's amazing, we have a very consistent 10% decline rate on that one. It's cards expiring, or some amount of fraud, weirdly, it doesn't make any sense but there's some amount of fraud there as well. The email just is garbage and that doesn't make any sense. That's about 10%. It holds amazingly steadily. The entire past year it's been always 10%.
So that thing kicks off and assigns a job that goes through Stripe. Goes through a safe token on Stripe.
We've also added a lot of little features. Things like automated funds transfers to the medical partners. When we first started it was not a problem to just go in and make some PayPal transfers, not a big deal. But now that we're doing 100, 200, 300 patients a month that suddenly becomes a thing where you can totally make a mistake and it's really a big problem. So things like that is why it's also happening.
It's interesting, the phase we're in right now at Watsi… Lean Startup is these great set of principles where we essentially cobble these things together and see if the thing works. But then once the thing works then you have this massive cobbled together system where you can't even make it a more real thing. In this phase we're taking things that worked really well when we had 20 patients or 50 patients, and then make it work at scale. The automatic funds transfer is a great example because when you're doing 20 patients a month, you can go through 20 patients and say, "okay I'm pretty sure I got this right, I've got these numbers correct." But when it's 300 patients you're like, "I don't know, I hope I'm doing it right."
It's just too many individual items for a human to really be able to get correct. Right now what I think about a lot is this trade off between, humans are really great at doing these things but at some point their efficiency and their correctness start falling off a cliff. So, what can I really have computers take over? But not have it suck out the soul of what we're doing and the donor experience. The writing, for example, is still 100% manual.
Y: Is there anything else coming up either from an engineering perspective or just a company perspective that probably relates to engineering that you're just excited about doing in the coming months?
T: Yeah, for sure. What we're starting to do now is get a better grasp on the data that we have. The other side that we have is, for example, we've done hundreds of hydrocephalus treatments which is this fluid in the brain thing that can happen when you're born. It happens in the US too, but when the doctor sees it they just do surgery immediately and it's a 45 minute or an hour long surgery and, no problem, it's fixed. But in the developing world it's not as commonly known. Surgery is a real cost, whereas in the US you can just absorb as part of childbirth.
So we fund a lot of those kind of treatments on Watsi. There's two hospitals, for example, outside Nairobi that we fund hydrocephalus treatments at. At one hospital the hydrocephalus treatment is $550. The other one is $950. It's exactly the same procedure. And the hospitals are literally next to each other. They share a support staff, they share a cafeteria. That's really interesting. There's a whole side to Watsi, the data side. We have all this very detailed costing for medical procedures ... This is the part of Watsi, we're like an insurance company. We have all these agreed on prices with hospitals. If you submit this treatment, we will pay you this much money for this treatment. These treatments we'll accept, these treatments we won't accept. In that way we're very much like an insurance system.
There's a whole data part of it that's pretty interesting. We're really just starting out. Let's make sure we're collecting the right things, let's make sure we're collecting in a way where we can analyze and play around with it well. We're starting to get an idea of, what do we know about this arena that we're just dipping our toe in, in terms of developing world healthcare delivery, essentially.
Y: Right. So that's sort of the next phase. What can you actually do after you've built this platform where you're just sitting in between the patients and then the money, right?
T: Right, exactly.
Y: Interesting. That's really cool.
T: We're starting to think about that a lot. There's also things that we can collect. Really simple things like the approximate annual income of the patient. It doesn't have to be exact dollar amount but just in the same bucket is great, so we get an idea of this treatment that I just did is roughly 10% of the annual income or 1%. Or 400% of their annual income. What is the ratio here? So that's something that would be really interesting to know.
Not to mention a deep break down by ... There's a whole category of break down by medical related things, the procedure. There's a whole break down based on geography. There's all these different dimensions we can explore our data at. This is going to be really, really valuable at some point but we first need to get organized around that. Again, the thing was first built to be like, okay we need to put these patients on a site and they need to be funded, but now we realize we have this whole other side. The data is actually not structured for that kind of thinking. So we need to figure that out.
Y: Because then you could get really smart about saying, okay we know that this operation is 400% of their income. We need to prioritize this or ...
T: Exactly.
Y: That could probably be a whole ‘nother interview. How you guys do prioritization and which operations can you do and can't you do. It's a whole different set of problems.
T: That's a whole thing. Like I said, it's actually very much like an insurance company. Insurance companies think about this all the time, we collect this much money for premiums, and this procedure has this probability of occurring in the population in the group of people that we insure. How many of these can we reasonably do before we go bankrupt, essentially. We kind of have a similar ... It's easy to think that we're drawing from an infinite pool of money because it's charitable donations. But there's behaviors in terms of how much money people donate each year.
And it's a percentage of that that we're getting, so we can think about that and reasonably estimate how much we’ll grow. So we think about all that stuff. We're starting to realize that that's how we should think about it. As opposed to being like, "oh we just put donations on the site and people donate to them." It's starting to get more real in that way.
Y: That's interesting because that's the benefit of doing this through technology. You're building this core product, but as a byproduct of that, and because you're using technology, there's so many other things you can do once you actually reach that scale.
T: Exactly. That's the idea, anyway.
Y: Very cool. I guess we covered everything. This was awesome. I'm glad we got in so many different aspects. Anything else you wanted to mention?
T: I guess, as usual, we're looking for a designer, we're looking for engineers.
Y: Yes, yes. Designers, right?
T: Yup. If this sounds super interesting then give me a call.
Y: Awesome. Thanks a lot for taking the time.
T: Yeah, sure. Of course.
