> 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.
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.