A Foundation or an Anchor?

Once you have code out the door, once you have customers, once you have people actually wanting to give you their money, you reach a certain place with any technology company. You have some attention, people like it, it could even be selling!


Sure, now that you have customers (users in web2.0 language), you have feedback. Everyone has ideas for new features and functionality and has been asking for them, so you – like a good PM – work to prioritize them and figure out what will/won't work with your schedule. In a matter of no time, you're starting to add things to the system and doing new and interesting things. Your customers love you, your bizdev guys love you, and you get great press coverage.

But… isn't this a good thing!?

Well… maybe, but this is also massively dangerous.

Those first few features were easy and were implemented quickly. In addition to all of those good things, you're also building up technical debt. You're also building up more and more code that needs to be supported. Now, adding that next feature ends up taking just a little more effort.  Now, that bug is more subtle and takes a little more effort.  Simplifying that function takes just a bit more than last time.

If you're selling/distributing something closed source vs Open Source (Microsoft Word vs web2project), you get the complexity of figuring out what to do -if anything – about your users' customizations, etc.

If you're selling something installable vs a service (web2project vs WhyGoSolo) and you also have previous versions of the application that need some level of support.

If you're selling something with API's, it's the worst of all worlds… not only do you have to determine what to do about old versions, but you also need to update the behavior, etc of all the old things.

Your team will notice that they're each spending a couple hours each week… and then an hour each day… and then all morning.

At some point, if this technical debt and burden – that's what it is – isn't managed and tracked, it can overwhelm your team… and they'll just start leaving…

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub