Ask HN: How to upgrade small pet project and make it commercial-grade?

6 points by meatbundragon 8 years ago | 6 comments

git-pull 8 years ago |

For bulletproofing, I do tests + mock network calls.

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.

meatbundragon 8 years ago |

OP here. To add context to this question, I have a small project in Flask that I made for myself, but it's not multi-threaded, there isn't comprehensive testing suite, etc.

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?

greysteil 8 years ago | |

It's tough, but really rewarding.

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

ioddly 8 years ago | |

Do not assume that you necessarily need to make things much more complex in order to scale to a thousand users. I have several client projects running on flask + sqlite.

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.

llccbb 8 years ago | | |

Have you had any success or failures with the single-threadedness of sqlite and multiple simultaneous users? Does buffering interactions using gunicorn help solve this? I ask because I love using sqlite for some localhost programs but always transfer away to postgres once I push the app to a server/VM. Thankfully sqlalchemy makes the transition possible with just a config change and no real retooling of the codebase.