Build Uber-for-X within a day using HyperTrack(blog.hypertrack.com)
blog.hypertrack.com
Build Uber-for-X within a day using HyperTrack
https://blog.hypertrack.com/2017/08/24/build-uber-for-x-hypertrack/
58 comments
If you're considering building an Uber-for-x, why not incorporate as a co-operative - a business model where there is either 1 worker 1 vote or 1 consumer 1 vote (as opposed to 30% of shares being a result as 30% of capital investment)? The reason for this is I think there's a lot of 'bullshit jobs' but this way at least people have ownership over what they are getting involved in and can elect a board etc. Could be a great experiment! There's also unique instruments for fundraising in this sector and opportunities for government funding. There's still a board of directors (elected) and a usual employee hierarchy stemming down from there. Founders can take all that they need to reasonably live on (and retire) in the form of some salary compensation package, with a legacy that creates a social enterprise and goodwill & a recession proof business model (when times are hard - co-opertives are more resilient because of this shared ownership & goodwill. When times are good, profits can be distributed - in addition to everyone's usual pay etc).
Co-ops aren't a new idea, and they certainly can survive. But in the two forms I've really seen them in action, they have been a mess.
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.
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.
I co-own a grocery store with ~16,000 other people (FoodCoop.com). We've been around since the 1960s and do about $50MM a year in revenue. It certainly has crazy political issues -- there has been a political war within the org for the last few years surrounding just getting together to vote on boycotting certain products, but we offer the freshest, most local and most affordable food in NYC (and this is in one of the most sought after neighborhoods in the city -- Obama once lived in a brownstone down the street from me).
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.
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.
Hello, fellow Park Slope yuppie!
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.
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.
Very true.
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.
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.
John Lewis/Waitrose is a successful full scale co-op in Britain.
https://en.m.wikipedia.org/wiki/John_Lewis_Partnership
https://en.m.wikipedia.org/wiki/John_Lewis_Partnership
I find it amusing you'd think of them first rather than... The Co-operative? https://www.co-operative.coop/about-us
Vanguard might be a good role model? I'm not sure exactly how they are organized, but I think they are owned formally owned by their customers _and_ seem to be doing a good job at providing customer surplus.
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.)
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.)
Vanguard is owned by funds that are owned by shareholders. Essentially, it's customer-owned. That's a very different proposition.
Yes, on paper its customer owned; and that's why I suggested it as a role-model to study.
In practice you still get principle-agent conflict. But so far they are still doing well by their customers in practice.
In practice you still get principle-agent conflict. But so far they are still doing well by their customers in practice.
I'm sure you've already seen Juno's attempt at this experiment[1].
- 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-...
- 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-...
It seems to me this example has nothing to do with the parent's comment. He is talking about co-ops. Companies that are owned by workers. It implies the company cannot be sold without a majority of workers to agree.
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 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.
Juno was owned by the workers - They had equity in the company based on when they started.
> 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...
> 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...
>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.
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.
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.
if it's impossible to dilute the worker, it's impossible to fund the business.
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.
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.
The incentives are perverse when a co op runs this way. An uber for x (or pretty much any company) succeeds when there's a maniacal focus on the customer, sometimes even at the expense of the contractors or employees used to service them.
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.
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.
Not necessarily
E.g. the Cooperative Group in the UK which is owned by its membership (customers and staff)
E.g. the Cooperative Group in the UK which is owned by its membership (customers and staff)
Building any sort of standard organization around anything Uber-esque is inherently a short-term deal. Uber could be replaced tomorrow by a peer-to-peer app that needs no server farm, cutting Uber out of the loop completely. And the same holds true for any company that expects it is going to set itself up as a software-mediated middleman. Their only actual 'service' being provided is the servers, and servers are not necessary. (Some credit should be given to them for their marketing, though, as if a p2p app existed today it would face the problem of gaining widespread acknowledgement... although I imagine all the Uber drivers who would say 'hey, book through peerDrive next time and it'll take Ubers cut and let you keep half and let me keep the other half!' and that would unwind Ubers influence in a weekend.
I think Uber has intangible assets and a fortress (it's competitive). It's more like a Coke. It's not a technology company, really. It's a highly competitive logistics company with intangible brand. But I can see how from the prism of hacker news and Silicon Valley it looks like a technology company. The technical part was their at conception but I think its innovation is more a style of business utilising precarious labour that is highly competitive & fierce (for better or for worse). It's like Toyota in its innovation in how to conduct business. For instance, I would say Google is clearly a technology company. But I think Uber has introduced a new style of business and organising labour, as Toyota did. So it's more an industrial innovation.
Why not just let everyone set their own prices and have reputations?
That leads to the right incentive structure!
TaskRabbit and Upwork has that I think.
That leads to the right incentive structure!
TaskRabbit and Upwork has that I think.
Who supplies the capital and what do they get out of it?
The same people that supply most capital: lenders. And they get interest out of it.
Alternatively, you could pre-sell credit at a cheaper price, as a sort of crowdfunding.
Alternatively, you could pre-sell credit at a cheaper price, as a sort of crowdfunding.
In the recent past there had been a burgeoning of startups that wanted to be the uber-for-x, specially in India. HyperTrack was created to address this segment of the market. However, many of these Uber-for-X hyperlocal vendors died a quick death after burning pile loads of investor money.With other startup's providing more end-to-end solutions in terms of route-scheduling and freight packaging(locus.sh) and also the downfall in the number of startups trying to be Uber-for-X, it surely will be interesting to see if HyperTrack's offerings are still relevant.
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.
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.
Thanks for the feedback. I am the HyperTrack founder. The customer you are referring to is still using us and volumes are growing. We pushed out a major re-architecture in March 2017. The release added a key dimension to the accuracy model - activity. Activity is computed based on non-location sensors on the device - accelerometer, gyroscope, compass, pedometer, etc. Please give us another shot with your new employer and tell us what you think.
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.
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.
Shameless plug: I'm one of the founders of TalkJS, which is essentially the HyperTrack of messaging.
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
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
Oh wow, HN changed! A few years ago, posts like this were frequent and well appreciated. Are my downvotes just some lone angry people or am I losing a sense of the community rules?
i don't think i'm lonely or angry. i'm just not super fond of irrelevance or self promotion. so using one as a platform for the other kind of rubs me the wrong way.
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.
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.
I see your point, and I very much appreciate your candor.
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.
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.
Hey Egbert, found your post useful. I have worked with the good folks at Stripe Connect as an early user (Pay with OpenTable). The Uber-for-X in a day package makes a ton of sense. Needs location, messaging, payments, perhaps an order management framework. What could the next steps be to put this together?
Cool! I've sent you a DM on Twitter.
eh. don't worry about me. your vote is positive and so you're doing fine. maybe i am lonely and angry. i didn't want to be critical really. just trying to provide some closure, since you asked...
ps - TalkJS website is awesome. triggers my retro feelies
ps - TalkJS website is awesome. triggers my retro feelies
Huh what? You didn't seem lonely or angry to me ever :-)
ps - Thanks!
ps - Thanks!
I think some people might not like you crowding out hypertrack's show hn post.
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.
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.
Cool! Happy to help. My contact info is in my account, or just use the chat on our homepage. Curious to hear what you think.
This is a great example of using this API.
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.
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.
Agreed. We did open source an example app for service-visit use case (https://github.com/hypertrack/service-visit-example-android) some time ago. To make it even simpler, we developed a walkthrough (https://dashboard.hypertrack.com/onboarding/). Do you think the walkthrough is what's required?
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.
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.
Awesome idea!
I guess they're selling shovels ;)
This comment is slightly OT, but this post prods at something I've been thinking about lately. Pessimistically, most programming is just writing a CRUD app with a layer of business logic over the top. Why haven't we been able to abstract or at least vastly accelerate that? Does anybody have any related reading/longform articles on this idea?
I've been irked by this issue for quite some time.
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.
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.
we have, to some degree. see: parse, firebase, etc. but the reality is most people need more fine grained control than is simple to layer over a crud interface. there's a reason parse shut down: as soon as people's apps had an inkling of success - and often times, even before that - people need to do more than just CRUD
A logistic version would be way more beneficial. Basically an pick up a container and deliver it option.
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.
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.
https://freight.uber.com/
Seems Uber is looking at tapping into the larger logistics market itself
Seems Uber is looking at tapping into the larger logistics market itself
Yea sure is. There is only so much of the world that Uber will capture even as the largest in the space. For everything else, the world would need a way to use a location stack that can compete with the might of Uber, no?
Isn't that what uShip is for? I only know about it from having watched a couple of episodes of Shipping Wars, but seems more or less hassle free, you just post your job and accept a bid.
Didn't know about uShip! It's still not exactly what I mean. This seems a customer to trucker option. I mean more _loads_ of offers to various truckers. uShip seems to be about the goods themselves. I mean just picking up a container. To pick up a container you need a truck capable of doing that, various documentation (incl something that proves you're allowed to pick it up), passport, etc. Cannot just go to a terminal and expect to get a container because someone asked you ;)
Despite that, seems fairly similar. The number of truckers is quite impressive though wonder if those are capable of trucking a container.
Despite that, seems fairly similar. The number of truckers is quite impressive though wonder if those are capable of trucking a container.
I think this is one of the things Convoy does. It's a startup out of Seattle I believe based around that idea. Seems to be doing very well.
Just two months ago was I looking for something like this! https://news.ycombinator.com/item?id=14600873
Would it be possible to move away from HyperTrack at some point, without losing all your customers to HyperTrack?
Iow, do they "control the gates"?
Iow, do they "control the gates"?
Arjun from HyperTrack here. We are building a developer tool that integrates with your in-house stack. Here's how some one can move away from HyperTrack.
- 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?
- 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?
Yes, thanks.
Tried looking at their FAQs link off that page but it doesn't open to any page, static or not static.
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.
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.
Ouch! A recent content reorg led to the trailing html getting nuked. Use this: https://www.hypertrack.com/faq. Fixing it on the blog... Thanks.
Oops, sorry for that! Links are alright now, thanks for pointing it out
Just a hint: https://www.hypertrack.com on iOS Firefox (current version) is just a white page for me.
This is super cool. I've been looking at HyperTrack for the last couple of weeks. I'm curious what other use-cases or features others might imagine with this platform?
Thanks Chris. This is Kashyap, HyperTrack's founder/ceo. Your work with Uber APIs and Trip Experiences was awesome and remains an inspiration. I would love to see an integration between HyperTrack and Trip Experiences.
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?
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?