If you're interested in this area, Lean Startup (book or general resources from that area) might be helpful. One example from the [Wikipedia Page](https://en.wikipedia.org/wiki/Lean_startup):
> As an example, Ries noted that Zappos founder Nick Swinmurn wanted to test the hypothesis that customers were ready and willing to buy shoes online. Instead of building a website and a large database of footwear, Swinmurn approached local shoe stores, took pictures of their inventory, posted the pictures online, bought the shoes from the stores at full price after he'd made a sale, and then shipped them directly to customers. Swinmurn deduced that customer demand was present, and Zappos would eventually grow into a billion dollar business based on the model of selling shoes online.
We also definitely did it in the early days of my non-profit — we wanted to build a very optimized public records submission platform that handled mail, fax, etc., but in our early days I literally hand delivered records requests, which was super helpful from learning but at $2 per request was a huge money-not-maker.
Where I live onselling is illegal, but it is still a pretty common practice for small online retailers to just not stock some items and go buy them at retail when it's ordered. It makes a little bit of sense, since it lets you expand your catalogue without keeping stock on hand or negotiating a supplier. For a small ecomm store, that can mean the difference between looking like a legitimate retailer a customer can trust or not.
This is different to the practice of buying up stock on sale and reselling on marketplaces.
> We also definitely did it in the early days of my non-profit
We are in Phase One testing of our NPO flagship.
It has been designed as a native Swift iOS-only app (but the backend will feed anything).
It also has a few design "tricks" that probably won't scale to millions, but has been tested with tens of thousands (of fake users). They make it lightning fast, and it will be a sad day, if I have to sideline them, in the future.
We sign up users manually, one at a time. I'm developing a dashboard, to lubricate that process, but it will still be manual.
Fortunately (for us, but many for-profits would hate it), I think it will be a long time, before we get to the point where matters of scale become an issue. We Serve a small, demanding, demographic.
Also, we don't collect PID. Extreme privacy and security are a big part of our model. I deliberately avoid a lot of the dependencies that could introduce issues.
> [EDIT] Heh. I find it absolutely fascinating that this post, describing our own small, non-threatening, NPO app, has already earned a ding.
There's a barrier to being able to downvote, but the only downvotes I actually see on HN seem like they're given in bad faith. I'd love an option to turn off displaying downvoting at all since it's never useful to me; from my perspective random comments just fade off a page, usually in the middle of a thread.
If I had to guess, you're being dinged because this is your only contribution to the conversation about doing things that don't scale is: "We sign up users manually, one at a time."
Actually, I suspect it might be because the original version mentioned that the way we do things was not going to be popular with profit-seekers. Its tone was a bit petty, and I removed it.
Otherwise, it is absolutely relevant to the topic at hand. I described:
1) Native iOS-only (not something that will necessarily scale. A large part of our demographic uses Android, and I am regretful that we don't Serve them, but I don't write Android, and don't want to use a hybrid system or PWA)
2) Uses "tricks" to improve performance (I mention these may not scale into the millions. An example is loading a fast list of minimal info on all the users on the system, so we don't have to do realtime searches)
3) We do sign up users manually (BTW: lots of other posts, here, say pretty much exactly the same thing).
But it could also be because I mention that we don't collect PID, and that I eschew dependencies. These postures don't play so well, in today's tech industry. Dependencies are how to scale, but they can also add risk; sometimes, big risk. If we screw up our data, it could put people's lives, careers, and families, in actual, physical danger, so we're kinda anal about that.
But our app will be great. It absolutely Serves its users well, and we're already getting a great deal of positive feedback (We've only been testing since Monday). My main concern is that we may have to scale sooner than I expected.
I won't announce it here, as the very last thing it needs, is thousands of curious geeks, registering one-time-use throwaway accounts. Like I said, each signup is vetted manually, by, like, two of us.
If you are truly interested in what it will be for, feel free to get to me, offline.
As someone who really appreciates the lessons learned in Lean Startup, kinda breaks my heart to know Ries had a heavy hand in the creation of R E S I S T bot. Hard to appreciate the art once you know the artist.
> As an example, Ries noted that Zappos founder Nick Swinmurn wanted to test the hypothesis that customers were ready and willing to buy shoes online. Instead of building a website and a large database of footwear, Swinmurn approached local shoe stores, took pictures of their inventory, posted the pictures online, bought the shoes from the stores at full price after he'd made a sale, and then shipped them directly to customers. Swinmurn deduced that customer demand was present, and Zappos would eventually grow into a billion dollar business based on the model of selling shoes online.
It also is very common for "AI" startups to have the AI just be manual work, though this can be controversial: https://www.404media.co/kaedim-ai-startup-2d-to-3d-used-chea...
We also definitely did it in the early days of my non-profit — we wanted to build a very optimized public records submission platform that handled mail, fax, etc., but in our early days I literally hand delivered records requests, which was super helpful from learning but at $2 per request was a huge money-not-maker.