snir

Sure thing! We hire primarily out of SF, NYC, and Seattle -- in-person has boosted our productivity and been a lot more fun for us! Transparently, we have made a few exceptions, and are not entirely opposed to more, but it's really the exception rather than the rule.

We are in-office 3 days a week, so there is some flexibility built in there, too.

Opportunistically chiming in :)

I lead engineering here at Retool -- reach out to snir (at) retool if you're interested in learning more! We're hiring across several key roles, including AI, performance, our core products, and infra.

Hi all, I'm Snir -- I lead engineering here at Retool.

I wanted to follow up on the above. Solving the round trip problem David mentioned above involves multi-region for our entire backend, inclusive of our DB. This is definitely a priority and something we plan on having by EoY.

Sure, in some sense :) This model exists under a number of names: Pesero, Jittney, Monit Sherut (to name a few). That said, it's not just an app that we've built. It's a system that can make dynamic decisions about which routes merit being paired together, and communicates with our drivers about any changes that need to be made to the current route. Of course, we take on-road safety into account, and so changes are only made while the vehicle is stationary.

Absolutely :) There are lot of systems like this that we took as inspiration. See my comment below on how we formalized this type of transit, and built something that can make more objective decisions as to whether the pairing "makes sense."

Lyft pairs one passenger (or equivalently, one party) to one driver. We've built a system which will actually take your route into consideration, and pair you with additional passengers that are en-route (relative to you). In other words, your ride is shared with other people heading in the same direction you are.

While are drivers are for-hire at this phase (in order to provide a reliable and available supply-side), there is much higher utilization in the car as multiple riding parties are paired to it.

EDIT:

I see the question was changed slightly. Higher utilization makes all the difference. Our current public transit system is just as you've stated: a vehicle being shared by "more strangers" (in your own words). We envision our system creating a completely adaptive and dynamic transit grid, which lends itself to predominant way in which people get around in the future.

Response has been really good (a subjective answer :)). For more objectivity, we've received ~40 leads for one CL post, and got about 10 leads in small little twitter campaign ($5 ad).

People seem to be genuinely excited about collaborative consumption, and we enable route-sharing (I hesitate to use "ridesharing" since the term has become overloaded and isn't accurate to its origins). Passengers are sharing their ride with others, and that's new in the on-demand era.

There have been plenty of mental models built up with the one-to-one sector though (one driver, one customer), so we have seen the need to start explaining from the ground-up, so as to articulate the differences.

We haven't, but that's a great idea. There are some limitations that tether us to cities (so networks like SamTrans in Palo Alto aren't ideal), but AC in the East Bay would be an excellent fit.

Thanks!

We've actually been working on something like this for San Francisco (and we plan to expand onwards after operating here): http://www.takehitch.com

The municipality tends to work a little slower here (chatted a bit with SFMTA in the past), so we're starting with a model that just focuses on private cars. But the fundamental point--dynamic re-routing to create custom routes where people can ride in the same vehicle--is very much in the spirit of what we're doing.

We're still in a pre-launch phase, but check out our iOS app: http://www.takehitch.com/download

Glad you like it!

We dont have any revenue sharing relationships in place with any of the services we link out to. We don't have any plans to monetize at present either. We found ourselves switching out between these different apps whenever making transit decisions, and decided to build it out. If we observe operating costs getting too high, we might seek out those relationships.

Sure thing. Just dropped you a line.

Strange. They should be distinct. I'll look into it.

On the biking side, we're considering looking at joins between biking and other modes of transit. So for example, you could bike an extra mile and get on a different, more direct bus/train (assuming it can carry your bike).

Glad to hear you like the app :)

Haha. You dont have to go that far :)

They're called "Fly Goggles" for those actually interested...

We would be happy to take any of those providers down from our listing if they reach out to us.

As we perceive it, if they chose to be removed, they provide an advantage to their competitors. We're listing them as benefit to our user base, but in doing so, we send over free traffic.

We'll be working on that momentarily. We picked up iOS development just for this, and will do the same with Android. Hopefully in two weeks.

Thanks :)