When starting any software project, there’s an age old argument: should we build something simple that solves our current problem or should we use an existing product that’s more complex, but more feature rich, since we know that’s where we’re going to end up in the future?
This is especially true when starting a company because you don’t want to get into a situation where you have something that won’t scale up to handle your impending traffic and users. (Your company is going to be a huge success right? )
One side of the argument says to start simple and solve the problem(s) at hand. That’s not the same as making short sighted, possibly limiting, decisions. It means trusting that your engineering staff can handle any iterative changes required to support your changing needs. Understand any tradeoffs in performance & scalability that you’re making now in exchange for speed & time to market.
The other side of the argument is to target something that is more complex, but that solves more complex problems. The thinking is that when you eventually reach the point where you have the more complex problems, your solution will be waiting there, dormant, ready to be turned on. The proposed benefit is that you won’t end up with something simple that you need to trash once it outgrows your needs. You can grow into your product as needed.
However, in my experience, product development rarely, if ever, happens that way.
I recently ran into this very situation last week while talking to a startup founder. He had a client that needed some simple web sites built. However, the client believed that his needs would grow to require a more full-featured CMS platform. The founder reasoned that they should just start with the CMS, so when the need arises, it will take a minimal amount of effort to support the additional complexity.
I argued the opposite. Making the “just flip a switch” assumption ignores a large swath of other assumptions, any of which could prove to be a giant roadblock:
FYI: these assumptions are not mutually exclusive. You can ( and probably will ) encounter one or more of them.
- That you’re actually going to need the complexity – Sad to say, but sometimes the need just doesn’t materialize.
- That you understand all of your futures needs enough to select a product that would solve them. – Premature optimization is the root of all evil. Everyone loves to make predictions and be proven right. In reality, it almost never works out that way. You’re not omniscient. If you’re doing Customer Development ( you are, aren’t you? ), you’ll be taking your direction from your eventual market anyway. Why make some of the most critical decisions about your company when you have the least amount of information possible?
- That the product you picked can actually solve your future needs – If you’re like most companies, an exhaustive product evaluation isn’t in your initial project plan.
- That, in the time between implementing the simple solution and needing the more complex solution, nothing changes with the product that you’ve chosen that could impede your transition – Products change & evolve. New versions are introduced, sometimes with backwards incompatible changes. Even understanding any version changes and testing your product for any issues is going to be a non-trivial effort.
- The cost of maintaining and administrating the product you’ve selected is worth the trouble – Maintenance, Backups, database updates, security updates, etc… are all factors to consider when evaluating any product. If you don’t stay on top of updates ( especially security updates ) you can find yourself in a nightmare scenario.
- That the effort it takes implement your product in the short term allows for an easy transition to the more complex solution in the future – There’s a good chance that you’ll be new to whatever product you choose. There’s an even better chance that, however you initially use it, that your usuage won’t be optimal.
Those are just a few to keep in mind. Any one of those assumptions can cost you time and money. Both are precious resources in a startup.
However, an oft neglected repercussion of building too much too quickly is that the extra functionality can calcify your product and make it very rigid. Releases become more complex, new features take longer to implement and bugs take longer to fix. You can find yourself a prisoner of your product, maintaining functionality and features that no one ( or very few ) people use. It can demoralize a engineering team, making them more and more susceptible to the nuclear option: the big rewrite.
I think the tendency to lean towards a more exhaustive solution upfront comes from a time when the effort require to change software was much higher than it is today. When systems were written in C, C++, Perl or even Java, making changes was a large undertaking. The thought of possibly throwing away chunks of code was nerve racking. It represented a huge investment in time and money. However, with todays rapid development languages and frameworks like Ruby/Rails & Python/Django, the investment required to create something, both in time and money, is rapidly shrinking.
To me, for any new product development effort to succeed, you should do three things:
- Start simply and build only what you need, nothing more.
- Pick a platform / language / framework that allows you to pivot and change direction easily.
- Hire good engineers that are experienced with different technologies and can change and adapt to different technology needs. This will by far the hardest, but it can be done.