It's a thing in second world countries too. There are small communities that don't get package delivery, so they ship packages to the capital city and then pay someone to drive packages to their community once a week or so. I've heard of people paying $50 a package in places with pretty low incomes.
1) Incentivize people on one side to join without the other side. For example Uber paid early drivers money just for signing up even though they had no riders.
2) You provide one side of the marketplace to kickstart the other side. This would be like Uber hiring drivers in the beginning.
This is why starting a two sided marketplace often requires significant capital. They're very hard to start organically.
Another thing I'd suggest is to focus on a niche. Don't try to solve the global problem just yet. Maybe you know a lot of people want to transport books between London and Madrid. Just focus on that to get that market healthy, then add another product or location. This helps you focus your marketing. Also if you go global to start you might have 1000 users on both sides but no matches because everyone is too spread out.
Uber also paid riders to ride. I was working for Garret Camp at SumbleUpon and we got free Uber Black back then. The number of available drivers even in SF was so low that it was not really useful, even free!
IIRC Uber employees would jump into taxis and offer them money on the spot to drive for them.
Its priming the pump, I agree there's probably no way around it. Once you get some adoption you can use that experience to go to other cities. Hit social networks often to generate interest organically.
yeah the "cheat" framing makes sense. I've been thinking about option 2, being the supply side myself at the start. Like personally coordinating the first few deliveries to prove it works before asking random travelers to sign up
option 1 is trickier when bootstrapped though. How do you incentivize signups without burning money you dont have? Curious if you've seen that work without VC funding behind it
Without burning money you'll need to be creative. Either do it yourself or go sourcing the supply side. Can you go find a group of people you can use to transport things and basically sign up on the platform on their behalf and then hand stuff off to them? Maybe you know some travel group that exist and you could pay them to take packages. You're basically acting in an agency model in the beginning instead of being a true P2P marketplace. It's a common strategy though it does often lead to just becoming an agency because it's more successful than your organic marketplace. This would be like if you called an Uber and Uber calls up a private driving service to pick you up.
The only real example I can think of being bootstrapped is Airbnb, and even that wasn't bootstrapped for long.
Unless you have a good go to market strategy, you might want to try something easier.
At the risk of being overly critical, the cost of shipping packages is pretty low unless you're trying to do same day delivery, in which case Uber already lets you get your package delivered.
Managed services have value. It's less to set up, less to maintain, and less worrying about waking up at 3am when something breaks.
I've spent time eating the costs of things like DigitalOcean or SaaS products because my time is better spent growing my revenue than reducing infrastructure costs. But at some point, costs can grow large enough that's it's worthwhile to shift focus to reducing infrastructure spend.
I don't want my site to be agent ready. I'd prefer people visit my site so that I can make revenue than have an AI scrape my content and answer the question for someone else.
I've redesigned my site to have enough content so that AI knows what I have but they have to send the user to my site to use an interactive JavaScript widget to get the final answer they need. So far so good, but not sure how long that will work for.
So far I haven't seen crawlers or agents utilize the interactive map widget where the final useful data is located. I'm sure it will happen eventually.
I can tell they're not using it because the page is getting hit by their user agents but my API is not.
If I have to use "interactive map widget" and you weren't the only supplier of the lifesaving thing I'd noped out of there faster than I arrived (and then blacklisted you in kagi to never come back again).
My basic rule is this: Don't use cloud services if you're not big enough to have a dedicated account manager and can get customer service. This means spending like $10k/mo on the big clouds.
I don't use GCP, AWS, etc for these reasons. I had a similar algorithmic flag shutdown a previous startup running on GCP and it destroyed the business.
I do have GMail and GSuite for my current business, but I have everything backed up outside of Google and can switch to a new provider pretty quick by changing my MX records. I could use an alternative but I do like GSuite.
I have an app that is literally just a wrapper around the website. The mobile website and the mobile app are the exact same experience.
Before I built the app, people were constantly asking me to build a mobile app. Yes, I had a PWA but people still wanted an app.
I thought it was kind of silly but I eventually built that wrapper app. It immediately got thousands of downloads, users upgrading to paid plans increased by 10x, and app users have way better metrics that website users.
It's pretty interesting, but as a website owner, having an app is valuable.
It is silly but you have to meet customers where they are.
I think the problem is also that PWAs don't have any discoverability, and no standardization. I did some consulting work for a company that had a PWA. They had a 200-line long react component that was intended to determine what modal to show the user depending on what web browser and OS they were using to instruct them how to install PWA depending on the combination of OS and browser.
This is a lot of friction for the dev, and it's not clear to an average user what a PWA is. But they are familiar with, and for better or worse, trust, the App store. If I didn't know what a PWA and a site said "open menu and click on 'install!'" I'd be very wary of following those instructions!
I think Android and iOS should provide some sort of hook between the app store and PWAs before they really start to catch on.
Yeah, I had a lengthy customer service email template explaining how to install the PWA for when people asked about a mobile app. Almost nobody installed it.
Neat! I like this. But I still don't think it solves the problem of a random website saying "install me!" without the "secure" middleman of an App store.
I actually don't know what you mean by PWA. Is that a mobile web site? And by installing it, do you mean installing a link to it on a phone's launcher?
That, but with a little more ceremony. It gets treated as a separate app by mobile OS app switchers and doesn't show the browser's chrome or other open tabs.
Haha. Not sure if this was intentional but this is exactly my point! If someone on HN doesn't know what a PWA is, what chance does the average user have?
Besides users being more familiar with apps in the past, PWAs are still kneecapped in some subtle ways to make them want apps. I wish PWAs were the norm, so much easier.
From what I gathered with my imperfect data, almost nobody was using the app as a PWA even with an in-app nudge for it. I instantly got lots of downloads when I released iOS and Android apps. My users just don't want PWAs for the most part it seems.
That's typical. I think it's mainly familiarity, which in turn comes from PWAs missing basic capabilities in the past or present so everyone made apps instead. Push notifications in PWAs is a recent thing. PWAs don't share cookies with browsers, which entirely breaks some auth flows like Firebase. It's still hard to tell users to install it as you mentioned. And PWAs didn't even exist at some point.
The other thing is, many websites have bad or broken PWAs. It's usually just the website without tabs or back arrow, which sometimes makes navigation awkward because they built it assuming a browser. I'll always use the browser over the PWA.
Ugh, I run a B2B SaaS app that's mobile friendly, but people keep asking for an app (and I really do need push notifications, I'm spending thousands per month on text messages right now), but I've been putting it off. Did the App Stores have issues with you publishing just a simple RN wrapper app?
No issues at all. I have two tabs in the RN app. One tab is basically the entire app, which is just an embedded web view. The other tab is a basic account tab (sign in, log out, delete account, cancel plan). I also have native auth and native payments.
I'm not 100% sure yet, but I might regret using React-Native over Capacitor. I have to bridge things like auth and payments between the web view and the native app. For example, the web app has a flow where you need to login, so it opens the login modal. If you're inside the mobile app, instead of doing that, it sends a message up to the native app to open the native app's login modal. Then once login is complete, the native app sends a message into the webview with the auth token. Similar thing for payments. That all works great, but occasionally I want to make a breaking change. Since it takes many weeks to get an update rolled out everyone, I have to keep the webapp backwards compatible for a long time. That slows down iterating on stuff like AB testing checkout flows. I don't think I'd have to worry about this if I was using Capacitor because the native functionality would be mostly driven from the webapp code.
It could be that your app is amazingly well done. But most PWAs and web apps turned into an "app" are not meeting my quality standards. It's usually a clunky experience (well, like a browser).
I think once you've seen the actual possibilities of what e.g. an iOS app can do, when done correctly, everything changes for you.
My mobile app is pretty decent actually. Other than some stylistic differences, I can't tell where the native wrapper ends and then embedded view starts. The embedded view is a SPA though so it never does full page loads.
There's usually some random mandatory updates I have to do about 1-2 times a year, so you need updates even with no development.
My React-Native wrapper app handles native auth and native payments, so I occasionally need to tweak that, but it's rare.
I'm considering a rewrite in Capacitor so I can change those things without modifying the mobile app. It's not that releasing the mobile app is a big deal, but it's that it can take many weeks for users to update the mobile app, so I have to keep the website backwards compatible with the old mobile app. It makes testing new checkout flows and stuff more difficult.
Its a monthly/annual subscription. They can pay on the website or via native payments in the mobile app. The subscription works no matter where you bought it.
Fwiw, I stopped using ChatGPT and went to a competitor because the checks slow down ChatGPT so much that the webapp becomes unusable in anything but a new short chat. CPU usage goes to 100%, you can't type, the entire tab freezes, etc. It's a miserable experience to use and I'm on a relatively new MacBook not some old computer. If you read around it's a very common problem people have been having for a while now.
Looking back, how do you feel about your slate of past projects?
I'm curious as TinyPilot is your most successful project and it looks like the most business-oriented thing you built: as in, its a product aimed at serious businesses. Whereas Zestful is a niche micro-saas and Is It Keto is a niche website. Perhaps I'm characterizing things wrong, but that's my rough perception.
>Looking back, how do you feel about your slate of past projects?
I feel like I learned something valuable from all of them.
The ones I'm most proud of are TinyPilot, my book, and my blogging course (in that order). Those are, uncoincidentally, the ones where I found product-market fit, whereas the rest never really achieved that.
TinyPilot was business-oriented by mistake. When I initially made it, I thought the market was entirely hobbyists who would rather make a DIY KVM than buy a $600 enterprise-y device. As I continued working on it, I found that my customers were much more interested in paying a higher price for a pre-made device than saving money with a DIY solution.
But yeah, I think the fact that it appealed to businesses made it more viable than my other business attempts that were consumer-focused.
>> I found that my customers were much more interested in paying a higher price for a pre-made device than saving money with a DIY solution
This could have been a 50-yr-old comment about the Apple I computer! Lol
>> Wozniak intended to share schematics of the machine for free; however, Jobs advised him to start a business together and sell bare printed circuit boards (PCBs) for the computer, without any components soldered on.
...
Terrell told Jobs that he would order 50 units of the Apple I and pay $500 each on delivery, but only if they came fully assembled – he was not interested in buying bare printed circuit boards with no components.
How odd. I googled their name and a few sentences from their post. They post stuff in a few other places too. They appear to be some sort of electronics installer from China. I don't see a single promotional link anywhere but it's all the same content for months, obviously written by AI. Must be some bad attempt at marketing.
reply