 Anyway, so welcome. So I'm talking about an SMS application in Flask and Tulio to call farmers in Ethiopia and the DR. So I'm not primarily a web developer, so this is kind of for folks who would want to do something like this. And to realize it's really actually not too complicated, the application itself is pretty simple, but it does sort of what we need it to do. And also to give you an overview of some of the problems that are out there in the developing world that we're less familiar with here and how a lot of the tools that we already know can be used to solve really, really important problems. So the motivation for this was I mostly work on data and modeling weather indices. So using hierarchical Bayesian models to predict weather. And those weather indices are used for micro insurance. So you're probably all familiar with micro finance, but micro insurance is the small amounts of insurance that goes to farmers. And they're supposed to indemnify them when there's large catastrophic occurrences. So in a lot of places, in villages, people will ensure each other on the small idiosyncratic risk. My farm didn't do well today, so I borrow from my neighbor or my family member. But micro insurance is supposed to cover these large risks where everybody is hit at the same time. So that's sort of what a field. I've seen a lot of fields like this where there's just nothing. And you lose all of your capital that you've invested for the season. So the weather insurance that the models feed into, the weather indices feed into, this insurance indemnifies you based on a rainfall index. So it'll pay out if the rainfall falls below a certain amount, and it won't otherwise. And the purpose of this is that it kind of gets rid of moral hazard and adverse selection that you'd normally see in insurance, like if you think of health insurance. Well, actually, that's not a great example. But with traditional ag insurance, the problem is you'll get bad types buying the insurance. And also, farmers potentially destroying their crop so they get a payout. So the first type of thing is adverse selection. You get adverse types self-selecting in. And the moral hazard is that you can't monitor them. So weather insurance is supposed to solve both those things. But it's really hard to scale for two reasons. One is most of the sales are done door to door, as with anything in developing countries. And that takes a long time. And you can't find people because they're in fields like this. And you literally have to walk out and go find that person. And how do you do that with thousands of people? And then the other issue is satellite data. So most of the indices that we use to predict whether come from satellite data. And that satellite data is only as good as its own resolution. And so it's not going to be a very good input for predicting microclimates because it has a one kilometer by one kilometer resolution. So anything within that, you're not going to see any variation. So that leads to something called basis risk. Sometimes the insurance pays out when it shouldn't. And sometimes it doesn't pay out when it should. There's not a lot of predicted variation around the cut off. So that leads to needing more programmers in this area really because there's problems like these that are relative, not easy to solve, but need people to solve them. And most of the NGOs that work in this space have not a lot of technical capacity to solve these things. And SMS applications can be pretty helpful. They don't solve everything. Obviously, people need to be trained in what product they're being given. But there's a lot of pros. So the idea with this application was to basically collect information about rainfall to cross validate satellite data, but also to be able to allow farmers to sign up for insurance remotely. So it solves two things. It solves, to some extent, the data problem and the data validation problem. And it also solves the problem of not being able to scale that quickly when you have to go door to door. And I think it's not unique to this question that I'm discussing. It's a pretty common problem in any kind of service that you're providing in the developing world, whether it's in health, health information, any kind of information service. These are the two things that need to be solved. So the pros are that the SMS application will move travel time. It can help collect more crowdsourced data. A nice example of this is a company called Premise that does a lot of this crowdsourcing, where they get people to take pictures of stuff that they need information on. People send the pictures to them, and they use machine learning to basically learn what's in the pictures and aggregate the data. And the other nice thing about an SMS application, which ultimately would be the final goal, is that a lot of NGOs like some sort of gold standard like randomized control trial to test if something worked. So a randomized control trial is similar to an AB test. But they're very costly, and they're generally paper driven. And so with SMS, you can test a lot of things much more quickly. You can randomize how you change the question, randomize who's offered the SMS service, and test outcomes with that kind of application. The cons are that you're not training people directly. You're not facing them. Facing them, if you go door to door, you face them. And people have a sense of trust that you're not just spamming them. And the other thing is, say with insurance, you need it to be connected to mobile, some sort of mobile money. And a lot of people are not signed up for mobile money in developing worlds. Even though they'll have simple phones with SMS, the next step to get mobile money is just it's cumbersome. So there's already existing solutions out there for this type of application. I'm just listing three that I know fairly well. But so like Vota Mobile or Engaged Spark, these are organizations that provide basically customized web solutions where you can enter in a list of phone numbers and typing the questions that you want to be asked via SMS or voice. And then they have a lot of customizations around this. So then the question is, why reinvent the wheel? Well, doing it yourself is a lot cheaper. And it's relatively simple. When it comes to customization, it's not that simple. But for the purposes of what I needed, which is just basically send out a bunch of voice, collect the responses, and stick it into a database or CSV, the solution's pretty fast. Like you can do it on your own in a few months or less. So the issue of not using something that's customized is if you're going to use an aggregator like Tulio, they don't sell numbers in all countries. So in that case, then you need to use some sort of SMS gateway where you essentially buy a phone, you stick it in country, it's going to have some gateway on it, and you connect to that gateway, which then sends out all your calls. If the phone's off or something happens to it, then it's not going to work. It's risky. You can also use, say for instance, I first started testing this in Ethiopia, and you can't buy phone numbers in Ethiopia from Tulio. Because most phone numbers, to buy a phone number in Tulio, you need to register there. And you also have to have someone who is a citizen to vouch for you. So what I did was I bought a phone number in South Africa, and so all the calls come from South Africa. It's more costly, but that is a workaround. So yeah, and then the other thing is a lot of these other organizations that I listed, companies, they're going to have several agreements with different telcos in case the first number doesn't go through. And their last resort's going to be to call, like what I said, from an international number if it doesn't go through. The last thing is, like I said, I'm not a web developer. I don't know a ton about security. So after this gets rolled out, starting to test in in August, I need to hand it to somebody to make sure that the data that's being passed back and forth isn't compromised. And then lastly, if I want customization, that'll take some work. So in terms of pricing, this is an example of one company. You can see right away how much cheaper it is to do it yourself. So to get one of these ready-made solutions first you have to pay a monthly fee of about $300. Then you need to pay another fee for tech support. And then you need to pay another fee if you want them to help you with your survey. Comes out into the thousands per month. And then on top of that, you have to pay for all the phone calls you make, which they part of margin on. So Africa is particularly expensive. Nigeria, most of West Africa is pretty expensive. Asia is a little bit cheaper. But $0.30.35 per minute per call can get pretty expensive. So for this app, the tools that we used, I built this with another colleague of mine at Columbia. We used Flask, Tulio, Postgres, and it's all on a Heroku server. And the main packages that we used, Flask again, Tulio, Ginger, and our database isn't fully worked out. But when it is, PsyCOP and then requests to handle all the requests. And so the setup, I mean, it's a very lightweight application. I can just show you really quickly how few files there are. So I mean, most of the, as you know with Flask, most of the functionality is in the views. And it's pretty short. We don't have that many files. So we just have our views, our database, and requirements. What else are their big file, our config file? I mean, most of it is in views, and it's really not that long. And then you can see that the app itself, give it a second, is very lightweight. Like this is, we didn't build it to sell it. We built it to use it just for the farmers that we work with. So let me just go back to the presentation. We'll do a demo in a second. So really, all you need for your environment to work is a working phone number, which you can purchase on Twilio pretty easy within seconds. And your account IDs, and that's about it. So in case you're interested in doing this yourself, you'll find that there's a lot of competitors to Twilio. And the main competitors are like Tropo and Plivo. I didn't do a ton of research myself. Twilio is a little bit more expensive compared to some of their competitors. But from what I can tell, it's a bit more responsive in terms of their help. And if you want a complete list of all the competitors, Google 578 Telephony. There's somebody who created this enormous list of 578 competitors to Twilio and their pros and cons. But like I said, Plivo is one of their main competitors. Apparently, they have better voice quality and also have voice recognition. So you'll hear when we do a demo for Twilio, the voice is pretty crummy. The other thing, Twilio, I had trouble with is uploading my own voice messages and then to send the call. So right now what it's using is I just type in the question and it'll either, it can speak Spanish, it can speak French. I don't know what else. But for instance, it couldn't speak Amharic, which is the language in Ethiopia. So you'd need someone to speak the message and then upload it. And it wasn't, we tried multiple times and we couldn't get it to work, even with Twilio's help. So we have to go back and fix that. The nice thing about Twilio is they have full on tutorials where you can see previous web apps step by step and work off of that. So that's nice. Plivo doesn't have that as far as I know. And it's super easy to add IVR. So any voice calls because, I don't know if you can tell, but basically it records all, it records any digits. So if you say press one to, press one to buy insurance or press two if you don't want to buy insurance. If one, then tell me if it rained. And press two if it didn't rain. And so then you ping Twilio's API just to get those digits back. And it's nice to have this option instead of SMS, especially if you're dealing with really gnarly scripts like Amharic or Devangari for India. And also because a lot of these individuals are illiterate. So you can't count on them being able to read the SMS. And so it's a lot nicer to have the voice option. So then we put onto Heroku simply because it's really easy and it pushes automatic. Once you push to GitHub, it automatically deploys in Heroku. It's an option. You can set it off. So getting to the app itself, I'll go back to it. So we have three, four pages. We have a page for, it's pretty flexible. This doesn't have to just be used for insurance. All we do is you can type your initial message in. And then your message is for press one, press two. We'd have to build it out a little bit more to do more than that. But I was fooling around with the questions last night and testing it out and I had an error. And then I finally fixed it this morning. So I'm not going to play with it here because the questions that's in there is good. And then for users, pretty easy to add a user and then add your phone number and call or SMS. So right now it's set to the Dominican Republic. And in the DR, you can only send voice for whatever reason through Tulio. So that's another thing to consider is in some countries you can only send voice, in some countries you can only send SMS. So would anybody like to be the guinea pig for being called? I need your phone number. What's your phone number? 646-895-1561. What's your name? Gabriel. Gabriel. I'm going to just say you're from New York. Yeah. You and your rating? It should say press one for insurance. I can also do it to myself. Here, why don't we do this? I'll call myself and then you can hear. You can also then hear the voice quality, which is not that good. Oh, that's not right. Sorry, that's not audible. Right now, the question is, press one if awesome, press two is great. And that's it. So I had it on insurance before and it wasn't working for some reason. Anyways, I'm sorry you can't hear it, but I think it's pretty simple and clear what happens. And then the other thing you can do is just you can just get all of the calls that you've sent from Twilio. We have it here so that you can just download it as a CSB for anybody that we work with who wants to just get all the data, but we're still organizing it into tables for our Postgres database. That's it. Any questions? Oh, I'm at Columbia. I'm a researcher there. And so like I said, I do mostly data and both experimental design and these Bayesian hierarchical models for weather. And when we were working on the model, the Bayesian model, the biggest problem was the low resolution of the data. And we had no cross validation. And in some places, we have rain gauges. So we have two time series that we can use the correlation between them to get a better predictor. But rain gauges aren't everywhere. So this is why I thought of why don't we just ask people if it's raining or not? And that's how we started to do this. So I've only kind of alpha tested it with a few farmers and it works fine. The one thing is they have to know what it is all about. But so in August, we're going to start adding a few hundred farmers at a time and see how that works. But I mean, so far, so good. Yeah, through this front end, I can load up a list of cell phones and just use the scripts that send the phone numbers. But yeah, I need to work on that. We have 30 seconds. Ask another question. OK. Well, thanks.