Why A Start-Up Should Trust In Its Own Technology
It is no secret that the Linux community keeps a close watch on Microsoft. Even though the once-mighty OS giant from Redmond isn’t the force that it used to be, many still like to keep an eye out for Microsoft not using its own tools and operating system for its business needs. After all, Microsoft’s tool suites and platforms have overwhelmingly been geared toward the B2B market, and so they should be ideal for the company’s own needs, right? However, as long as there have been Linux verses Windows feuding, stories such as this, pointing out that Microsoft used Akamai’s Linux-based site acceleration service, typically generate waves in the tech blogosphere.
Of course, the purpose of mentioning this is not to rip on Microsoft, but to demonstrate that it can be a source of embarrassment when a company does not trust its own tools, and even opts to use the tools of its competitor even when it is considered the leader in that problem domain.
In your case you’ve created your start-up because you figured out a better way to do something, or at least it should be because why else did you do it? You need to think about how difficult it is for a client to commit to your solution if they see that you don’t believe in it enough to use it yourself.
If for example you’ve built the next best thing in help desk ticketing software but clients still submit requests to you through ZenDesk or FreshDesk or Kayako, it says that even you don’t believe your solution is indispensable.
It doesn’t matter if you use this other solution because, while your ticketing is superior, it provides a few additional unified features that make it easier for you to conduct your business. In doing so you’re telling your prospective customers that while your solution is better, these additional features in another solution are beneficial enough to live with any shortcoming it may have in its ticketing.
Are you saying that this doesn’t apply to my company because I don’t build technology? That might be true, but do you use technology in a service you offer? Do you build websites and recommend a responsive grid for all your clients but your own website doesn’t use one? Do you tout the benefits of RoR but use WordPress for all your own sites? Do you suggest Linux but run all Windows servers yourself?
It’s true that different situations require different technologies and you might recommend a solution for a client that you yourself do not use because you have no need for it. The concept that we are discussing here is how not one-size fits all. Our point is simply this: go ahead and drink the Kool-Aid of your own evangelism.
To think about it another way, if a guy is going to paint your house by spraying it, yet would only brush his own, the question you may be asking is whether he considers his own house to be more important than yours.
Historical Pattern of Successful Technologies
One interesting trait of technologies that have succeeded with the larger public, such as programming languages, is that often they were developed for the use of their creators to solve internal problems. A good example is C, developed in-house use at Bell Labs as a programming environment for UNIX, as opposed to Ada, which was developed for a general market and never flourished as a language.
Lean Approach to Testing
For a lean startup, dedicated test teams are often out of scope and budget, and therefore this approach can work as an alternative. On top of this, a startup that continues to use an internal technology even after it grows implicitly demonstrates the product’s scalability.