How Perry Zheng leveraged his experience from working at Amazon, Twitter and Lyft to kickstart a successful SaaS company in the real estate space

Victor [00:13]: Hey everyone, welcome back. Today’s guest is Perry Zheng, an ex Amazon, Twitter and Lyft engineer and founder of cashflow portal. In this episode, he will share with us his journey of building software for real estate, syndicators, leveraging everything that he’s learned working at these unicorns before. Perry, welcome to the show.

Perry [00:34]: Thank you. Thank you for having me. Happy to be here.

Victor [00:37]: Awesome. Why don’t you tell our audience a little bit of your background? How did you get to these very big hubs of very successful companies? How did you start your own business?

Perry [00:50]: I was trained foremost, as a software engineer, graduated in 2010. Worked out a few companies, starting with the biggest and then kind of worked my way down to, you know, first Amazon then Twitter, then Lyft, they get smaller and smaller. Now I am the founder and CEO of cashflow portal, which is a year and a half old startup focused on real estate syndication software.

Victor [01:14]: You have news to share, essentially, since we last spoke, you raised money. Is that correct?

Perry [01:19]: Yes, we did. Yeah, we did. We raised about 3.5. It’s pretty incredible. We raised it in like less than a week.

Victor [01:27]: Not sure what was on the pitch deck, it must have been something very good. So what is cash flow portal?

Perry [01:36]: So cash flow portal is a real estate syndication software that helps real estate sponsors, raise equity, streamline their operations, and just reach more investors. Now, going back to the last question, the reason we were able to raise quite a bit of money in short amount of time, is that I had a experience as a real estate sponsor myself. I have been a real estate investor, almost as a side gig while I was working as a software engineer and engineer manager in this tech companies. For example, our first deal, we raised $4.3 million for a real estate project, a 172 unit in Dallas, Texas. That one is 4.3 million from 70 investors. So that means 70, Docusign I need to send out. 70 signatures, I need to review, counter sign and send them back. I checked the bank account every day to make sure the wire has been received and sent out another email, acknowledging the wire receipt.

It is quite cumbersome and tedious. That’s why I built the software to streamline that process. But because I have been a successful sponsor, people know I have a good track record in it just fiduciary duty.

Victor [02:59]: Awesome. So 73 investors, is that about normal? Is that about average with these deals go? Or is there significantly more or less? What’s the distribution here?

Perry [03:08]: Good question. That is pretty normal. In order to do syndication, it’s good idea that you get more than 60 units. Now usually syndications are between 100, 250 Plus units. That’s usually about a $5 Million raise. If each person invest 50,000, that’s 100 investors. Plus or minus 20.

Victor [03:34]: I can’t imagine how that’s managing a lot of people a lot of deal flow, to get this stuff done. They said that you were you were essentially using a zoo of tools and manual work. Being a software engineer, it probably didn’t take long for you to figure out I could build a tool here. So essentially, that’s what you did first for yourself, right?

Perry [03:56]: Yeah, that’s right. One interesting thing I noticed was all the software’s back then were extraordinarily expensive, because it’s business to business. Second, they usually came from established real estate sponsors that want to get into the real estate business, wanting to get into the SAS business. My background is almost the opposite. I came from a software world, I know how software gets built. I know that in Silicon Valley, and you know, this West Coast, we just build software better and differently. Then I got into real estate investing. I came from it from a different angle, and foremost, a engineer by training.

Victor [04:38]: So after you’ve built this more or less for yourself to just manage your deal flow to improve it to get rid of all the hassle. How did you realize, well, this could be a business?

Perry [04:52]: So a couple things. I was a engineering manage at a time. I was basically working three jobs. I was moonlighting at night. I actually did not code. I decided that I will not write a single line of code. So I built a team of software engineers to build the initial prototype. I use it for my own deal. That went very successful. But that’s a year to a year and a half in the making, right? So a year to a year and a half is the most painful part where we have almost zero customers. We just kept building, we focus on product design and engineering. And we build it in a pretty scalable engineering way. In a way, I was building the software with the focus that this is going to be adopted by other customers.

Victor [05:40 ]: Take a step back being a software developer, you were a manager, then but generally, you’re an engineer, when did you decide, okay, I’m not going to build that myself, I’m just going to straight [inaudible 05:54]

Perry [05:54]: It might be one of those intuitive philosophy I had over the years was, I want to see what is the equilibrium. I want to do what is at that equilibrium, by taking a shortcut, and then transition into the equilibria usually means more work. I know if I want to build a company, eventually, I’m not going to cope. Eventually, I need to build a team, and even hire more and more people. By coding, it might be faster in the short term. But in the long term, there will be a painful transition. It’s the same idea perhaps that if I can start off by buying single families and whatnot, but if I know one day I need to scale, it’s better to start building the team so that I can buy apartment complexes.

Victor [06:46 ]: Yeah, that makes a lot of sense. As they say, the founders core skill can be the company’s bottleneck, because that’s something that you clinged to, right, you’re like, hey, I’m good at this. I don’t know, I’m good at sales, I’m good at coding, I can do this. I’m gonna build a team. I don’t know marketing, because that’s not what I’m good at. But coding, I’m just gonna go to clinch that for the rest of my life. I’m going to micromanage it because I believe I know better. I think that is a big problem for the founder. You just said, no, I’m not gonna go down that path. I’m just gonna straight away build a team. How did you build a team? In the early days? Did you fund that yourself? Where did you find people?

Perry [07:27]: I fund the operation myself, I also found everyone myself. A lot of is through grind and hustle. The first engineer was from Upwork. I got very lucky where they were really good. I thought it was really easy to hire engineers. It turns out the next 20 engineers I interviewed were really bad, so I just got really lucky on that first engineer. The other thing that is more of a tailwind, which I am forever grateful, is with every crisis, there is opportunities. During the pandemic, I was able to work from home. My friends were not hanging out. I don’t have this kind of like Fear Of Missing Out of not being able to go to dinner with them. That’s number one. Second, because I can work from home, I can switch back and forth between, my number two job and my start up. Number three, because of the pandemic, everyone was looking for a job. Now everyone has multiple offers. I’m definitely very appreciative of the good things that were not during that time. They were very favorable to starting a company back then.

Victor [08:39]: When did you start exactly? Was it like, during or shortly before? When did you start?

Perry[08:44]: Literally when the pandemic was starting. April of 2020. A year and a half ago?

Victor [08:51]: Yeah. I mean, it’s easy to say in hindsight, oh, seeing how this has changed what we have right now, it was obvious to, you know, hire people back then, to scale back then, to invest back then, because it was cheap, right. But back then, of course, it was a risk. Of course, it was a gamble. Well, congratulations on taking that. You also said that not only did you hire a team right away, right, but you also started building at scale right away what others, especially in the bootstrap world, especially in this kind of philosophy, people will call that maybe premature scaling. What were your thoughts behind that?

Perry [09:30]: I have a few points. The first point is, in my mind, it was not premature scaling. In a way, I was able to do the tradeoff between what is the risk of not doing that and versus was the risk of spending actual week or two weeks to make it well, or make it fundamentally and there may be there is different levels to engineering. So to me, that’s just the basic engineering. I was like, yeah, like spend a week or two. The business not gonna be over because we spent two actual weeks. But if we do that, then we don’t have to do a database migration. No matter what will become to the database. That’s well worth it, in my opinion. That being said, let’s talk about the product side. Product side, I was a customer, but I was doing a lot of user interviews and give them beta accounts where they can try it out. We do have one beta interview maybe once a week, or twice a week.

That has been very helpful in making our product iteratively better. That’s instrumental. I read on the article that you only probably need five beta users to test a particular feature to have a pretty statistical, you know, early sample, because any incremental feedback is probably not going to add that much more value. If you cannot do A B testing, for example. Now, from an engineering side, I know very well, what we are doing. Even though I don’t cope, I review every tech spec, I know that I should don’t download the GitHub, I read the code sometimes. I know the architecture back and forth. So there will be bugs in which I already foresee things could happen. I translate those worries into almost direction changes and refactorings for the engineers to execute. I was born a engineer in a way. I could think of it like that. The good news, though, is, you know, hindsight is 2020 is once we start getting customers, and they come in just in a hockey stick fashion. We do not need to do any database migrations, our system was stable. Like, if we didn’t do what we did, we will have a very hard time scaling, along with our customers.

Now was that frowned upon by the startup world? Absolutely. There were good mentors at the time. One told me that I should quit so I can go full time. It’s true.
They told me that I should do 10 customer interviews a day to get more feedback. Three is that you’ve been working on it for a year, and $200,000 $300,000 spent, and you have almost zero customers, what are you doing? I don’t know how to answer those questions right now.

Victor [12:33]: Well, for you, it’s definitely paid off, which is amazing. It makes me wonder, because a lot of the founders that we talked to, we work with, they have not experienced working at Amazon or Lyft, or any similar company, and a lot of people are coming from an industry, you know, just what you said, coming from the real estate, we’re all trying to disrupt it with software, coming from with specific market knowledge. Then learning really how to build product, how to build startups, how to build software. We all kind of think that the values that drive us the strategies that we use that they come from the startup world from these, maybe even big companies. But would you say that having worked at these, you know, Silicon Valley unicorns, has taught you slightly different values?

Perry [13:25]: Yeah, absolutely. I think some of the proudest things I have done in the last year and a half was that I make good trade offs between short term goals and long term stability. Because in Silicon Valley, there will be certain bugs and user pain points, that will be become an all consuming matter in the companies I worked at. There will be [inaudible 13:51] For people who don’t know what that means is it’s an incident where customers are pairing degraded service, and one or two engineers will stop everything they do and to go fix it. That’s a very real thing. It is surprising to me that when I was entering this software industry for real estate, that other companies just let these what I consider sets go on for weeks without fixing. I don’t know if that’s just lack of priority, lack of engineers scalability, or just lack of that they have better a bigger fish to fry. I don’t know, but to me, they’re pretty important bucks. I’ll give you maybe for those who are technical, maybe make it a little bit more concrete.

A specific sample is in January of 2021, about nine months after we start a company, when someone make a investment, they are directly attached to a real estate deal. When they should be attached. They should invest not as a person they should be invest through a type of abstraction called investment profile. The profile should be attached to the classes of the team. Now, suppose I went down the path of never creating these abstractions called investment profiles and classes of a entity, it will be really difficult to add the classes back in later. I noticed because there are established software companies, they’re still don’t have classes. I know how difficult it will be for them to add classes, they have to backfill the entire, database or whatnot. We spend, an extra month actually, to just refactor the whole thing in preparation that I know in the future, we need it. To this day, I was so grateful that I did that. Otherwise, we will just be in a constant pain right now trying to refactor.

Victor [15:45]: It’s actually something that I see a lot with startups that build a prototype, then catch the hockey stick train and all they’re doing is firefighting, literally right firefighting, and trying to improve scalability. But I think this is one of the toughest trade offs you can possibly have in a software company is, because in the end, while you’re prototyping, a lot of times, you just don’t have the resources to build properly. You have to take the gamble and and understand if this even catches on. If it doesn’t, then okay, I’m just going to scrap it, nothing bad happened. But if it does, and obviously, I wish I had invested more earlier. So this is, yeah, I’m very fascinated by how you really did a fairly bold move, and how well it it worked out. Congratulations again. Culturally, what did you take from having worked at Amazon, etc.