Sometime in 2011 (or thereabouts) I was working in a marketing role for a small startup. I had already started to realize that the position wasn't working for me (although I still learned a ton), and was working on improving my technical chops so I could start looking for web development roles. A colleague of mine noted my interest and began coaching me through programming concepts, design patterns, new tools, and otherwise answering my questions when I got stuck. Up to that point I was well-versed in HTML and CSS, and had played around with ActionScript/Flash, but didn't really know what to investigate next. As I was mentored through JavaScript and the web dev toolchain, I was able to contribute to our company's codebase and ultimately joined the engineering team.
In the course of that journey, I was introduced to Python- a language which held particular appeal to the English Lit major in me for its philosophy that code should be readable by humans. It enforces this by codifying a white spacing standard and encourages the use of natural language statements. That isn't to say Python doesn't have its weaknesses (e.g. Unicode/string types in Python 2, lack of support for popular libraries in Python 3, etc.) and I still learn more about it all the time, but after many years with it, I feel comfortable saying that it suits me well.
Armed with "just enough knowledge to be dangerous" I began spending every moment of my free time assembling my first Python web app - a Steam account data aggregator for folks interested in what their digital libraries looked like. While other web apps like this existed, they didn't quite meet my needs, and lacked a lot of information that Steam's APIs did not provide (namely, install size). What I didn't appreciate at the time was that I was really building 3 apps - one to control the traffic and display of the website, one as a backend API that unified Steam's API data with my own, and a web scraper which populated a dataset with information pulled from the Steam store pages that wasn't available any other way (I've written a more in-depth overview of how Steam Gauge is put together, as well.)
On April 1, 2013 Steam Gauge went live (the risks of launching anything on the Internet on April Fool's day were not lost on me). I posted some links to the site with modest expectations. As a tool I designed for myself, a labour of love, and a way for me to showcase my new skills, I expected an audience of at least one. What I got was so much more; sudden and massive interest. The project made it to the front page of Hacker News for the day and Tech Crunch subsequently picked it up, which increased traffic even more.
I watched in disbelief as Google Analytics reported hundreds of concurrent connections consistently accessing the site throughout the day. I expected the site to go down immediately, as it was living on a shared hosting service, but it performed great, with few outages. I got a ton of feedback, and spent most of the day fixing small issues or inaccuracies in the data.
Even more pleasantly, traffic to the site continued to be strong even after the initial surge on launch day. I've had mixed feelings on this; I feel so great that something I built is useful to so many people, but I also feel guilty when I'm not spending time on it. In the years since Steam Gauge launched, I've maintained a full-time engineering job, freelance work, and other passion projects too; the lessening availability of my time has become something of which I'm acutely aware. Still, I've given Steam Gauge some of that time; it has undergone several revisions and is now an open-source project. Despite many code refactors, there's still plenty in there that I find to be embarrassingly naive, but it works, and that has to count for something.
Steam Gauge doesn't generate any revenue. I get asked about that a lot. More people than I can remember have suggested I sell ad space. I did dabble a little with Google AdSense for a month or so a few years back, but the funds generated from that endeavor didn't feel significant enough to justify the negative impact to the site experience. Because the site doesn't make any money, however, I also don't feel that I can justify the added cost of a dedicated hosting plan. I once attempted a migration to Amazon Web Services, but found it unnecessarily cumbersome (which resulted in unexpected charges) and geared more toward enterprise customers. Because of this, Steam Gauge does occasionally suffer short outages when the server resources are capped out - a reasonable trade-off, I think (and one that can always be fixed easily if I change my mind about throwing money at it).
In the four years since its launch, Steam Gauge has undergone database upgrades, Python version migrations, server changes, open-sourcing, design updates, and more code refactors than should probably needed for a well-designed web app. Nonetheless, I'm pleased to say Steam Gauge is still has an audience, and will slowly and steadily continue to get new incremental features (and bugs, I'm sure) for the foreseeable future.