How do I get from a very bootstrapped pet project to something a thousand people can use? Are there any resources/books that could offer guidance on this process?
Technically, getting something that's polished enough that other people can use it is a higher bar than having something that works for you. In particular, you need to think about:
- Error handling (i.e., non-happy path flows). Your users won't be able to see your logs / error reporting emails, so their experience is different to your own one.
- UI. Your users won't know how they're meant to use your product, because they didn't build it. They'll have a much harder time figuring out how to use it than you do.
- Robustness (i.e., bugs). Once you have lots of people using your product, they're going to start surfacing lots of bugs you didn't know existed. They're also going to start using the product in ways that you yourself don't. You'll need a robust test suite to ensure you don't have to load all of the additional context into your head each/every time you make changes.
Beyond that, getting 1,000 people to use your thing is going to need some thinking about distribution:
- You almost certainly want to start with "sales". Even if you're giving your thing away for free. You'll learn more, faster by contacting people individually and trying to persuade them to use your thing. You'll also see a more predictable growth in users, and save yourself from getting depressed about botched launches / blog posts that no-one reads.
- Later, you need a growth engine just like any business.
There are lots of great interviews on IndieHackers (https://www.indiehackers.com/businesses) that might help with the above. My own personal experience is from building Dependabot (there's an interview on there from me!).
There are ways you could simulate a lot of users at once, if you're worried about it.
For running multiple processes, I use gunicorn with an nginx proxy. Requires little to no additional code added to your application.
I use pytest with parametrize: https://docs.pytest.org/en/latest/parametrize.html
Then responses for mocking network stuff from requests: https://github.com/getsentry/responses
Using fixtures and writing your own factory objects to simulate scenarios: https://docs.pytest.org/en/latest/fixture.html. Fixtures in pytest are like setup/teardown.
I keep the code live in production, and have sentry errors email me if someone hits a snag.
Decouple generic code into separate git repositories. Split up billing / generic django / ux stuff so you don't need to repeat it with every website.
I maintain a changelog https://devel.tech/site/updates. Helps to stay motivated while you build out your own IP.
At work, when a project flops, the code tends to go to waste. When you write your own code, unencumbered by any outside agreements/conflicts, it stays with you to reuse, improve, license to others, turn into a SAAS, use in a separate website, etc.
