Build Uber-for-X within a day using HyperTrack
blog.hypertrack.com
blog.hypertrack.com
- Drivers said they joined Juno on the premise that they would receive equity from the company. - Gett acquired Juno for $200 million and the equity program was done away with. - Drivers are suing for breach of contract, false advertising and securities fraud.
In order for that structure to work, the company would need a new fund structure that would make it both scalable and impossible to dilute the worker. From my limited knowledge, most of the funding power goes to investors and since these types of businesses generally rely network effects, it seems difficult to kick this system off. I'm not saying it's impossible, I'm just not smart enough to figure out how to get the ball rolling.
[1] - https://www.cnbc.com/2017/06/19/drivers-sue-uber-rival-juno-...
Why not make it a non-profit corporation, then there is no ownership (stock) and the company can't be sold.
Basic structure: You have members (drivers), they vote the board and in turn the board votes the officers who run the operations (corporate compliance). There would obviously be salaries for the officers, but they wouldn't/couldn't exactly get out of control because they would be set/approved by the Board, and if the Board would be put in check (voted out) by the members (drivers). And that is just the default, you can get far more creative with the actual business agreements and corporate governance documentation to ensure no funny business for the get go.
But you're right the funding scheme would be more challenging. But if the service sold is of very good quality, it may work. And the "not for private investors" model may also be something good to promote for (some) consumers.
> But the icing on the cake is Juno's equity offering: 1 billion of the company's founding shares reserved just for the drivers. [1]
It was all stripped away when the company was sold off to Gett because of liquidation preference because now.
> But drivers were soon informed by emails from Juno that the stock plan was void. They could instead receive cash payouts amounting to less than what they could make in a day of driving. [2]
[1] - https://www.theverge.com/2016/3/29/11301076/juno-uber-driver...
[2] - https://www.bloomberg.com/news/articles/2017-04-28/juno-sold...
Lets say your startup sells 20% to an investor (round A), keeps 50% for founders/direct employees, and allocates the remaining 30% to "workers", i.e. drivers, employees. Now you run low on money and go out for round B.
Where is the equity for the round B investors? Say they want 50%, who takes the dilution? Just the round A investors and founders, taking them down to 6% and 14% respectively so workers can stay at 30%? Thats never going to happen, the B round investors aren't going to give funding to see founder incentives massively reduced (unless they plan to replace founders). They want the people they think are most likely to make their investment successful to have the most skin in the game, and that's very unlikely to be workers/drivers.
Also when an investor gives a management team and workers a big round of financing, they typically expect preference in future rounds. Especially if you don't achieve your promised objectives, your A round investor doesn't want to take the same amount of punishment as you will.
Whether you are an employee or a driver, you will almost always get common stock. Investors will get preferred stock. Preferred stock can have all sorts of negotiated rights, but almost always it means that they will get their investment back before common shareholders get a dime. This kind of structure actually makes venture capital possible, the vast majority of investments fail and being able to recover some of their investment from many of them instead of a huge smoking crater keeps funds going until they finally book a big winner. So if your company takes $200M in funding and then sells for $200M, the only payout employees can hope for are retention bonuses for key players.
What Juno did looks really sleazy, given they supposedly only raise $30M and sold for $200M liquidation preferences should have nothing to do with it. And drivers got restricted stock grants, not options for common shares. The difference is options are worthless until the option price is reached. RSUs are typically structured so you always get value, you don't have to reach any exercise price. No idea how they could only end up with 2 cents per share unless Juno had 20 billion shares, which is ridiculous.
Form 1: Freelance designer and coder co-op. Top players were continually dissatisfied with performance of their peers and the bargain-basement rates that would result. And their only remedy was to go join a normal company.
Form 2: An employee-owned taxi company with a 100-person board whose response to Uber was, "Oh, we just need an app." However, they couldn't agree to change any of their practices, resulting in people still not being guaranteed service when booking through the app. And no customer feedback or punitive mechanisms for drivers not following through. The system is: Cabbie clicks in on the radio and says "I'll take that fare." After that, if they see an easier-made buck on the way, they divert and grab that instead. The customer doesn't get service.
This is not to say that any given co-op is doomed, but consider this: A community, of which the customer is not part, making decisions in a mostly democratic fashion, will frequently devolve into each member acting and voting in self-preservation within the organization. And with no one to wield a hammer on behalf of the customer, eventually killing the entire organization with a thousand paper cuts.
Were I to attempt something approaching a co-op today, from the ground up, I would want to think very hard about how to create a governance structure that could prevent the organization from cannibalizing itself. Can it be done? I'd like to think so, but I also think it would be very difficult. And dangerous to get wrong.
Of course, in the end it's competition that's keeping businesses customer focused. (Or rather competition provides for the survivorship bias so that mostly customer focused businesses survive.)
In practice you still get principle-agent conflict. But so far they are still doing well by their customers in practice.
I've been pushing to get our data exposed via API for developers to build apps and one of them I'd like to see built is a delivery service for owners to use.
Y'all have a good thing going. I just don't think the co-op model necessarily translates to that many scenarios. Park Slope Food Co-Op depends a lot upon volunteer hours, and operators are customers. I think that's been the distinction in every co-op or co-op-like that anyone has cited as successful. They're customer-owned as much as they're employee-owned.
All of our owners also must work 2.75 hours a month, and you can't shop at our coop without being an owner.
I have seen some other coops where they have separate pricing for owners vs. members vs. regular folk, but I don't know how successful they are.
About half the reason I joined the coop was to get a look under the hood of how a coop like this works - so far I've been fascinated and learned a lot about human psychology and politics.
In some sense, Uber drivers are also customers, in that they are buying the leads and software from Uber corporate.
I also think if there are ways to have customers also be owners that can be a really great set up.
Coops on the other hand exist to serve themselves, not their customers. That's why small scale communes and cults work better. They enable self sufficiency and owner happiness, which may be mutually exclusive with good customer service.
E.g. the Cooperative Group in the UK which is owned by its membership (customers and staff)
That leads to the right incentive structure!
TaskRabbit and Upwork has that I think.
Alternatively, you could pre-sell credit at a cheaper price, as a sort of crowdfunding.
Btw in 2016, at my previous startup we had used HyperTrack services for tracking of sales personnel on the field. We had issues with accurate location reporting and also there were quite some bugs. We then decided to stop using their API's. I hope that by now these issues are resolved.
Uber-for-X and on-demand have become bad words just like ecommerce and dot com did in 2000/01. We are long on the Uberification of every industry out there. And are seeing forward thinking companies of all shapes and sizes use the power of the smartphone location/activity to build awesome features to grow revenues and reduce costs.
If your brand new Uber-for-X needs great user-to-user chat (like Uber itself recently added), consider adding TalkJS within the same day. https://talkjs.com
That said, I was looking for something very similar to talkjs and am going to try it out thanks to your post. So for me it was very useful and would like to ask you some follow-up questions off of hn.
on one hand, who am i to arbitrate relevance? on the other hand, i really think you're pushing it.
"HyperTrack of messaging" -- you are using "HyperTrack" here, the proper noun, as an analogy for "SaaS". TalkJS is "SaaS of messaging". and i think "hey i have a SaaS product too!" is too broad to be contextual.
a similar scenario would be an employee of Stripe posting in this thread, promoting Stripe. sure they could argue it is relevant. i'd argue they are trying a little too hard to make it so.
forgive me if i've missed something.
That said, there's more commonalities between HyperTrack and TalkJS than just that we're both SaaS - both products help you build a marketplace type platform faster. HyperTrack makes it easy to build location sharing between your users, we make it easy to build message sending between your users. Most SaaS products, even most chat products, don't have that dynamic. You can't use Intercom or Slack to build user-to-user messaging on your platform, just like you can't use Google Maps or Mapbox to (easily) build realtime location sharing on your platform.
About your Stripe example: I agree about Stripe in general, but as a matter of fact their Stripe Connect product happens to be a miraculously great fit, becaue it's a service for user to user payments. HyperTrack + Stripe Connect + TalkJS means you can have a functional Uber with all bells and whistles in just a few days.
I felt it was on-topic because this article isn't just about HyperTrack, it's about building an "Uber for X" in a single day.
ps - TalkJS website is awesome. triggers my retro feelies
ps - Thanks!
Seems like a no-brainer for HyperTrack to make a template app so that this becomes even simpler. Their example setup seems very agnostic to the system.
P.S. There are a few more example apps (that use HyperTrack) that we open-sourced. Do check https://github.com/hypertrack. Would love to get your thoughts.
My temporary conclusion is that the MVC pattern and defining constraints in a text-based programming language (as opposed to the visual drag-n-drop languages commonly used in software generation systems) is the best abstraction we can come up with without making the framework so rigid it suffers from leaky abstractions and hence comes apart rapidly.
It might seem like mostly clerical work and it isn't exactly accessible to non-programmers but the tools and frameworks commonly used for creating CRUD apps already abstract away a lot of the plumbing code that used to be necessary to do this.
Although on the surface most CRUD apps at least conceptually look exactly the same the devil often is in the details: Legacy databases, weird interfaces and data formats, data has to be imported from Excel, you name it.
Regenerating / modifying an app upon model changes can become particularly arduous depending on how frequently those changes occur.
If your data model conforms to some constraints though creating a run-of-the-mill CRUD app with tools like Spring Boot, Swagger and a generic, declarative UI is both fairly easy and robust.
As soon as the UI has to accommodate more specific use cases or you want to provide a more focused, less one-size-fits-all UX a mostly automatically generated UI however will fall apart rather quickly again.
By the way, at its core Uber is a CRUD app, too, isn't? Perhaps we don't need a generalised CRUD app generator but rather very specific app generators like this one.
A lot of effort is spend on just contacting either individual drivers or many small companies just to see who can pick up 1 container. This often done via multiple phone calls.
This "Uber-for-X" assumes you need it right now. Usually in logistics you don't; it's just the hassle or figuring out who can do it ahead of time.
Despite that, seems fairly similar. The number of truckers is quite impressive though wonder if those are capable of trucking a container.
Seems Uber is looking at tapping into the larger logistics market itself
Iow, do they "control the gates"?
- HyperTrack does not store any information about your end customers, or reach out to them. We empower you with information that can be sent to them. Eg, "your order is being delayed by x mins" is available as a webhook, which you can potentially use to fire a notification to your customers.
- In addition, all data that is collected and visualised is accessible via APIs. Developers can retrieve data, and store it in-house.
- The HyperTrack mobile SDKs will be open source, and it will be possible to hook it up with a different backend. This will allow you to utilise the robustness of the SDK without relying on our backend.
Does that answer your concerns?
I'm guessing it's a course or tutorial for a tool or a service but if the FAQs don't show up from the outset, not sure I could take it to my bosses at this time.
When we started, we imagined that apps for work would find us most useful. We have been surprised with the number of apps for consumers who tinker with our stack for building live location sharing and geofencing use cases. For example, a messaging app used us so groups that were meeting up (for beer, say) could track each other in the same map fragment. Another developer used us to profile the places (bars, say) where a user's social graph hangs out. They used it to make better recommendations. Do you think stuff like that has room to grow?