I make you right about Twitter. I think my primary point, and what I read in the OPs article is this...don't let the fear and worry about the tech you're using

I make you right about Twitter. I think my primary point, and what I read in the OPs article is this...don't let the fear and worry about the tech you're using take your eye off the customers paying your bills. I'd much rather have millions of customers using my app while I work out how to fix technical debt issues, than piss about with my choice of tech for 6 months while the competition takes money off of the table. I love technology, but too often it's a distraction in business. Twitter will have known they pushed their luck on reliability while they scaled, and seemingly got the balance right as it didn't take them down. If you're interested, here's some more specific answers to the points you raised: So keep in mind we usually have a couple of engineers assigned to the backlog for Staff Squared. Their time is precious, but as with all things a technical solution is not always necessary, so we will often use workarounds: Internal tools: They exist to help the sales team onboard more customers, or help the support team keep our customers happy, or keep the management team in the loop and so on. Most of these things can be traced back to my two points (getting/keeping customers) and if they can't then they're nice to haves and can wait. Alternatively we'll ask a non-techie member of the team to run a process manually using what they've already got available. We only create a tool if the process we're experimenting with actually delivers enough value to warrant the coding time to automate it. Internal features that increase scalability. These do go in to the backlog, and they're things like integrating S2 with our CRM, or setting up KPIs (e.g http://imgur.com/itFzSaO http://imgur.com/itFzSaO) and dashboards for important info. Again, most of these things can be traced back to gaining more customers because we use the data to refine our onboarding and overall user experience, or speaking with customers who aren't as engaged with the app as we would like and ensuring they stay a customer. Technical debt due to a lack of foresight in code maintenance is not something you want if you can help it. Having said that, I can't think of a bigger technical debt than complex, mature accounting app written in classic ASP running stored procedures to pull data from complex SQL views. So while we do of course have to factor in to sprints things like performance enhancements, code refactors, or just plain old upgrades to the version of .Net MVC we're using, they're just not as much of a priority as my two main justifications for the cards I include in upcoming sprints (Getting customers/keeping customers).