 My name's John. I'm the VT of Engineering at the payoff of the STEM part of our day. And so we're here to talk a little bit about, so we're here to talk a little bit about what we've been up to for the last year and a half or so. We launched just in December. So we came from the internet company Roots, and we did that for a while and realized we wanted a lot more impact. We didn't set out to be a non-profit to help people get out of debt. We really wanted to do something that would have a lot of impact, help a lot of people. We did that with Ruby and Open Source. I'm here over here to talk a little bit. So we haven't heard about payoff, and that's not terribly surprising. So we started in 2009. Again, we're an internet company. We're trying to do personal finance management. So we kind of think of mint.com, but we did it with badges and kind of became a change. So we really wanted to help consumers get out of debt, number one. But we're trying to do it with positive reinforcement in game mechanics. So think of mint with achievements. So instead of killing 50 zombies and being a badge, if you made six payments on time, you'd get a badge. Or if you saved more money, they spent this month and you'd get a badge. So that was kind of payoff 1.0. But payoff 2.0 is kind of what we set out to build. That's the piece of build on top of what Ruby's got. So this is actually how we use it to kind of illustrate what payoff 2.0 is. So payoff 2.0 is credit card refinancing. So if you think about mortgage refinancing, mortgage is right. You have a better interest rate, so you can refinance it instead of paying an interesting tax. So what we're trying to say, why shouldn't credit cards be the same way? And actually, if you're trying to refinance just to save 100 basis points or 50 basis points, why shouldn't you try to refinance credit card and try to save several thousand basis points? And so Ashley is probably similar to many of you. She's in her late 20s. She's well educated. She's technologically savvy. And she's unfortunately built up $10,000 for credit card debt. And so one thing that we've learned is a really prevalent story. And it's something that people generally don't talk about. Studies have shown that people are more willing to talk about having cancer than about being in credit card debt. So that's how bizarre and taboo this topic is. But again, very, very prevalent as well. And so, you know, you just kind of think of the way that credit cards work today. You get your credit card. You're walking around campus. You're in college. And someone hands you a slice of pizza, maybe a t-shirt, and says, hey, Phil, it's your credit card location. And then off you go. Or you've got a credit now. You can spend money that you may not necessarily have. But if you think about the way that credit card pricing works, it's based on risk. So when you're 18 and you have no job, no college career, your app, it works as possible risk as possible to be at. And so you get this first credit card, you're paying 22-24% interest. And then Ashley here has been making payments on time. She's got 700 credit score. But she's not at the same risk that she was 10 years ago. But she's probably still paying that 22-24% UPR on their private credit card. We're saying that this doesn't make any sense. And so the payoff loan is essentially taking her minimum payment, $300. And if she kept paying that, after the card act, when you look at your credit card now, there's a little graph that says how long it will take to get out of debt. So it'll take her over 20 years to get out of debt. So 20% compounding interest month after month. She's accumulating approximately one 12th of that every single month. And so what we're saying is credit cards are alone. You borrow some money, you pay me back over time. And so you should be able to refinance it. And so a payoff loan is quite simple. It's just a simple amount. So she's got a fairly high credit score. So what we're saying is we want to refinance her to a 15% simple interest, 20% compounding, and how to pay it off in three years instead of 28 years. So we think about the life change for actually between age 28 and age 31 or age 28 and age 58. Nothing really happens in those years, right? So you don't do anything more or anything. So payoff tax core is a financial empowerment company. We really want to get people off this debt treadmill paying just enough each month to not accumulate more debt. And so that's what payoff is really about. So this ties really to our core. We're not a nonprofit. We believe that making a profit, being sustainable, helping the customers, and we're a venture backed company, so making a return for our investors are not mutually exclusive. We really believe that we can do all these things. And really there's no secret to it. It's just don't be greedy, but that's all it comes down to. And so talk a little about payoff 1.0. And so here's a screenshot. This was circa 2010 or so. So it's totally payoff-y. And the balloons used to animate and CSS animations. But this is the part that I want to start sharing with you. So it was half a million lines of code. It was definitely thousands in monolith category. We had 0% test coverage. So every time we could play, I used to keep a cool beer in the fridge for one of two reasons. Either it couldn't be a celebration that I survived, or I really needed it after I reached a deployment. It was two weeks into play, a simple feature. So if I just wanted to display one additional, let's say spending metric, I wanted to put a widget on there that said how much you spent on coffee. That would take me two weeks. But 10 engineers offered engineers. And so it was really, really, really painful. It would take our two QA analysts two full days to do a full regression of the site. So it was mostly manual and it was painful. So it was really painful. And so what we realized after we hired a couple more engineers, we were hiring pretty senior engineers at this point. But the gist for us was we couldn't keep doing this. We were insane. So we made a decision with myself, Stan, one other engineer, that we're going to rewrite this thing. But we kind of did it under the radar. We didn't tell anyone. So eight weeks of spare time, nights and weekends, we wrote a Rails proof concept. So Stan and I used Rails before, but never in the production environment. It was just always for a kind of hobby project. We were up and it was never anything to say. So over eight weeks, we wrote this 40,000 line, 70% test coverage, 80% feature complete from our initial prototype. So we did all the typical things you think of in a PFF, counting, displaying balances and all those things. But we went back and we did a very, very modern tech step. So Rails for work, Postgres, Angular, Redis, the way that we really wanted to do it. And so this was kind of foreshadowed. We didn't know what was going to happen next. And so we knew that we just needed something different and just to get our sanity back, really. And so it was really kind of a surprise when our CEO came to us about two months after we finished the prototype and said, hey guys, we're going to become a lender. And he said, wait, you work, we're an internet company. No one on the team has any experience lending or getting a dollar back. Which is a hard part by the way, because you can lend them any amount they want. Take back to their point too. And so we said, well, we're all a bunch of tech guys. We have a couple marketing guys. We have no one in finance at all. And so the foundation goal was to become a lender. We said, okay, we'll do it in a year. Yeah, that's a little aggressive. You already know the title of our talk. It's 16 months. That's how long it actually took us. But we didn't really know what we were getting ourselves into. So what kind of compliance aspects did we need? What kind of security did we need? We didn't even know that we were making one day. One, if there would be the correct decision, it was six days, six months later. And so we started digging into it. So we spent six months digging into it. This diagram up here, we call it the Sausage. If the diagram no one wants to know what goes into the Sausage. Really damn scary thing about this. This is the 50,000 foot view. This is not the detailed view. This is what it looks like when you zoom out. So on the left is when a lead comes in from the internet, and the right is a complete loan. And each of these boxes break into more scary diagrams that look like this one. So we really didn't know what we were getting into. But the thing, the one thing we did know was that this was definitely a marathon. It was certainly not strength. And so we knew that we had to do this in some sustainable way. Otherwise after we implemented it, we wouldn't have a team that we hadn't been able to. They'd all quit and we'd walk out. And then we'd really be closed. And so one of the things that we're really blessed with is that many times we'd actually sat down and thought about culture. So a lot of people will tell you, culture is something you can't create that's organic, which is true. But you need this nurturing environment for this to occur. And so we were really lucky because we actually sat down with companies before we decided to become lenders. So we started thinking, well, what's really important to me? So unlike a lot of other startups, we're not a bunch of 20-something sitting around in a garage pounding red bulls. We have families. We have kids, we have spouses. And so we realized that families are really at the core. And we knew that we were competing, we were located in Playa Vista up on the west side of LA. So we were competing at the time of my space. And Google, with Santa Monica and the whole Silicon Beach. And then in Irvine we were competing with another, yet another Google. And we were competing with Blizzard and a bunch of other shops. So we were competing for the talent. And again, we were pretty confident. So what were we going to do? So we realized that telecommuting was really important. A lot of people value telecommuting. They value flex time. We live in LA, so we all hated traffic. So we didn't want to sit in traffic. The idea of being in the office at 8.30 or 9.00 and sitting on the 4.00 or 5.00 for those who've been from LA, that just didn't appeal to us. So we knew no one doesn't matter. Just be here for a few hours and we're impressed on face-to-face time and collaborate. We knew we didn't want to create documentations. We'd all done Fortune 500 stints and created mass news and word documents that were obsolete as soon as we wrote them. So we knew conversations were really important. There's a really website. You can see all the couches. We actually have a two-to-one couch ratio. Sorry, two desks to one couch ratio in the office. So that's how important it is for us to sit and be able to talk to each other. We knew the work-and-play were related. So this is one of those things that is organic. It's craft beer Thursdays. Every Thursday we're on four or so. We crack open some craft beers and we have a beer trader who lives in the office. But it's our way of meeting management, meeting marketing, meeting the product, placing down people who don't interact with the week and just having something work to be able to chat. And then flat organization. Usually flat organization is just lip service which we really need and we'll talk a little bit about that on other slides. So Stan and I have read all these books and particularly reworked. Again, I mentioned earlier that we hired a lot of people from Fortune 500. And so re-work is one of the first books we hand them on starting day. We say you need to unlearn all of everything that you've learned from Fortune 500 and come to work with different attitudes. So for us, we really took a lot of these ideas from very formally known as 37 Signals from Etsy and from a bunch of other shops and kind of based a lot of our thinking on some of those kind of founding fathers of star culture. And I mentioned earlier about equal seats in the table. So the thing that I think is a common theme in a lot of other financial institutions is that they happen to have an IT department. And so IT becomes this organization in the company that just gets in the way. So I want to release this new product or I want to release this new marketing product or I want to do this, you know, whatever it is IT is in the way. So you guys haven't read Themich Project, that's an excellent book. Kind of getting the perspective of how IT is perceived in a lot of these other organizations. And so we brought a couple of other people to the table as well. So Science, so we have the chief scientist from the Harmony who works and leads our Science 15. So, you know, we have a lot of thought leaders in finance working for us. Basically people we brought in from the financial industry which had constraints and some of the complexities and compliance issues were willing to leave some of that, those opinions, and that's the way we always did it at the door. And basically we learned. So we really do have a lot of grounding in terms of all voices matter and that diversity and thought is something that we really, really value. So what that adds up to is pay off is trying to restore humanity to finance. And so one of the challenges to hiring is, I'll give you an example. So you're going to hire.com. So hire.com categorizes companies by industry. And so one of the things we always get is I don't want to be part of the finance industry. And my response is always give me 10 minutes. I swear I don't want to be in the financial industry either. But here's how we're different. And so, you know, greed is just something that just is at the core of a lot of these companies. That's something that just really, really bothers us. And then a lot of these companies are built on mainframe technologies. And so when you have these types of companies, yeah, you're going to get people that are, I shouldn't even tell you this before. So have you ever called into your bank and the agent says, you know, please wait while my system blows up your record? What the hell is that? Why am I waiting in this day and age for a record to load up? And the agent wants to tell me, I'm sorry, my system seems to be having a case on Mondays. I don't like that. I just want to reset my password for the website. Why is it so difficult? And so I really feel that technology, just humanity, even needs to be restored to the industry. And that's the kind of thing that we're discussing. This is probably the exact, if you stayed behind for Shopify talk, this is probably the exact advice that they just gave you. And so for us, it really means we need to survive in order to hit scale. So average transaction size for us is $15,000. This isn't an eyeball business. A standard eyeball came from eyeball businesses. We used to, you know, work on a water trend where, you know, lots and lots of eyeballs might form banner ad impressions, but this is a completely different business for us. And so we figured, oh, Rails is good enough for Cookpad. It's going to be good enough for us because in terms of pure eyeball, we're really not going to get to that point. So for us, modularity for agility is something really, really important to us. The assumption here is that we're going to throw away all these pieces as we learned. And so we need just enough learning to get off the ground, to be compliant, to be secure. But along these pieces, over time, we knew we were going to replace. So the emphasis for us was really building lots and lots of really small things. And that's what was really important to us. So test coverage is an obvious must. In order for us to switch out these pieces kind of up in the air. So if you imagine doing risky things like changing out how you decision a loan application, how you decide who you lend money to, some of these things have thousands and thousands of test cases. And so we put a lot of emphasis into test coverage. And if we have time at the end of it, we'll dive into tech stack and everything and answer any questions we have about that too. MPIs and microservices are really, really important to us. We run our own gem servers. Almost everything that we have is a packaged gem for ourselves too. In order for us to switch these things out and then we'll talk a little bit more about reducing meantime and recovering the gems are also a big part of that for us in order to be able to switch out the version of things. And then vendors will dive into an entire section on but the key thing there is we rat every single vendor and innovation we have and then pull the abstractions out of it. So there's usually more than one vendor for each of the things that we do. So we pulled out the business abstractions for it add an account and remove an account things like that and actually insulate it ourselves for those better integrations that's something that's really, really important I think for almost anyone dealing in a mature industry. And then speed of iteration is one of the most important things. So we took a lot of notes from Etsy. And so Etsy, yeah, is not part of the Rails community but they have a lot of ideas that are really, really important. I think the main thing being automating almost everything they have so in terms of deployments, testing, IT automation to use Chef to build our servers deployments we use we use Capistron and we're using Mininel and testing we're using Capembar, R-SPEC, Selenium and we're also evaluating robot which is a Python testing framework. Feature Flags is something that we've been learning but we've gotten some good success on. So Feature Flags is basically just a switch or some code. And so let's do separate deployments from launch. So that's really key. So when your code hits production that's not when you have to pay attention. You actually switch it so that you turn on the feature when your engineers are in the house or when everyone you need is around. And so it's just something that we've been trying to espouse and that obviously also goes with deploying smaller bits of code. So if you push code out to production and do what's called dark deployments we get a lot more confidence. So all these things are basically just trying to maximize the amount of confidence because again we're coming into a very highly regulated very high risk and high cost for screw ups. So if you screw up you lend to the wrong person that can really bite you in the butt. And then monitoring is obviously something that you need as well. So you need to go see how things are reacting when you turn on a feature play. Or even if you screw up. And then lastly again compliance. So there's some pieces that you can move really really fast on and just like Shopify and just like Etsy there's pieces that are PCI compliance or SOC2 compliance that you really need to carve out a little bit slower pace in order for you to keep your compliance and keep the regulators happy. So with that in my hand we'll be over to Stan in a few minutes. Good afternoon everyone. I'm pretty excited to be here. As we mentioned we only started doing Ruby two years ago I never thought we'd be speaking to you guys already. We started out so we started out with a team of really experienced developers. We're all coming from corporate backgrounds with Java and C sharp experience. But we knew from the proof of concept that we could pick up new languages and Rails in particular was pretty easy. So it was kind of nice that we found something that we could leverage and kind of give us the ability to achieve a really complicated goal yet in a short time frame like the year that we had. So I'm going to talk a little bit about what was really useful for us. Number one thing is the Ruby community. And like I said, it came from Java. So as far as kind of set low it was kind of the dominant force over there. They're not really that open and welcoming but we were able from day one to really find like detailed blog posts or screencasts whenever we ran into a problem just cool things. And the technologies that we chose also had people who were very willing to share information about them. So things like Venice and Lassie search. If we ran into a problem we were able to kind of fire off an email to you like the people who wrote the gems. And that was a little surprising because normally when you're dealing with a vendor you want to get something fixed or you have a question about like how does this work, how do we configure it. They're not going to get back to you in less than an hour. We would actually go right to kind of famous rubies or people who wrote like a keyless gem for us and they would actually respond to this. And so I really encourage you guys if you run into any things you're very willing to share your knowledge within this company. And of course one of our favorites is Railscasts. I think we actually had this running joke for a while where we would implement something and run into problems and like oh man that's kind of complicated. It took me a while to figure out. I'm like you know I bet there was some Railscasts on that. And then we actually searched Railscasts and we're like oh man we shouldn't have wasted an hour and we could have just learned it right there. Another great one for us was Ruby Rose and that podcast kind of really introduced us to a lot of different tools in the community and people. What we should be reading. So that was a really good one. I'm not sure if you guys have listened to the podcast but we are actually the same pay off. I almost killed one one. I feel glad about that still. Let's see. Well it's hard for us. So I think a lot of you guys, or maybe some of you guys are starting out and learning Ruby so hopefully you can kind of share the things that are hard for us and I'll help you out. When you're learning a language it's a lot more than just a syntax. For us there's kind of like a whole ecosystem that you have to learn. There's tooling, kind of best practices. So for us we haven't kind of done it yet. We'll request for kind of you know a little bit more for us. It's a little while to get our heads wrapped around but we're keeping it to that manner. We also get more from kind of the x-menu type of testing to PDD with RSpec and it takes a little while to do that as well. In the beginning we have a lot of code that was syntactically correct and from Java world you have kind of a static compilation and it would tell you okay it compiles but that doesn't really tell you that everything is working which with Ruby there's more of a duct typing kind of dynamic and it took us quite a long time to kind of like change our mindset in order to write code that looked less like Java. That was still syntactically correct Ruby but more you know to switch into like idiomatic Ruby and we think the best way to do that is kind of just to read a lot of code. Yeah, Eloquent Ruby is I think usually we throw them in have a new engineer write some code and then Ruby is usually on the required reading list pretty close to them starting to write Ruby and that's I think that's when everyone realizes oh my code looks like Java still. Yeah, we start people out with kind of just a whole two weeks of hey learn some stuff about you know what you're working on, read these things and learn about the culture so that's really big for us. So I'm sure you guys are aware that you know hiring is very difficult these days and with Ruby it's actually even more difficult than we have because there's a smaller pool at least within Orange County most everybody is doing like C-Shard or Java and surprisingly when you tell them hey there's this cool language Ruby, you guys can switch to it and a lot of people were not that interested in kind of learning something totally new so we're happy that the client is willing to embrace learning and have that agility to switch There's also a very interesting study that the Harvard Business Review had about women and they were not willing to kind of apply for jobs but they didn't feel like they already knew all the skills and we actually learned from that so we started rewriting kind of our job listings but actually you say hey you know come here and learn on the job you know you don't need to know every little bit as long as you're willing to learn. So another thing growing pains we started out with four engineers and kind of a small startup company and a lot of Rails literature is talking about what DHH was talking about where it's kind of a monolithic application and as you grow bigger there's communication overhead you have to start splitting things apart so you have to kind of take a critical view of which pieces of advice apply to a system as you grow between business. Alright so let's talk a little bit more about hiring. We like to lead nice people that's one of the things that we try to hire for but it's not really critical in a business environment shouldn't you be hiring for x years of experience instead or someone who's really experienced with the finance industry. Well we don't think so because we think culture is kind of the most important thing you have to have this environment where people enjoy working in order to be successful like if we didn't have pain to go out there and work would we still enjoy being with these people building kind of the same things we're building? So that's a question we ask ourselves a lot. And for my experience and this may not be everywhere it's definitely possible to learn Ruby and you can definitely look into the domain and kind of pick up how that works and all that but I've never seen someone who is on a power trip or really rude or condescending change their ways so we found that that was kind of a it's not scientific but it's pretty much a reason to choose nice over those other things when you're hiring and we have a good question that we ask ourselves when we're hiring or interviewing somebody it's stuck on a plane question if we call it so if I was stuck on a plane with you for the next 3 hours well I still want to work with you you know can I hang out with this person afterward and relax you know is it kind of draining instead to be stuck talking to that person and I think that's a really good witness test so why are we talking about these things as if they would be really exclusive you know there are people who are nice competent and have domain knowledge but in our experience especially down in Orange County it's really kind of a confused thing it's like the category of hiring as I like to call it you kind of have these 3 sliders and you have to choose which things to optimize for so we always go for competent and nice so this is kind of what we ended up with it's who we are as you can see we're a very diverse group this is actually really important it's kind of surprising there was a study recently that showed that if you have a diverse team it would actually outperform a more capable and experienced team that had less diversity so we felt like diversity is another thing that we should look for and what we built I think is a really diverse team of really capable people so what we needed to we let them learn the domain knowledge of the finance industry and we really didn't feel like we had to make compromises to get this so what do we look for when we hire provable competence you gotta have somebody here is able to learn reason about code there's a certain kind of thinking that needs to be there logical kind of reasoning we mentioned learning agility you know use a different language we're able to kind of twist our minds around new things and apply themselves and learn Ruby that's fantastic so polyglots are great and I mentioned nice already what you'll notice that we don't have up here are the traditional deal breakers say X years of Rails experience or you must be some sort of expert in the finance industry we think those are kind of negotiable things kind of optional and we're hiring so brings us up to the vendors can't keep up so we're in the financial industry but we kind of have really internet company kind of roots and you'll see this like Airbnb like Uber saying they're in these industries that are kind of entrenched like established industries but they're not really from the industries they have a very different DNA and we kind of feel the same way we're in the finance industry but we're not really of that but the vendors as it turns out kind of are they're very successful because they're kind of over the last generation and because of that they're a little bit slower than a new company they're not as hungry they're basically doing what worked for them in the past things nowadays are a lot faster and like you can't really make mistakes either because you know if you have a problem and the customer doesn't get a fix they're going to start tweeting about it and that's only if you're lucky the worst thing is like if you're a trending topic on say Reddit right they're really screwed so initially we were really really scared about building the hard pieces things like underwriting and low management so we didn't have the domain experience and we figured these vendors they've been here for decades they must know what they're doing but as it turns out it's kind of more perception than reality so they have this image of the ability of all kind of just like a giant rocky building but behind the scenes they have a lot of different silos within the company so maybe like the ops team doesn't talk to their dev team we've had you know, businesses like great, what's it going on? oh we don't know, you know talk to our ops team we'll get back to you in like 48 hours and like wow, that's kind of really acceptable and we learned pretty quickly that we should take in house all those things so we don't have to rely on slow vendors so here's an example of something that we took in house it's the credit policy which is how we improve loans it's a piece that has a lot of high risk if you make an error it would have a huge cost associated basically every loan application goes through the system goes through this process and we also change it a lot as we learn new things we make improvements to the credit policy just by in-house we reduce the turnaround time for a change from two weeks down to two days and that's just about speed too because testability was vastly improved when we in-house it we're getting better confidence that way we also found that SLAs are not very useful so the best guarantee to you know the best guarantee you can have really is being able to fix a problem meantime, recovery is the thing we really focus on so with an SLA you're kind of your hands are tied if there's a problem you're maybe able to diagnose it but there's nothing you can do to actually push a fix out there and you're just basically burning teams time effort on a problem that you can't solve yourself and that's a huge problem surprisingly vendors are not that adverse to eating the cost of this it's great for them because they don't have to worry about things but for us, the small startup we killed you and this is a really good business as well we found there's some vendors out there that actually don't have a test environment and you should really be aware if they don't have a test environment so I just want to give them a chart visualizing kind of the timeline and gains that we got from in-house and things we found this to be true within our industry but we suspect it's also true so if you're in a startup you're probably trying to disrupt one of these industries and we really encourage you to go out there and believe yourself and just have a lot of faith in yourself so I'm going to hand this back to John now we have six, it's a rounding error I'm sorry I mentioned earlier we're not a bunch of programmers we're people with families our engineering team is actually a quarter female and so a lot of working moms and so for us you know not having a life, we're not seeing our kids or not being able to do the things that we do you know there's a lot of people there's multiple people coaching you know kids teams and there's multiple people who have passions almost everyone I think has a passion outside of just their job and so for us that really meant a lot of you know not trading off things that we felt really important and again a couple of those intangible things that's much harder to describe to a candidate to interview and so how did we do this you know it was one thing just to say yeah family time is important but that sounds pretty cut in your eye and it seems somewhat obvious to say out loud but I will say that Ruby really enabled us to do this being able to leverage a lot of open source the language itself obvious if you, in the example I always use how many lines in a C sharp does it take to open up a file read some lines and then output another file and then how many lines does that take in Ruby and so you take that and you multiply over and over and over again you add test training kind of eat those into it and how many times that saved your bacon and then you add in just all the kind of defaults that are just smart defaults out of the gems in the Rails communities whereas with you know a lot of the other frameworks you can do whatever you want and you don't really have guidance for that and it takes a lot more time to train as well so there's generally a set established way of doing something at least for the 12 months or so before the new version of Ruby sector 24 months until the new version of Rails comes out and then automation again it's just something that's just really really baked into the organization that you know this is how 20 engineers act like 80 engineers is doing a lot of this automation and the other thing I didn't talk much about is high fidelity prototyping tools so we use these prototyping tools to hand off from a product team to our engineering team so rather than having nonsense word documents or winky documents or whatever we do a lot of prototyping that we can use to do user testing in front of actual customers and then also to communicate ideas between product and engineering as well so fire drills so getting a phone call and having a walk away from the dinner table or having your Saturday interrupted or having to carry your laptop in your car all the time we think it's just kind of ridiculous and so even before you know the speed science talk this morning Friday deployments has always been a rule of pay off not because we can't deploy on our Friday we can, we just enjoy our weekends and we enjoy our Friday nights and so again feature flags is really really important for us you know if DevOps finds an issue or someone is on call turn off the flag and go back to sleep do not wake up the entire engineering team at 2am on a Saturday night just doesn't make any sense anymore maybe it made sense in 2004 this certainly doesn't make any sense today and so this is where we're at today so we launched in December it took us 16 months to launch it 20 total employees to 80 something employees today so the rest of the company was pretty busy with engineering, was building some of these pieces out Stan talked a little bit about the growing pains one, the other things we didn't touch on too much is when it's 20 people and you know every single person's name to 80 people that's just a lot more relationships to groom so you think of people in your company as network nodes and the number of connections between 20 nodes and the number of connections between 80 nodes how that goes up exponentially and so for us this balance between life and work is totally achievable and that's really what we're here to sell we're not here to sell you the payoff loan if it fits for you great but what we're saying is that start-up life has become something that is parodied on the TV show now and so for us we really think that there is a sustainable way that would be nice too we work for a start-up and these things that you usually think that hey does the company need to be ruthless to survive as a start-up there's all these stories of these start-up founders that are just ruthless and execute at all costs and we say we don't think it needs to be that way we think that you can have the family and we think that there's the tools and the community and among others to have a start-up that does good that you can use technology to help people and that's not mutually exclusive profitability or even making a return for your investors and those things aren't evil either they all need to be kind of working together and that's really what we're trying to sell here is that it doesn't need to be that way this community has the tools in order to do that it's a quick recap culture is something that you have to think of on day one scale come later you can retrofit scale with the cloud and with all the things that you have available today it's a much different environment from the last time when I attended Rails 2.9 so you can retrofit scale now and really you should be building these things so you can swap it out and so agility matters way more I don't mean agile scrawl or combat agile is the true sense of hey your founder might come in one day and say you need to become a vendor you know shit kind of different for us we didn't have a choice we had to teach people really so without something that was really really important that we were able to train people make people successful and get them through that transition we hired the right people and it also changed how we hired people nice matters a lot and so instead of having egotistical arguments in the office about I'm right my algorithm is better the type of discussions that we have heated discussions oftentimes is that what is best for the customer and those are the discussions that are most important and you have those thinking over those things about how do you help your customers instead of I'm right and you're wrong and my idea is better than your idea or this technology is better than this technology and the corollary there is that if you have a right team and you're using the right stack have more faith in yourself that's something that we didn't have from day one we're really really scared and you're unknown and so we have this over reliance on vendors and we just burned a lot of time and as Stan said we spent a lot of time fixing their problems and finally you can have a life so work with nice people and take away so we hope that the things I said I feel are common sense if I say them out loud you all kind of nod you should work with nice people that probably makes sense but for some reason every job that I've had that just isn't true there's someone that backs that out to get me or they're asking me to trade my family time or to make these trade-offs and we just don't get it we can take I think a little bit of time we have two minutes for questions happy to answer any questions about stack technology and stuff too yeah cool bit of detail on your vendor is pretty interesting that goes against a lot of this new year from a lot of especially started people and I actually do payments in the Evo so I know a lot of what we're talking about we have payments vendors that don't have testing environments but sometimes not using vendors pretty hard because when you have to have a deal with an exciting chain so can you give me specific examples or you know spin that out a little bit I'm going to take that I already not mention specific examples but I'll give you some cases the main challenge is really getting your head around the domain knowledge and you would have had if you went and so for us I think we're fortunate enough to be able to attract a lot of people that understood the black boxes maybe not the rules internal to the black boxes which we may not want to use anyways because a lot of the systems at least in finance are mainframe systems we can dig down into or their giant oral pole 10 systems and so for us understanding the interfaces on the outside of the black boxes was the most important piece and so I don't know if there's a secret sauce to that I think it's just doing a lot of research and finding a lot of industry people that are willing to talk about those systems I don't think we traded out to a technology I think they're kind of being trench and sass what they call themselves sass but for them cloud is a new fangle for a lot of these for example we were working with a bank and the bank gave us a 40 page security questionnaire and inside the security questionnaire there's a mention of the word cloud once 40 pages, no sass, no cloud it was talking about where, if I had to find a customer's record point to me the exact server at the exact time where this record is we were trying to explain to them we used platform as a service so it could be on this node and if performance gets bottomed on this server then this virtual machine can move to this server we had to explain all these things to them and so I don't know if there is a secret sauce to it but for a lot of these vendors we did a lot of due diligence and we really just had to trust ourselves at some point that we could develop this in a dirty fashion that as we learned, adapted that's really the only secret sauce so it came back to agility we went out there knowing that we didn't know a lot of these but the main pieces we dug up first were the pieces in the scare of Jesus which usually had something to do with the money I was interested then did you develop your own credit model or did you acquire it we did but the thing that I think is key is that we had people that had done it before so the first approach we went out with was something that was comparable to everyone else and then we started iterating there so a lot of the things that we implemented we implemented in such a way that we could compare to other comparables to make sure that we were benchmarking the money benchmarking the financial we showed that our financial products were forming in a way that we would expect and then we iterated from there so we used McCall we used InVision there was a few more if you send me email at John and Payoff I'll be happy to send you back any questions thank you very much