Startups have very little money, very little time. In their short lives they try to make a good bet at putting together an architecture that will get them far enough, even if it isn’t forever.
When building your product, shipping quickly seems like all that matters. However, every time you ship with bad code, you incur technical debt. Bad software design or bad architecture follows the same logic. Sometimes it’s just so plain obvious solving a problem could be done better, but the concrete knowledge for that aspect of the used framework is lacking or no good rationales for what approach to take are available.
For this, consultants are great. Mostly because they help reducing your technical debt by offering a roadmap of how to solve issues. Also, especially if the startup has only one software guy, having an extra pair of eyes on your activities can really hedge you for future surprises.
On average, consultants are quite costly. It’s not unlikely, however, that they are willing to strike a deal with you to get some of the startup enthusiasm back. Even if that isn’t the case, having consultants help you for a few hours is a very different story money-wise than hiring one for weeks to flesh out your product.
Objectively, there are a lot of extremely appealing but quite vague incentives for why startups should hire consultants. Let me give some concrete examples of help we have received over the past six months, working on our booking platform.
Just two months after having switched to Ember we decided to have our application audited, to point out pain points that would in due time become serious problems. At the Ember London Meetup I met James, who pointed out some Ember gotchas, including introducing the idea of more sophisticated route nesting.
In January I had the pleasure to have a workshop with Boris to reflect on our initial attempt at developing a recommender system for matching hotels and travelers. Summarized:
Recommender systems are designed to be technical solutions for scenarios where differences between users (differences in individual preferences) show to be the the strongest factor determining the outcome of their final choice.
It wasn’t yet determined whether the hotel matchmaking problem really was one that came from individual preferences. Instead, the best piece of advice was to favor general searching and filtering techniques. Luckily, we did talk about feature vector compression and other technical things.
Lastly, in February, two kind gentlemen from the IT giant Capgemini came over to talk about, amonst other things, Azure infrastructure.
We talked about Azure VMs and cloud services, how there is little like the benefits of Staging when just working with VMs. About continuous deployment through Team Foundation Server if all unit tests pass and about tricks such as warming up your application in
OnStart, crucial if you’re working against odd behavior such as IIS recycling every 29 hours.
Then they shared some knowledge on Entity Framework, on increasing performance by turning off dynamic proxies, auto tracking and lazy loading if you’re not using .NET MVC anyway. About the differences in Azure SQL and MSSQL and about Geofiltering, for which Mongo seems much more fit.
All in all, great stuff was shared and a lot was learned from any of these sessions. Viable information that gives startups speed and certainty. So don’t hesitate contacting consultants but bring them on board for some awesome advice.