We have a mobile app that connects drivers and passengers so they car share their daily conmutes

Hoop Carpool

[A Step by Step Guide] Create a Carpooling App with React Native - Part 2: {Creating the Frontend}

302 Stories To Learn About Front End Development

How to know which feedback to listen to for your startup. If you’re starting a new business, launching a new idea, or doing anything at all really, you’re going to be getting a lot of feedback. People are going to tell you if they love it. And you’re inevitably going to hear some verison of: “That’s not a good idea.” The fact is, you’re probably going to hear that one a lot, and from a lot of different people. Some of them perfectly well-meaning. So, how do we determine which feedback matters the most? When we’re overwhelmed with messages about our ideas being too risky or not good enough, how do we filter out the noise and get to the feedback that really matters? How do we know whether to listen to the people saying yes, or the people saying no? I’ve dealt with this problem a lot. Over the course of my entrepreneurial journey, I’ve had more than a few ideas. Some of them were winners. Many, not so much. Some I never really got the chance to find out if they would be successful until it was too late. Some I left behind because I listened to the feedback. wrong This is the story of an idea that I wish I’d done more with, and how it taught me which feedback to listen to, and which to ignore. Looking back at this, I realize what I should have done differently (and that I potentially could have made a lot of money!) had I only known then what I’m telling you now. One weekend, my buddy Krish managed to get us a spot in a lean startup machine workshop. Normally, this would have cost us a few thousand dollars. Somehow though, he managed to get us in for free. For three days, we’d be attending this workshop and working on our own ideas for a startup. I was pretty excited for this opportunity. I'd recently read The Lean Startup, and was interested in getting more hands on with it. Inside the workshop, we divided up into groups of three to five people. Each group was tasked with coming up with a potential startup idea. Once we had one, it was time to hit the streets. Having the idea wasn’t enough. We needed proof that our idea had value, and we needed to get that by getting people to sign onto it in one form or another. We needed to hear from our potential customers. Now, a lot of the people in my group lived in the upper east side. This workshop? It was in downtown Manhattan. This was before the days of Uber. We had two options for getting there. Either we cough up the money for a expensive cab ride, or we use the subway for a much cheaper, but also much slower, commute. very This was the problem that we tackled with our startup idea. We called our solution “CabPool.” A clever twist on the phrase “carpool.” People would use an app to find others going to the same place as them and share a cab, splitting the cost. very If you’re drawing parallels between what we were thinking about and rideshare apps? Trust me, I’ve been doing that for a while, too. When it came time to test our idea, we planted ourselves in front of a Whole Foods market. The plan was simple. We’d wait to see someone hailing a cab and ask them if they’d be interested in a program like ours. We even had a little application. When someone said they were interested, we’d ask them where they were going so we could find a match for them. Sort of. For the purposes of this test, I was the person waiting for the ride, and trust me, I just so happened to be going the same direction. They’d be matched up with me, I’d hop in the cab, and off we’d go. We made small talk along the way, and then, at the end of the ride, we split the cost. The people I talked to seemed to genuinely enjoy this idea. Not surprising, right? Who doesn’t want cheaper transportation? Whether that was the idea itself or just my winning personality, you be the judge. As we did this, we got people to give us money. So, when it came time for the judges to determine which group had the best idea? We were pretty sure that we were going to win. We did not, in fact, win. The judges told us that, despite the fact that we’d made some money, our plan wasn’t a good idea. It simply wasn’t going to work. The winner of the competition had proposed an app that would let people know when a parking spot opened up and where it was. I’m sure it’s a complete surprise that a lot of people in NYC were thinking about traffic, commuting, and parking. Their group hadn’t gotten anyone to give them money, like ours had. Instead, they had gotten people to sign a letter of intent to use the app. The judges decided this was the better approach. Now, I don’t want to harp on their idea, but I do feel like it is worth pointing out that a parking spot in NYC is probably only open for about 60 seconds on a good day – according to the team whom presented their findings... By the time you check an app, find an open spot, and drive to it? That spot isn’t empty anymore. That’s probably the reason we’re not seeing this kind of app around much. Nevertheless, we took the advice of the judges. After all, they were experts on these things, right? This had only been a weekend idea for us, not a serious venture. And the judges had told us it hadn’t been good enough. Why continue on with it? Obviously, given the success of rideshare apps, we probably should have ignored them. The judges, the experts on the issue? They were the feedback we chose to listen to. They weren’t the feedback we have been listening to, though. should The customers that we had over the course of the trial had been giving us feedback too. They’d been doing it with their wallets, and they’d been doing it in a positive way. was the feedback we should have been listening to. That Our customers voted with their wallets, and we decided to listen to the people who had no financial interest in the matter. When you launch a new idea, that idea is always going to have some detractors. Those detractors might even be the experts. They might tell you that your idea isn’t a good one. That there isn’t a market for what you’re thinking of doing. That data? It really isn’t all that useful. The useful data comes from your customers, and how they choose to vote with their wallets. We had people voting yes, putting their dollars down on our idea. We didn’t listen to them. We listened to the experts instead. That was our mistake. Don’t let it be yours. When you’re starting something new, the main feedback you need to listen to is the one that comes from the customers. Are they willing to spend money on what you’re proposing? That answer matters more than any other, and is going to really tell you if your idea can work or not. When people vote with their wallets, listen to them. Do you have an idea or product that you want to turn into a full-fledged business? Click here to learn more about me and my agency, Unbounded, and how I can put my experience to work for you. Images licensed by Adobe Stock Photos. First image by fuzzbones . Second image by Семен Саливанчук

Have You Ever Been Told Your Business Idea Sucks?

Scaling SpotHero and the Future of Mobility

An interesting message popped up on my radar from Kevin Law on September 21st, 2016: “You’d be a perfect fit for a company I’m advising if you’re extremely flexible on location” Since I love working on early consumer products and traveling, it was only three weeks later that I touched down at the airport in Kampala. Serve as interim CTO for 1 month and provide leadership to a small ride share engineering team, paving the way for future success. The mission: (Note — there are several HD YouTube videos of Uganda at the end of this post if you’re like me and you like to watch videos.) Boda Boda A “boda boda” is an inexpensive motorcycle ride offered in African cities (for my San Franciscans, imagine a ride from Hayes Valley to the Marina for just $1 versus a $5 Uber carpool). It is estimated that 1,000,000 boda rides take place everyday in Kampala. While on a walk, upon reaching a sidewalk, you will find you are solicited by a boda driver within seconds. “Boss!” “Boda!?” A regular boda ride involves hopping on the back of a boda driver’s low power motorcycle. He will take you on a harrowing ride, dangerously weaving through the chaotic gridlocked streets, sometimes crossing a median, often narrowly avoiding a collision or sideswiping a bigger vehicle, and sometimes just driving on the sidewalk. Passengers rarely have helmets, they sometimes double or triple-up on the back of a single bike, drivers are often unlicensed, and, at least in Kampala, there are very few traffic signals, street lights, or stop signs. At the end of the boda trip, you negotiate with your driver and you pay in cash. A look at the streets of Kampala during the day. Video shot . here Don’t let the above-mentioned video fool you- if it looks fairly organized in the video, one must only travel a block or so before you hit points which seem totally chaotic. Most intersections are very disorganized and seem extremely dangerous to a like me. mzungu Drivers Want “SafeBoda” The name of the company I consulted for is called . Its business hypothesis is that consumers may want a safer, organized, and vetted system for requesting a boda ride. SafeBoda drivers are screened, have a bright orange reflective vest, and have an extra helmet available for you to wear on the ride. The SafeBoda driver’s unfair advantage? - they get many more boda passengers than before they were a “SafeBoda” driver and therefore they make more money. SafeBoda drivers also have access to insurance, quality equipment, training in first-aid and road safety, and a sense of community that is rare in the industry. SafeBoda Evidence of early traction is that with virtually no technology, SafeBoda was able to sign up over 1,300 Kampalan boda drivers who each pay a fee as part of their onboarding. SafeBoda was so successful at this that they stopped accepting new drivers in order to focus on passenger demand and product. Before my arrival in Kampala, SafeBoda had a basic app in the Google Play Store with which around 1,000 rides per month were taking place. Clip of my “SafeBoda” ride from my apartment to the office Uganda’s Mobile Phone & Payment Technology Android is king in Uganda with around 70% market share. iPhones are rare… perhaps a 3% share. There are also ‘feature phones’ which only allow calls, texts, and a basic interactive textual menu provided by the carriers ( ) which I would estimate is used by the remaining 27% of users. USSD The major cellular carrier is called . In addition to data plans and voice calls, MTN also provides a money transfer service called “Mobile Money” which is tied to your SIM card and used by around 85% of Uganda’s citizens. MTN A Ugandan can deposit his or her pay (which is usually disbursed as cash) at any one of thousands of MTN locations throughout the country. MTN Money locations are usually offered as an extension to a physical store front such as a market or street vendor. After depositing cash at an MTN Money vendor, the balance on the user’s mobile interface instantly updates. With the updated balance on the mobile interface, the MTN Money balance can then be used to pay bills and transfer money to others at a cost of ~3% in fees on each transfer. Clearly as part of a technology revamp, SafeBoda should include MTN Money as part of the payment solution. However, we wouldn’t be able to complete the integration within 10 days due to MTN’s stone aged SOAP-based API. Instead, we decide to use Stripe’s API platform which we can implement in 1 day and which the founders felt would help to validate whether or not credit card holders are willing to use the service. It is decided MTN integration will take place in a subsequent development cycle. SafeBoda’s Legacy Tech Upon my arrival, the 5 person engineering team had first created a PHP / MySQL backend on 1 server, but then decided to rewrite it using with after they had encountered a series of problems related to connection issues and deliverability problems with the Android client. CodeIgniter Digital Ocean Node.js Socket.io On my arrival, some of the problems the local engineering team was grappling with were: When the client would miss a socket.io message, the app would strand The MySQL database was hard to migrate The code was peppered with large, hand rolled complex inline SQL queries The developers were actually testing against the production servers There was a lot of opportunity to improve both the development process and the product. Overhaul In 10 Days I convinced the founders to let me drive a complete overhaul to their product architecture and process in 10 days flat — roughly 300 man hours split between just 3 engineers. Having worked for over 2 years engineering at Lyft, I also know a thing or two about the best way to design almost anything related to ride share services. Scaleable product architecture and fast development process using technologies the team is already familiar with was right up my alley and my experience would allow us to leverage everything I had learned. I wanted to use Python and , but after interviewing the team, I was able to see that due to their lack of significant Python experience, there would be little chance we would have a working revamp in 10 days. I had to keep them on PHP… something that made sense for them since scaling wasn’t an issue yet and rapid prototyping and market validation were the main focus. We would generally build with an eye towards future scalability in case things explode out of the gate, but for now, fast development was priority #1. Flask With 2 of their existing devs, the three of us started a 10 day process in which we locked ourselves away in a room, worked almost until midnight every night, and emerged at the end of the 10 days with a new minimally viable system. Below is an animated gif (pardon the low resolution) of the “Golden Path” of a ride request & boda driver pickup. This recording was made on the evening of our 10th day of development. This screen recording used the real API’s that were working on the 10th night. A “rough cut” of the working app. All of the screens used real API’s behind the scenes on our new server architecture. Almost all of the values were dynamic and correctly pulling from the REST API. Obviously several ui features were not completed at this stage. The following week, the Android interfaces were updated: HD video of the golden path about 1 week after the animated gif was recorded. How We Made It In 10 Days When you rapidly build something, you start with an idea of what the features will be, what platforms it should run on, and who will do what. Given Android is the market leader, our mobile developer would build out all of the front end screens according to our product spec. We mapped out all of the screens on a whiteboard and then our Android dev was off to work. The other developer and I would would hack out the backend architecture. We would create a new development process, infrastructure, product architecture, and API’s. We would document them, and hand them to the Android dev to implement on the 4th day. Hosting on Heroku Hosting this project on propelled us faster and further than I had originally imaged. Using Heroku pipelines with GitHub integration meant that once a pull request’s tests pass in Circle CI, it automatically deploys into our staging environment. I had never used Heroku pipelines before, but I think it’s amazingly easy to setup and very powerful. Heroku Heroku’s awesome pipeline interface used for deploying to production The best part is that as we open up pull requests, Heroku senses it and offers us an ability to launch a test app called a “review app” — you see it above in the left column. One click will launch a fully operational environment that you can connect the mobile app to in order to test an upcoming feature. Setting all of this up takes only 3–4 hours, which includes learning how it all works. Dockerized Development In production, we use mlab.com to host MongoDB version 3.2. Docker allowed us to launch a local Docker development database container with 1 command: docker run — name mongodb -d mongo:3.2.10 (Note — some of the additional switches we use are omitted for brevity) As for PHP, I was able to create a PHP dev environment container that closely mirrors Heroku’s environment. The devs can do a similar docker ‘run’ statement to launch a local development container through which they can work on their local PHP files, do live debugging with PHPStorm via both web and cli requests, and even test their local development using an Android phone across an ngrok tunnel. PHP Application Framework The closest thing PHP seems to have to Python’s Flask is called . Lumen gives you a basic routing system and is setup to support REST API development. It makes versioning your REST API very easy. It also supports adding “Middleware” which performs things like API authentication. One thing I personally like is the IOC injector that detects which objects your controllers would like to use and automatically injects them for you by default. Lumen For Mongo access, we used PHP’s — an open source data mapper for MongoDB that we used back at and a project to which I have also been an . Doctrine ODM Lyft open source contributor to Gameplan On day 1, we mapped out our data model. We really only needed two key domain models: User & Ride. We then went to the whiteboard and defined our ride state transitions. The happy path looks something like this: ‘requested’ -> ‘accepted’ -> ‘arrived’ -> ‘pickedup’ -> ‘droppedoff’. There are two edge cases. One is that if our dispatcher fails to find you a ride, we set the state to ‘operatordispatch’ - a final state in which the mobile client simply displays the number to SafeBoda’s human powered dispatching call center. They’re able to manually setup dispatches to drivers who have feature phones. The other case is when the passenger cancels — that’s a final state where the request ends. If the driver cancels, the dispatch loop just continues. Below are some of the actual whiteboards drawn in our kickoff on day #1. Initial diagram of the ride initial state changes. Some chicken scratch from that first meeting where I described the way the phones would poll the server and how we would structure the HTTP JSON server response. From left to right: Charles, Kirk, and Jon (me). RestAPI We next sketched out a basic HTTP REST API that has methods such as: Create a ride request. POST /v1/ride Update a user’s current location. PUT /v1/userlocation In total, we have about 20 REST calls that were defined. We wrote the whole API spec up in an swagger.yml file that is rendered beautifully if viewed with . http://editor.swagger.io/ For the following 9 days, we hacked away. We didn’t attend any of the company meetings and we spent some of the time in my personal apartment so as to not be distracted by anything. Service Oriented Architecture As with most minimally viable apps, we created a tiny so-called ‘monolith’ app. I like to organize business logic into service classes — these become the foundation of what you would eventually ‘decompose’ later into application partitions, or what some people call “microservices”. In our app, we have the following PHP “service” classes which can easily be broken out into the future and implemented in any programming language into microservices: Behaviors responsible for converting between USD and UGX using the latest exchange rate. Currency Behaviors responsible for finding the nearest drivers, and powering the dispatching lifecycle. Dispatch Behaviors used to determine the number of minutes it will take to travel on the road between two places Eta Behaviors used to authenticate a Facebook user and retrieve profile data. Facebook Behaviors responsible for tracking analytics event information. Metrics Behaviors related to billing users using a payments gateway. Payments Behaviors related to pricing rides. Pricing Behaviors related to casting a rating for a ride and then also updating a driver’s record to update their average rating. Rating Behaviors related to creating and updating a ride. Ride Behaviors related to user creation and update. User Behaviors related to updating the user’s location. UserLocation Coping with Eventually Consistent Data Due to the fact that MongoDB is not an ACID database, the application must be able to cope with database references which can be out of sync. In MongoDB, there are no transactions or rollbacks. To help overcome concurrent update contention and data loss, we use optimistic record locking by default on all updates. We use Doctrine’s event hooks in order to ensure two records point at each other. For example, If I put user A in ride B, I will first update user A’s record to have ride_id = B’s id. Then, during the post update hook, I will next update ride B’s user_id to have user A’s id. There are short moments when the database is therefore out of sync during normal operations. Further, the app might encounter a show stopping error before the 2nd update hook completes, leaving the database in a state where the user record indicates the user is in a ride, but the ride does not correctly point back at the user and this would be the source of trouble if your code is not setup defensively. To cope with this, we must have protective ‘cleanup’ routines that check for situations like this. Before key business logic fires, we invoke a “cleanup” routine to ensure the data integrity is correct. Note that we do not employ MongoDB’s “ref” feature — we manually store record id’s and resolve database references manually. Also noteworthy is that when we update the user’s location on their user record, we perform the update without the default optimistic locking record strategy used throughout the rest of the software, or else we would see tons of optimistic lock exceptions for no good reason. 3rd Parties Tools We Used GeofenceAPI PagerDuty PaperTrail for MongoDB hosting Mlab.com for Jenkins & S3 hosting Ec2 for the API cert, for the Jenkins cert RapidSSL LetsEncrypt CircleCI Mixpanel InstaBug Features & Hindsight A surprising number of drivers in Uganda cannot read maps. Some clearly had trouble knowing left from right. The society is also highly cash based and most folks don’t have credit cards. If I had known some of these things, I would have advocated for a slightly different MVP in which relied less on screens with maps on them and put more emphasis on calling the driver. Conclusion The developers are no longer testing against production machines. We ditched complex hand rolled inline SQL for a MongoDB solution which requires no production migrations. If the project takes off, MongoDB will allow us to add more shards and rebalance data. It’s now up for the market to decide if the product is the right one for Uganda. A Personal Note Living in Kampala for a month and working on a real startup again was awesome. I feel personally enlightened and the trip gave me a new perspective on the world. In San Francisco, we have a lot of millionaires & billionaires and I often feel like I’ve missed out on something that everybody else was able to achieve. However, my trip to Africa made me realize just how fortunate I am to be a self made engineer and what an achievement it is to even be able to live in San Francisco in the first place. My 30-day contract has ended. I wish the founders the best of luck. Here are the current state of things: SafeBoda is seeking an on-site full-time CTO. If you’re up to the challenge, contact team@safeboda.com The version of SafeBoda in the Android Play Store is still the legacy version of the app. They continue to make iterative improvements to the upcoming platform, and have a strategy to release the new platform in January. The work we accomplished currently lives in the beta channel. Make me proud guys! Twitter: Email: block.jon@gmail.comJoin me on the DoorDash API Platform Team and browse other available positions: Contact: @blockjon https://www.doordash.com/careers/ Pictures And Videos From My Trip KLM flies from SFO all the way to Kampala’s international airport with layovers in Europe My former office: San Francisco’s luxury “China Basin” building. My Kampala office? This inexpensive building. Photo taken . here HD clip of a ride down a street in Kampala shot from an Uber. A look at some Rhinos which were going to sleep for the day World’s most powerful waterfall Heading towards the center of Murchison National Park — home to thousands of wild animals Giraffees in the road in Murchison National Park Elephant hanging out at the water’s edge on a hot day. Hippos in the water. Walking from my apartment to the coffee shop. Filmed . here A Ugandan lunch: Rice + G-nut sauce, sweet potatoes, cabbages, and greens. Wiping out in a Jinja class 4 rapid (me in front left) A sophisticated fashion event Buying a breakfast sandwich “Rolex” on the side of the road in a slum. Video shot . here Eating tilapia at the shore of Lake Victoria. Video shot . here Inside the ultra-modern Acacia Mall food court Buying a random rolex on the side of the road heading from Jinja to Kampala

How engineering @ Lyft helped me launch a new African ride share app in 10 days

237 Stories To Learn About React Native

Why (and how) our startup spends $10K on our annual retreat

By , Co-Founder and President of Spin. on . Euwyn Poon Originally published Quora When I was a kid, I’d spend hours daydreaming about the future. What would the world look like? How would we all get around? In my imagination, people would step onto moving sidewalks and be whisked away to their office, the grocery store, the bank. The moving sidewalks of my imagination have yet to appear. But there is a need for a new kind of urban transportation — something that can reduce our dependence on Ubers, personal cars, and even bikes. I’m betting on the scooter. But not just any scooter. A motorized scooter that starts with a couple kicks and then glides over sidewalks with ease. Maybe it sounds a little fantastic, but our team at Spin already has scooters in operation in San Francisco. And they’re going to change personal mobility in a major way. Here’s why: Urban migration is skyrocketing. More people than ever before. live in cities now And most young people aren’t dreaming of suburban enclaves with manicured front lawns and big backyards. They want to be downtown in the mix. They want the conveniences of city life rather than the quiet of the suburbs. This migration is increasing stress on already overburdened transportation systems. And cities are taking note. In Germany, just cleared the way for cities to ban cars from some streets. already has plans to close off many streets to cars and give the city back to pedestrians. And London is slapping the owners of diesel engine vehicles with a if they drive in certain areas. a court ruling Barcelona “congestion charge” These efforts are only going to accelerate as cities attempt to curb pollution and create a more livable environment for both new and long-time residents. But an enjoyable environment isn’t the only factor cities have to consider. Current personal mobility options are causing congestion. Right now, the car is still king when it comes to getting from point A to point B. But cars simply aren’t an efficient way to travel around an urban environment. Sure, it’s great for carpooling. But take a look around the next time you stop at an intersection. How many of the cars are full of people? How many only have a driver? Ridesharing efforts like Uber Pool have helped with this problem, but the reality is, there are still gaps. Personally, my office is just far enough from my apartment that walking isn’t a good option. But driving isn’t either. When I call an Uber, I have to wait for them to fight through traffic to arrive. Then, we battle more traffic along the way — sometimes stopping to drop off other riders. I recently had to cancel a dinner meeting because of traffic. I called an Uber to pick me up from my office, hopped in, and made it one block before getting hopelessly stuck. Since the restaurant was across town, I called my business associates to cancel, got out, and walked back to my office. A smaller, easier mode of transportation is more convenient for moving around cities. Bikes are the current alternative to cars, but not everyone enjoys riding them. That made me wonder why and look to other options. Riding a motorized scooter differs from riding a bike in a key way — you don’t break a sweat. When we were testing both bikes and scooters here at Spin, it became clear that the scooter has a much lower physical barrier to entry. And motorized scooters don’t take a tremendous level of coordination to operate. Everyone gets it on their first try, which adds to the fun factor. Two people can even ride them side-by-side and hold a conversation without much difficulty. We don’t just need a new mode of transport. We can benefit from a new model of ownership. Similar to bikes, scooters can be shared. While they’re lightweight enough to carry, they aren’t the type of thing you’d bring into a restaurant with you. At Spin, we made our scooters stationless so you can park them anywhere without worrying about what happens next. And their small size makes that manageable, even in areas with high foot traffic. We’re already testing our scooter in San Francisco to learn how riders use them and how adoption will spread. And I can’t wait until people in every city across the U.S. can hop on a scooter, skip the traffic, and ride to their destination. By , Co-Founder and President of Spin. on . Euwyn Poon Originally published Quora For more trending tech answers from , visit . Quora HackerNoon.com/quora

HOOP CARPOOL

hoopcarpool.com

-- employees

Since n.d.

COMPANY RANKING

HOOP CARPOOL

EVERGREEN INDEX #5554

Representing this company? Click here to claim and customize this page!

Hoop Carpool WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

HOOP CARPOOL

hoopcarpool.com

-- employees

Since n.d.

COMPANY RANKING

HOOP CARPOOL

EVERGREEN INDEX #5554

RELATED COMPANIESRANK

STORIES ABOUT HOOP CARPOOL

Representing this company? Click here to claim and customize this page!

Hoop Carpool WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!