Hyperscaling with Bill Richards πŸ¦… ================================= by kirupa | Interviews with Creative People: https://www.kirupa.com/podcast/index.htm Bill Richards (https://twitter.com/lostincode) tells the MixPod story as both a scaling lesson and a product lesson. The memorable part is not just the traffic. It is how a tiny team combined Flash-era creativity, low-friction growth mechanics, SEO, constant experimentation, and just enough infrastructure to keep a very popular service standing. Watch the interview: https://www.youtube.com/watch?v=LsTyKeJyg-Y A conversation with Bill Richards | 56m ABOUT THIS CONVERSATION This conversation starts in the Flash era, which is exactly where it should. Bill Richards came up through design-heavy web communities, learned by making things, and found the wave that MixPod could ride: highly customizable music players for profile-driven social platforms. That origin matters because MixPod was never only an engineering challenge. It was a product that fit a very specific internet moment, when people wanted their pages to feel personal, musical, and a little loud in the best possible way. What follows is a great case study in leverage. Bill describes how distribution was built into the product itself, from linkbacks that turned every embed into discovery, to signup flows that lived inside the player instead of forcing people through a clumsy off-site funnel. He and his co-founder kept testing adjacent ideas too, including photo tools and other customizable widgets, then cut what was not working. The result was growth that came from product design, UX, search visibility, and timing all reinforcing one another instead of acting as separate departments. The technical side is just as vivid. MixPod outgrew shared hosting fast, moved through dedicated servers, and forced Bill to learn caching, databases, and performance tuning while also fighting spam, abuse, outages, and the general chaos of running a tiny company with millions of users. He talks openly about dropping out of school, handling the end of the Flash era, pushing into mobile, and eventually winding the service down with as much care for users as he could manage. It is a grounded reminder that hyperscaling is rarely clean. It is a pile of good calls, a lot of sleep loss, and the willingness to keep learning in public. WHAT YOU'LL HEAR ABOUT - Product fit and timing mattered as much as raw infrastructure work. - Embedding distribution inside the product can change growth dramatically. - Removing friction at the point of use often beats sending people through a separate funnel. - Small teams can survive surprising scale by fixing the most painful bottleneck next. - Experiments that fail quickly still teach you where the real value lives. - A graceful shutdown includes giving users a way to take their data with them. JUMP TO A TOPIC - 0:00 - A Flash-era starting point: Bill introduces his current work and looks back at the design-heavy web communities that shaped his early career. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=0s) - 3:00 - Finding the web building scene: He talks about discovering Flash, online forums, and the maker culture that pushed him toward building products. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=180s) - 7:00 - How MixPod found its moment: The story shifts to customizable music players, Myspace culture, and the product decisions that made MixPod take off. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=420s) - 11:00 - Scaling past shared hosting: Bill walks through the first big technical hurdles, from server crashes to caching and database tuning. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=660s) - 15:00 - Signup inside the widget: He explains the growth upside of letting users discover and join the service without leaving the player. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=900s) - 19:00 - SEO, embeds, and distribution: The team turns embeds and linkbacks into a powerful discovery engine across social platforms and personal sites. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1140s) - 31:00 - Life inside a two-person company: Bill describes the on-call reality of handling product work, infrastructure fires, spam, and nonstop iteration with a tiny team. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1860s) - 39:00 - When the platform shifted: The conversation moves to the decline of Flash, the mobile pivot, and the tougher business choices that followed. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2340s) - 43:00 - Shutting down with care: Bill shares what it was like to wind MixPod down and why giving users an export path still mattered. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2580s) - 51:00 - What hyperscaling taught him: The closing stretch turns those years of trial and error into broader lessons about judgment, mentoring, and experience. (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3060s) TO LEARN MORE - Bill's Twitter: https://twitter.com/lostincode TRANSCRIPT The automatically generated captions have been organized by speaker, lightly edited for clarity, and broken into paragraphs for readability. Names and wording may still contain errors. 0:00 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=0s) Building a successful product that ends up having 25 million users doesn't just happen. It takes a great idea, the right people, and a can-do attitude toward all the technical, business, design, and operational ups and downs that come with running a company. To go deeper into that, I'm talking with Bill Richards today. Bill, before we get too far into the conversation, can you please introduce yourself for the audience? 0:30 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=30s) Sure. My name is Bill Richards. I'm the CTO of Jog. 0:38 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=38s) And so what does Jog do, just for curiosity? 0:40 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=40s) Just for curiosity, yeah β€” we help brands with video. A good way to sum it up is that Jog is a video-vetting platform, and we work specifically with big brands like Sony and Disney on video screenings. Before we started working with them, they were using text-survey feedback for screenings. We handle video instead, so we can capture the excitement in the video itself and help deliver that back to brands while also handling the rights management side. 1:11 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=71s) Cool. Before we started recording, we were talking about video and the challenges that go into making it work really well, so I want to come back to that in a little bit. But first, because I've known you for a long time as a programmer who writes code and is really comfortable with code, I'm curious how you got started. What was the first thing you wrote, what was your language of choice back then, and what was the beginning of Bill's life as both a programmer and an entrepreneur? 1:41 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=101s) Yeah, actually, and I think you'll get a kick out of this: Flash is what really inspired me. Your site, as I told you before, played a huge role in my curiosity and my learning because it was such a great resource. You were such a great teacher. More than anything, building things in general is what kept me going and what got me started. I wanted to make something, so I knew programming was the way to do that. What kept my interest going, even back then, was seeing sites like 2Advanced and Billy Bussey's work. He used to do these really cool 3D Flash sites that would explode and rotate and do the full 360. Stuff like that completely fascinated me. I just kept thinking, I want to do that. I want to learn how to do that. I didn't know how I was going to do it, but that became the motivation. So when I got started, Flash was a huge part of it, and my first language was ActionScript 2, which definitely wasn't the world's greatest language. We can also happily skip over ActionScript 3 for a second. But that's where I got my start. My first real programming experience was basically just playing around inside Flash. It's funny you mentioned ActionScript 2, because in a lot of ways I still feel like JavaScript today fills a similar role. And if you look at TypeScript, maybe that's a little closer to the ActionScript 3 side of things. But in general, a lot of the ideas from ActionScript 2 really did live on through the JavaScript world. 3:17 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=197s) So Billy Bussey and 2Advanced β€” what got you to those sites in the first place? I'm guessing this was a long time ago, and unless you were already interested in design, you probably wouldn't just stumble into them casually. It's not like your friends at school were saying, 'Hey Bill, go check out Billy Bussey or 2Advanced.' So how did you discover them? 3:36 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=216s) Yeah. Circling back to my fascination with Flash, I found your site and spent a ton of time there. You had this wonderful forum with an amazing community of designers and developers. People were friendly, people were making cool things, and there were fun activities like Photoshop tennis. Forums were the online place to hang out back then, so I spent a lot of time there. I can't pinpoint the exact moment, but that's probably where it happened. I learned about those sites just by being on your site, being active in the community, and probably seeing a post or a link somewhere. We didn't have the social media ecosystem we have today, so I want to say forums were most likely where I discovered them. 4:23 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=263s) Yep. We had AOL Instant Messenger, MSN Messenger, and things like ICQ back then. You'd get a little notification in the bottom-right corner, a tiny panel where you could message people, and that felt like advanced technology at the time. So from there, after Flash and all of that, what did you do next? 4:49 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=289s) Yeah, so back then I was learning Flash by making fun little projects, the kinds of demo-y things you would build from tutorials. I remember the snow tutorials you did and stuff like that. I was really fascinated by it. At the same time, Myspace was huge, and the cool thing to do back then was customize your profile. I had a friend in California while I was living in Michigan. We played Counter-Strike together a lot, and she was also into programming and design. I met her through Myspace, and we both had customized profiles. I think that was another big gateway for a lot of people in that era, because learning CSS was closely tied to making your profile feel like your own. We noticed pretty early that Myspace had these boring built-in music players, and everyone wanted to express themselves and personalize their page. So with what I had learned from your site, I made my own little custom Flash player and put it on my page. People kept asking how I did it and whether they could use it too. My friend and I were playing Counter-Strike one day and basically said, what if we just made a site for this? That's how MixPod was born. We put together a quick little MVP β€” really just a one-page site where you could customize a music player and add it to your profile β€” and that turned into a business we ran for six years. MixPod ended up becoming wildly popular. 6:35 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=395s) When did you know that what you were building was going to turn into something you'd spend six years on? 6:42 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=402s) Yeah, so in the early days, I didn't know for sure. People were asking me about it, and I thought, why don't I just put up a site? I was also interested in web design, web development, and that kind of stuff. If you remember Slide and RockYou, they had Flash photo viewers back then that you could customize. You could have photos flying around, upload your own photos, and do things like that. We started with one music player, but we also thought the photo features that Slide and RockYou were doing were the popular thing to chase. They got all this funding and became such big companies, so we pursued that direction for a while. Then we realized that competing with companies with huge funding and resources just wasn't going to work, so we ended up dropping that part. On the music side, we got pretty lucky early on. Shady Records, Eminem, and 50 Cent all hired people to customize their Myspace profiles, and they used our music players on those sites. Thankfully, we were smart enough to put a link in the Flash player that wasn't easy to hide or remove. You could probably mess with the embed code and shorten it, but they kept the link prominently displayed. We got a ton of traffic from that, and it really took off from there. 8:10 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=490s) For that link that appeared under the player, was there ever an option where people could pay to remove it, or did you always keep it visible? 8:16 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=496s) Visible. It was always visible. The site was free, and we never really considered a paid removal option because payments were such a hassle back then. We didn't have Stripe or modern tools like that. It was the kind of thing where you'd have to call a bank like Chase and set up payment processing manually. So we kept it free and ran it as an ad-supported site. That's really how we sustained the business in those days. 8:42 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=522s) And when you say ad-supported, do you mean there was a banner in the music player itself, or were you monetizing indirectly through the site? 8:53 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=533s) Yeah, we only put ads on the site, never in the player itself. We kept the player clean. Most of the revenue was from Google AdSense, and we also had some affiliate revenue because, being in the music space, we partnered with Thumbplay, which did ringtones back then. So yes, I'm definitely dating myself there. Ringtones were a real business, and we had a way for people to search for ringtones and we'd get an affiliate cut from that. 9:21 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=561s) So your monetization was advertising. What percentage came from advertising, and what percentage came from other sources? 9:29 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=569s) It was pretty much all advertising-supported. But as we built out the site, we also realized there was an opportunity to build a community around music itself. So we added profiles, custom forms, and more of a destination experience. You could have your own mixpod. Com page, show off your custom players, and make it feel like your own space. So the original idea of customizing music players expanded into more of a music and profile community around that core behavior. 9:59 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=599s) And the impressive thing is, I think you mentioned that at the peak you had 25 million members using the service. That's a mind-boggling number even today, especially when you think about the state of the internet back then, before mobile devices were doing so much of this work. What was your tech stack like? How did you even build something like this? Because kirupa. Com was never that popular β€” at its peak it had maybe 200,000 active members β€” and the servers would still go down because they couldn't handle the load. It was PHP and MySQL, and I'm curious how you ended up building MixPod. 10:38 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=638s) I kind of just winged it the whole time. I learned Flash, and I learned enough PHP to get by. PHP gets a bad rap, but it was pretty much standard on all hosting, especially back then, so it was an easy way to get started. The code definitely wasn't clean. We just threw something together, it worked, and it got the job done. Believe it or not, it scaled pretty well. My biggest education was learning how to manage it, because we also had a lot of downtime. We started on GoDaddy shared servers and quickly got an email saying we were using too many resources and had to get off their system. They basically booted us, so we had to figure out what came next. We rented dedicated servers, and then those started crashing. On our most popular run, I think we had well over a million members join in a month. It was a constant battle, and I lost a lot of sleep. I learned about Nginx, caching, Memcache, making sites faster, and scaling a database. At the peak, I think we had six servers: a master database, two read databases to distribute the load, and a couple of web servers with a load balancer between them. I figured a lot of that out on the fly. Friends from the forums helped, and the scale was incredible. We had hundreds of millions of playlists and hundreds of millions of songs on those playlists. I hired Percona, who were database experts and are still in business today. They were really helpful. They set up an ideal arrangement that I could manage, and they taught me what they had done. I took it one problem at a time, putting out fire after fire until we reached a stable point. Then the next thing arose, and I had to learn how to fix that. In retrospect, one nice thing about that era was that we didn't have today's services and platforms that autoscale traffic and handle those things for you. It was also pre-framework, so I had to optimize queries and learn about indexes, databases, and everything under the hood. Putting out those fires for six years was a really great learning experience, and it helped me get where I am today. 13:21 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=801s) Was it still just you and your friend, plus Percona helping with the database, or did you have a broader team at that point? 13:26 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=806s) It was just me and my friend for six years. We never really needed to grow the team because we were able to manage it. Once we got the platform stable, it became a matter of building cool stuff. We kept adding new players. A big motivation for me in the early days was Winamp, with all its customized skins and visualizations. We ended up with a couple dozen customizable players, multiple colors for each one, and I think around 12 to 15 different skins you could choose from. My ultimate vision was to have a developer kit. I never got there back then, but my dream was to create a new, modern version of Winamp. Another thing Flash really helped with was letting us build mini-applications inside those little widgets. We also used YouTube for videos, so we had customizable video players. While you were watching something, you could click a little plus button. The widget would ask you to log in or sign up from inside the widget itself. That meant that anywhere somebody took our code and embedded it, whether on Myspace, a blog, or somewhere else, a visitor could sign up inside the widget. You didn't need to go to our site. You could interact with the widget, make an account, set up your player, and get the code from inside somebody else's widget. It was like a mini-platform: the more widgets we had across the web, the more signup opportunities we had. That was a major part of how the product went viral and how our audience kept growing without requiring people to visit our homepage first. 15:05 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=905s) You're making it sound trivial, like, β€œOh yeah, I just put the signup form in the middle and made it work.” But there are really two parts to this. One is the technical side, which Flash definitely made more obvious. The other is the user-experience side, because many people wouldn't have made the jump you did and decided to build the login directly inside the widget. Conventional thinking today would probably favor a templatized approach: the widget is a top-of-funnel activity that sends people to your website, because that's where the main content lives. You deliberately chose something that runs counter to what conventional wisdom says you should do. It was clearly the right choice and very successful for you. What made you decide on that path? I'm pretty sure that if you had read the conventional books at the time about how to scale and grow, putting the login inside the widget would have been the exact opposite of their top recommendations. 15:58 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=958s) Yeah, that's a really interesting question. It mostly came down to asking what the best experience for the user would be. Obviously, because we were ad-supported, I did want people to come to the site eventually. But I didn't want to force them to do it if the cooler, smoother experience was to let them act right there inside the player. If you were interacting with a customized player and thought, hey, I want one of those, it felt magical that you could click around, sign up from within the widget, and get the code to put it on your own blog. When people signed up, we'd still send them a welcome email, so that was one way of bringing them back to the main site later. But the onboarding itself felt better when it happened right there in context. It kind of blew my mind that I could embed the onboarding flow inside all of these widgets distributed across the web. It just felt like the right thing to do, so we did it that way. 16:48 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1008s) Was there any A/B testing, or was it more a case of trying it, shipping it, and iterating based on live feedback? 16:54 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1014s) Everything I've done in my career has basically been winging it and doing what felt right. We didn't do A/B testing back then. We just made some good calls, had good timing with the growth of Myspace, and kept experimenting because the internet was fun and Flash made it fun to build things. A lot of it really was just making an executive decision because it seemed like the right thing to do at the time. 17:25 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1045s) Was Myspace your primary distribution platform? 17:28 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1048s) Yeah, it was definitely the biggest platform for us, and at one point they also cracked down on Flash. My partner was really brilliant, and she also had some clever marketing strategies I'll mention in a second. She actually knew Tom from Myspace β€” the default friend β€” so when that crackdown happened she was able to help get us onto the allow list so we could stay on Myspace. That definitely helped sustain our growth. 17:59 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1079s) Yeah, and you already kind of teed this up for me. Tell me about your marketing plans, because products don't just hit 25 million users automatically. 18:09 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1089s) Obviously, the in-widget registration, was kind of a big thing. And another part of that was also to be able to log in so, like, if you're already a user, you could, just log in and like you're like, oh, that, that video is amazing, I want that on my playlist. You see somebody like, okay, this is a mixpod player, I can just log in, Click the plus, add it to one of my existing playlists. But also, as I mentioned, we had a link under the player. But SEO was such a big driver for us back then so we wanted to target like words like playlists, music player, stuff like that. So early on I figured I'm like we're sending out thousands, in some case tens of thousands per day widgets. When we were at the peak growth, I was like what if we just it's a link back? Right, that was such a big thing back then to get someone to link back to you with a keyword. So I was like why don't we just put a link under that player targeting the keywords we want to target? So we have all these people embedding code on their sites pointing back to us for keywords we want to target. So we would have like a little string at the bottom that said I made this music player or whatever term we wanted at mixpod. Com and, we just got all these link backs and I just kind of waited them by importance and we ended up being like for music player number one, like all these different terms that we wanted to target back then just by doing some simple research on popularity, and that strategy really like rocketed us to the top of Google search results back then. It's obviously much more complex now but back then it was fairly easy to do as long as you had a lot, a lot of people linking to you. 19:41 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1181s) Correct. When people embedded it, was it primarily on Myspace, or could they also put it on their own blogs and other places? 19:47 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1187s) Blogs too, really anywhere. We had specific instructions for pretty much every social network. Friendster was around back then, and I think there was another one called Hi5. There were a lot of social networks. It was kind of the golden age of social networks before Facebook, so whenever we saw one gaining traction, we supported it. When you got the code, there was a little tab where you could choose your specific social network and get specific instructions. Sometimes the embed code had to be altered to work on a particular platform. We ordered those choices by popularity so people could quickly find the instructions they needed. As those social networks matured, they created their own ways of integrating widgets. When Facebook came along, it had a developer platform, so we built a Facebook app. Facebook had a very strict way of doing things. It allowed Flash, but you had to show a picture that people clicked before the player would start, so it didn't play by default. Eventually, as the networks grew, we targeted specific ones such as Facebook and Myspace and built apps directly on their platforms. We kept adapting the player, the code, and the instructions to whatever each popular network required. 21:10 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1270s) That required recognizing both a problem and an opportunity β€” in this case, SEO β€” and then actually being able to implement it. What helped you branch out beyond just design or development and understand all of that? Were you reading about it, following other people doing adjacent work, and then adapting part of what they were doing to your situation? I'm curious about your thought process. 21:42 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1302s) Yeah, honestly, we did a little research and wanted to see how far we could take the thing. It's a very rare opportunity to have something grow that fast and become that big, so we wanted to figure out how to maximize it. We did a lot of research and Googling, but there wasn't a concrete manual for success. You had to play around with things. We also looked at other sites, including RockYou and the other popular photo viewers I mentioned. They had way more resources than we did and were huge, so we studied how they handled things and took inspiration from them. Beyond that, as I said, we winged it and did whatever felt right. I don't think anyone was putting signup flows inside Flash widgets back then. It was a little research, a little trust in your gut, and a lot of trying to find the best path forward. There was no guaranteed playbook, and every choice was an experiment that we had to evaluate ourselves. 22:42 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1362s) Nice. When you mention that, what are some things you tried that didn't fully work out? 22:49 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1369s) Yeah, good question. The video and photo viewers were semi-successful, but they were nothing like the customizable music players. We also experimented with random one-off widgets β€” clocks, scrolling text, little decorative things people wanted on their pages. We kept asking ourselves: what if we took every boring widget idea and made it customizable and expressive the way we had with music? Some of those things worked a little, some of them really didn't, but that was the process. We were always experimenting with how far we could apply customization as the main value. Not everything was successful, but that was the thinking behind it. 23:43 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1423s) That is interesting, because it sounds like you were experimenting to figure out what actually made the product sticky. Was it the audio player itself, or was it the ability to customize whatever you were creating? It seems like it was a little bit of both, but mostly the audio player was the anchor and the customization made it more compelling than the other audio players that existed at the time. 24:07 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1447s) Yep. There were definitely a lot of players in the space, and this was well before Spotify and the modern streaming world. But the ones that were catching fire mostly had a single boring player. That was exactly what we set out to change. Myspace had the music you wanted, but the player looked like everyone else's and you couldn't really make it your own. So yes, I definitely think customization was a huge part of what made MixPod work. 24:35 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1475s) Definitely a big lesson. Going back almost to the beginning, this started because you were an active Myspace user who liked to share, listen to, and discover music through its interface. You found the music player boring, so you and your friend decided to change it. You solved a problem you personally had and then scaled the solution to other people who had the same problem. That's a great approach, especially early in your career when you're younger and have the bandwidth: solve a problem for yourself, then see whether other people have it too. It also gave you extra motivation to figure out what worked, what didn't, and to keep experimenting. You weren't solving a problem for an abstract persona or whatever term people use to describe an audience. You were solving something you experienced personally. That also explains choices such as putting the login inside the widget. The question was really, β€œWould I enjoy using a feature like this?” If you wouldn't enjoy it, your audience probably wouldn't either. Building for yourself can be dangerous, but it works when you truly are the target audience for the final product, which you clearly were in this case. In that situation, your own reaction to each feature became a useful proxy for how the people you were trying to serve might react. 25:53 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1553s) Yeah, I think my lack of experience actually helped me. I was just finishing high school and starting college when I began this crazy thing, and I hadn't worked for a big company. The web was still fairly young, and there weren't a lot of huge sites. If I had waited until later in my career, I probably would have done things differently because I would have been more constrained by the standard way we think things should happen. Being naive, not knowing how things were supposed to work, and thinking from the ground up about the best user experience turned out to be a great lesson early in my career. I still remind myself of it whenever I'm building something. I ask what's best for the user and what would work best here, rather than automatically following the rules. That approach has served me well. It's difficult to pull off, even today, but it's probably still the best way to do things. 26:51 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1611s) Whenever people talk about new technology, for a brief millisecond my brain goes all the way back to dial-up modems and all those older experiences before it finally returns to the present. Some of my mental bandwidth is already spent thinking about what was tried and what failed in the past, which means I have less capacity left to think about what the future could be. In your case, the inexperience actually helped, because someone with more formal experience might have immediately ruled out ideas by saying, 'We've tried that before.' Context matters, but your brain doesn't always process that. It can jump straight to the no. Sometimes being a little naive is what lets you go a bit farther. 27:41 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1661s) Yeah, another subject we could probably talk about for hours is dealing with abuse and spam while growing something that big. I know you've had that challenge with your forums too. Early on, I installed vBulletin, or something like it. As you know, those packages get exploited nonstop. You're constantly updating them, moderating spam, and dealing with abuse. We installed it, and it quickly became a nightmare. I thought, man, this isn't fun. It was automatic signups, exploits, constant moderation, and putting the forum on a separate server so an exploit couldn't reach the main database. I deleted it and thought, I really enjoy programming, so why don't I build my own custom forum? It wasn't as feature-rich, but it eliminated most of the spam and gave me more control. I could require small things before someone became active on the forum: had they made a player, and had they filled out their profile? Those gates made the forum part of the rest of the product and helped prove that someone was a real user. I also liked the challenge of asking whether I could build a forum. I iterated on it little by little, solved one problem and then the next, and used my curiosity and learning to combat spam. In this case, reaching for the standard prebuilt solution wasn't a good solution for us. Building something custom was much easier to manage. That custom approach also meant an exploit in an off-the-shelf forum package couldn't put our main database at risk. It traded built-in features for the control I needed. 29:22 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1762s) I'm curious about that, because forums like vBulletin were pretty extensible, and the same was true for things like phpBB. Why did you decide to build your own instead of using one of those? 29:36 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1776s) I just thought it would be fun. I love building stuff. That was the whole reason I got into this in the first place. Building my own forum gave me more control, more customization, and something that felt easier to manage because I didn't have to dive into someone else's internals. I naively believed I could do it better, and more than anything I wanted to see if I could do it at all. It was another chance to learn, so I took it on and made it happen. 30:09 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1809s) No, that's actually really impressive. I tried and failed at building my own forum, because the first challenge was support and the second challenge was trying to understand how to bootstrap it so it wasn't empty. Those were pretty hard things. So what did you do differently? 30:26 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1826s) Yeah, it was mostly that. I stubbornly pushed through and made a lot of mistakes. The forum wasn't feature-rich, and it was missing many things, but I kept at it. I wanted something basic, so at first I stripped all HTML out of posts and didn't allow formatting. I slowly added features as I figured out how to do them safely, and some packages helped with specific pieces. I took on small tasks whenever I had the bandwidth and kept improving it. I did this for six years, so I iterated slowly until it became good. The interesting part is that you were doing all this while also working on the music player and everything around it. What was your day like? Were most things on autopilot unless something was on fire, giving you the bandwidth to explore and do all these things in parallel? It varied day to day. If there were fires to put out, I dealt with them. It was just me and my partner. She was more of a graphic designer and knew a little CSS, but I had to figure out everything else. I was always on call when a server was on fire. If I wasn't putting out fires, I asked, β€œWhat can I build today, and how can I make this better?” There were also weeks when everything ran smoothly and I wasn't feeling creative, so I took some time off. I think taking a break is important because it lets you come back feeling fresh and motivated. I took it day by day without a strict agenda and stayed passionate about learning and getting better. There were no fixed schedules; creativity and the current emergency decided what I worked on next. 32:13 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1933s) How did you find out what things were on fire? Did you have some kind of service set up to notify you when things broke, or was it mostly people emailing you to say, 'Bill, things are not working?' 32:21 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=1941s) A little bit of both. After we got kicked off GoDaddy, we eventually found a home at a company called SoftLayer. I don't even know if they're still around, but they had monitoring emails. Percona, the same company that helped me optimize the database, also helped set up alarms when server load crossed certain thresholds. I still have the Gmail account I used back then, and I think I almost filled the inbox with alerts. When things were going wrong, I got flooded with email. So I had to look through the messages, figure out what was happening, decide whether I could fix it myself, and decide when I needed outside help. And on top of that, if I made a bad change to the site, I would also get a flood of angry emails from users. So it really was both. I spent a lot of time in email. We didn't do much formal support, but I did reply when people had real problems. The volume was just overwhelming for two people, though β€” thousands of emails a day covering feature requests, complaints, spam reports, and everything else β€” so we had to do our best and figure out what actually mattered most. 33:48 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2028s) Your product was fairly successful. Why didn't you expand beyond the two of you so you could outsource or offload support, email, and some of the operational work? What was your thought process behind keeping it so lean? 34:03 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2043s) Yeah, that's a good question. I think it came down to the fact that we wanted to keep doing it ourselves. A lot of people would probably grow something like that, hire a bigger team, and move on. But we genuinely enjoyed it. We'd play games, work on the site, and treat it like a playground. It was definitely challenging, and some days were a headache, but for the most part it was fun. It felt a little like the role your own site plays for you β€” a place you can go every day, tinker with things, and make changes knowing that millions of people might see them and give feedback on them. That was a big part of why we kept it small. 34:46 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2086s) And at this point, were you still juggling college and MixPod at the same time, or were you already working on MixPod full time? 34:55 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2095s) Yeah, I'm one of those people who dropped out of school because MixPod was growing so fast. I was in a computer science program, and the technology they were teaching felt so far behind what I was actually doing. They were teaching very basic HTML while I was showing up to class and, in some cases, helping the teachers learn newer things. At one point I think we had hit our first million users, and I remember showing that to one of my teachers. She basically said, what are you doing in school? I didn't really have a great answer for that. So I thought hard about it. Obviously your parents don't want you to go down that road because it looks like you're just playing around, but for me school was getting in the way and the product was growing too quickly to ignore. So I made the leap. It was the right decision for me, even though it definitely isn't the right decision for everybody. And here we are more than 20 years later. I'm still doing well and still learning every day. 35:55 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2155s) That is great to hear, because it puts you on a path a little like Steve Jobs or Bill Gates in the sense that it's not completely unheard of, even if it's still a huge leap. I agree that it feels more accepted now to take that kind of risk. Today you can sign up for an incubator or a program that almost encourages you to pause school and chase the opportunity. Back then it was a much wilder leap, so that's a really impressive kind of risk-taking. 36:26 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2186s) Yeah, we actually branched out into a few other products. One that had some success was a site called TubeChop. It had a little Flash interface where you could load any YouTube video and clip out an interesting part. YouTube has that feature now, and I think TubeChop was an inspiration because it was wildly successful. We advertised it a little on our site, but it was simple: you pasted in a YouTube URL and loaded the video. I built a custom trimming interface in Flash so you could choose the section you wanted to share. Back then, YouTube didn't even have the little URL query parameter that starts a video at a certain time. TubeChop became very popular with teachers because they wanted to share particular parts of YouTube videos in the classroom. The funny part is that I didn't actually trim the video. Thanks to Flash, I loaded the full video, sought to the chosen start time, and stopped it with a timer at the clip's end time. The player created the illusion of a trimmed clip. It hid the full length, showed only your trimmed duration, and made the section feel like its own piece of media. It was a little Flash trick. It didn't alter the video or do anything against YouTube's terms of service. It loaded the full video, jumped to the part you wanted, and stopped where you wanted. You could also add a comment explaining why you had trimmed and shared that part. We hosted a page for the clip as well. A little CSS bar showed where the clipped section appeared within the full video's timeline, and there was a link to watch the full video. We definitely experimented with a lot of things. 38:15 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2295s) That's really cool. I was about to ask how you stored the video, and it sounds like the original video stayed on YouTube while the Flash player simply pulled the source from YouTube and gave it a visual treatment that made it feel like a trimmed clip. That's really clever. I can go deeper into how you came up with TubeChop in a little bit, but I want to get back to MixPod for a moment. You had all these social-network integrations, and you also built a Facebook app. Today, for the most part, we think of Facebook as the platform that replaced a lot of the networks you listed. So what happened when Myspace started to decline and Friendster or Orkut and the others started fading? How did you manage that transition? 39:05 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2345s) Yeah, there was a lot going on back then. Steve Jobs famously killed Flash, or at least helped make it irrelevant. I fought that for a while because there was this looming thing I had to learn called Objective-C. It was foreign to me, difficult, and very verbose, and I didn't know C either. I started tinkering with it because I knew I needed to get an iPhone app done. I hired an agency to build version one, and it was successful because I could advertise it on our site. I think we reached the top 20 in the music category. Then I quickly learned that I didn't know much about contracts. The agency delivered the app but didn't give me the code I had paid for, so I couldn't make changes. As a programmer, I found that really annoying. I didn't want to pursue legal action, and I hadn't gotten the code-ownership requirement in writing. I stubbornly decided to learn Objective-C myself because Flash was dying and I knew this was where we needed to take the business. I started and quit several times while continuing to build the site. Eventually, I learned enough to create my own version one and replace the app I had paid the agency to build. The agency-built app had proved there was demand, but its success was difficult to use when I had no source code and couldn't update or support it myself. At the same time, Facebook took over out of the blue. We transitioned by building an app inside the Facebook platform, so I had to learn its ins and outs. Especially early on, Facebook constantly changed the platform and its rules. It felt like a whole new business to run, and it was frustrating to keep adapting. The platform was new and growing, so the changes were expected, but the restrictions were a big hassle. Facebook profiles were boring and corporate compared with Myspace. People liked Facebook because they could discover their friends, but the interface was blue and white. You could add a customized widget, but it didn't have the same vibe or level of personalization as Myspace. We got an initial bump when Facebook became our primary source, but then usage began slowly declining. Facebook got rid of Flash, everyone else got rid of Flash, and that was the beginning of the business's descent. 41:51 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2511s) So if I answer this based on what you just said, was it really the death of Flash that made it difficult to continue MixPod, or was it also that people's preferences changed and even if you had built a great HTML and JavaScript-based player for Facebook, it just wouldn't have gotten the same traction? 42:08 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2528s) Yeah, I think Flash was definitely a big part of it, partly because when Flash went away the work also stopped being fun for me. I loved how expressive Flash was. You could build things, customize them, animate them, and make them feel alive. JavaScript eventually caught up in a lot of ways, but at that moment it really felt like we had taken a step backward. It wasn't as fun. It didn't have the same built-in sense of motion and play. So when we started thinking about shutting the business down, one of the big questions was simply: am I still having fun doing this? Once the answer stopped being an obvious yes, and both of us had other career opportunities starting to appear, it became easier to decide to close it down. 42:54 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2574s) That sounds very reasonable. You didn't build a company in the formal sense with a large team to support. It started with a problem you wanted to solve, and the fun of hacking on it was a huge part of what kept you doing it for six years. Once that motivation faded, it makes sense that the business would wind down too. So let's talk about shutting the service down. That's a complicated thing logistically. Did you have a formal moment where you said, 'We're no longer going to operate,' or did it just gradually decline into maintenance mode first? 43:27 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2607s) Yeah, usage was declining. My partner and I both started pursuing other career opportunities, and we put MixPod into maintenance mode for a while. Other challenges were piling up too. We had grown so large that I think we were a top-10 API partner for YouTube. Then YouTube built tools that let music labels manage their content, and we started getting blocked because we were so successful. I could never get a clear reason from YouTube. I remember being interviewed by Google around that time. They were curious about my site, and I think they had an intern talk to me because they were building Google Wave and were interested in social sites. They asked many questions about how my site worked. Shortly after that, YouTube began blocking us. I don't know whether there was any correlation. Technically, I could have changed the Flash player's URL and gotten unblocked, but I didn't want to play a cat-and-mouse game. We tried contacting the music labels and couldn't get through to them. We were on their radar because we were so big, and I think they didn't like not being in control. It's still a mystery, but these problems made the shutdown decision easier. Thankfully, our separate careers were also flourishing. It ultimately came back to whether the work was still fun. We collectively made the decision, gave a little notice, shut the site down, and put up a note transparently explaining our reasoning. I think we also posted links to follow us on Facebook and Twitter if people wanted to talk about it. The user response ranged from people discussing the decision to people asking how to export their content. I built a quick internal tool that exported all their data. It wasn't self-service, but not many people asked, so we handled requests case by case. I wanted to honor the people who had spent so much time on the site. I kept one instance of the database running so I could create those exports. I think the data was in XML, so many users probably didn't know what to do with it, but at least I gave them their data. Even though only a handful asked, those users had spent years organizing playlists and customizing their content, and I wanted to do right by them. The shutdown wasn't caused by one dramatic issue. Declining use, the YouTube blocks, our inability to reach the labels, changing careers, and the fact that it wasn't fun anymore all pointed in the same direction. The export was not automated, so I ran the internal tool for each person and handled every request case by case. 46:10 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2770s) Right by the users. I was curious what exactly was exported, because I wasn't sure whether you were exporting the actual audio files themselves or just the preferences β€” playlists, titles, and the things people had organized or customized. 46:24 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2784s) Essentially, it was their own data. We never hosted any of the media files. People could use the YouTube API or enter their own media URLs, so I exported those URLs and the structured information around them. Imagine that you made 20 playlists on our site. You might know where the individual URLs came from, but you wouldn't want to remember and rebuild the way you had organized all of them. That organization still had value. We didn't have thousands of people asking for exports when we shut down, but a handful said, β€œOh crap, I want that data. I spent years organizing my perfect playlist.” That's why we exported XML. We also let people customize video playlists by overriding the titles. YouTube titles could be strange or overly driven by SEO, so you could replace them and make them look clean in the player. I wanted people to have a way to preserve the URLs, organized playlists, custom titles, and all the other work they had put into the site. The organization and custom metadata were the content that we could actually return to them. 47:34 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2854s) That's actually really nice that you did that. This was also before GDPR and the more formal legal expectations around data export, where even if only 10 people out of 25 million ever asked for it, the legal requirements would still slow you down today. So now that MixPod is behind you and you chose to end it, how do you feel about all of that? You spent six years of your life on it. 48:10 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=2890s) Yeah, it was definitely bittersweet. It had been a fun thing to do, and for a long time I thought, β€œMan, am I always going to be chasing this success? How do I ever achieve that again?” But I quickly realized that those six years had given me an invaluable education. When I was trying to figure out what came next after MixPod, I joined one of the early coding boot camps. I did it in Seattle while I was living in Florida. I could afford to go there, live there for a month, and fully immerse myself. It was called Code Fellows, which was part of Techstars back then, and they were teaching Ruby on Rails. I was coming from Flash and PHP, so I wanted to learn something I knew nothing about. I wanted to be the biggest idiot in the room. I knew nothing about Ruby, and I decided to spend a month absorbing it. I learned quickly that all those years of grinding through problem after problem had built real muscle. In the early MixPod days, Google resources often weren't good, and I don't think Stack Overflow was available yet. I had to dig through forums, ask questions, and keep trying until something worked. That had become my natural approach. The six years weren't clean or easy, but every outage and unknown forced me to keep learning until the system worked. That habit mattered more than entering the boot camp already knowing the syntax. Even though I didn't know these programming languages, they were easy for me to pick up because my muscle memory was to figure things out. There was no other option. I took to Ruby on Rails very easily, and I loved how it was set up. Then I found Laravel, a PHP framework using many of the same concepts. It even had built-in queue support, and I already knew PHP, so it felt comfortable. Taylor, who created the framework, emphasizes developer happiness. I felt very productive there and found a home, while also continuing my iOS development. I took a job as an iOS developer at an agency in Los Angeles. We made some cool apps for big companies such as Red Bull and projects such as Fox ADHD, a really cool animation show. I learned about GIFs and putting together iOS apps. At that agency, I discovered that I knew much more than I thought. I had never formally worked at a company, so I positioned myself as a junior developer and assumed I knew less than people with formal training. Once I started the job, I realized I knew a lot and was quickly pushed into a lead role. Looking back, MixPod was invaluable experience. It sucks that I couldn't turn it into a sustainable business that still exists today, but I learned so much. I loved the experience, and it made me who I am today. I had gained production experience, persistence, and the ability to solve real problems even though none of it came from a conventional company role. The practical experience turned out to be as valuable as formal training. Instead of recreating the same success, I could step back, learn something new, and recognize how much of the earlier experience transferred to the next chapter. 51:43 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3103s) The productive path you took was to relearn, see what you knew and didn't know, and get back into it. Other people in that position might fall by the wayside or chase adjacent things without recognizing the context and reality of where they are. What you did was really cool. Your experience learning Ruby on Rails echoes what we often hear about programming languages. Once you learn one language well, you understand how to detect a problem, recognize that you have one, and put the right keywords together for a Google or forum search. Outside the syntax changes, learning another language becomes much simpler. The other thing you learned was about people: how to build products, scale them, and deal with partners and clients. Even if you had started a consulting company or someone wanted database help, you had real skills that you don't learn in college. So many studies have shown that people in junior industry positions can spend several years unlearning what they learned in college before becoming productive in the real world. Those skills would have mattered even if the next step had been a consulting company helping someone with a broken database. The problems were real, not abstract classroom exercises. You bypassed all of that, and then some, by building something popular in the open. You learned the technical side, the business side, and how to keep a steady head when there's a fire. You could focus on solving it and making progress instead of becoming another source of chaos. You had also learned how to work with people, which matters just as much as the language, framework, or database knowledge. 53:18 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3198s) Yeah, another thing I really took pride in was figuring out bugs. I genuinely enjoy the process of getting a weird report, especially when it affects millions of people, and diving in until I can pinpoint exactly where the problem is and how to fix it. To this day I still love that. It's a great skill to be able to absorb information and trace an issue back to where it actually comes from, because it's often not where you initially expect it to be. I didn't even realize I was developing that skill during the MixPod years, but it has helped me a ton in my career. As a CTO now, it's incredibly useful. Sometimes just from listening to my team talk through a bug, I can more or less triangulate where it probably lives because I've seen so many versions of that process before. Back in the MixPod days, that kind of debugging sometimes mattered immediately, because a weird issue could hit millions of people very quickly. That pressure taught me to be methodical instead of panicky. 54:14 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3254s) Exactly. The key word here really is experience. If I were to summarize what we've been talking about, a huge part of it is that you've actually been there and done that, which is very different from just learning about something academically. You're basically a case study in how being in the middle of the work gives you an edge in recognizing outcomes, even when you're no longer the one directly doing the implementation. That's a really fascinating place to be. 54:49 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3289s) Yeah, it also helps me not overthink things. I've noticed, especially as I've hired more developers, that people can get really hung up on finding the perfect solution. And I'm like, there isn't a perfect solution. There are many workable solutions, and they're going to change over time anyway. So we need to come up with the best solution for now and then revisit it later if we need to. That experience has helped me a lot. When people come to me and ask, 'What should I do?' I usually respond with, 'What do you think you should do?' I want them to work through it. Sometimes, even if I know they're slightly off, I'll let them go down that path a little just so they can learn from it. Experience is the biggest thing I'm thankful for in this whole journey. Sometimes people mainly need permission to think their way through the tradeoff instead of being handed a supposedly perfect answer. Experience helps you recognize that too. 55:39 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3339s) That was a fantastic summary. I didn't expect to start a conversation in this direction, and this has been great. I learned a lot from hearing the details directly from you, especially the kinds of operational and technical details that tend to get lost to history. So thanks again for coming on. I know there are a lot more things you've done that I'd love for us to talk about at some point in the future. 56:06 - Bill Richards (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3366s) Absolutely. Thanks so much for having me. I'm so glad to see that your site is still thriving. I've learned so much from you and from kirupa. Com, and I really can pinpoint that era of Kirupa tutorials as something that shaped me. I even wrote my first tutorial on your site, so I want to make sure to give you your props. 56:27 - Kirupa (https://www.youtube.com/watch?v=LsTyKeJyg-Y&t=3387s) Thank you. You are appreciated. It's all teamwork. There's a group of people who've made it work, and you're a big part of it. When I think about community, every person who has contributed to it has played a big role in its overall success, so you get the credit as well. Browse all Interviews with Creative People: https://www.kirupa.com/podcast/index.htm