Buy versus Build…

We had a question come up during a pitch the other week about where we draw the line between buy versus build with parts of our technology.

I’m a fan of not re-inventing the wheel when you don’t need to, which tends to put me at odds with many software engineers.  I’ve often found that software engineers err on the side of recreating everything from scratch on the assumption they can do it better.  But that misses the point — it’s not a matter of skill, it’s always a matter of time.  The exception to the rule are engineers who’ve released a bunch of products.  Experience is a great teacher 🙂

Fortunately, Logan (my trusty CTO) is a veteran coder and is more than willing to explore off-the-shelf pieces when it makes sense.  So the short answer is that we creatively use off-the-shelf code whenever we can. 

However, there are two caveats to that statement: 

a)    Critical components.  If we are considering using off the shelf code for a critical component, we have to have a high degree of certainty as to the reliability and efficiency of the tool. For example, we looked at an open source library to generate tags, but the code wasn’t nearly optimized enough for our kind of deployment. 

b)    Security.  Data security is big concern for us.  We must be able to clearly demonstrate that a customer’s data is secure under a variety of circumstances.  If using something off-the-shelf results in the slightest degradation of our security, we’ll pass.

But that’s really not the whole story.  As a startup, off-the-shelf can be deeply appealing.  There’s a huge volume of open source code that is readily available, and an equally vast array of odd little utilities that someone somewhere developed, and all of it is readily findable (thanks, Google).

However, there’s a hidden cost, which was really brought home to me by some events that occurred on Friday. 

Working with someone else’s code is orders of magnitude slower than working with your own. 

For the non-coders out there, it’s like inheriting a marketing plan that was written for similar but-not-identical business and trying to shoe-horn it into your business plan without (a) making changes to it or (b) anyone noticing.  Not as easy as it might at first seem.  Think about all the little tweaks you would need to make throughout the rest of your plan in order for integration to be seamless…

Logan has been working on some email integration functionality so that Unifyr can support email archives, and part of that process relies on off-the-shelf tools and someone else’s standards.  The net result is that what was theoretically trivial has taken much longer than he hoped.

But compare and contrast…  On Friday we had a very interesting lunch meeting.  On the drive home he had an epiphany about some functionality we’ve been dying to show but have been unable to spend the time to develop.  I would guess he got home around 3pm.  By 6pm I had a working prototype.

And this is a big deal piece of the Unifyr puzzle.  So big, I can’t tell you what it is yet.  But it puts us in a league of our own.

And it was accomplished in less than three hours.

Now okay, that’s a bit like the old saw about Picasso drawing on the napkin and charging thousands for it ("It only took you five minutes", "no, it took my whole life").  A lot of work was put in to giving the core of Unifyr exactly the kind of flexibility that let Logan deliver this so quickly. 

But it doesn’t change the fact that moving a mountain with your own code is often faster than shifting a molehill with someone else’s.

Choose carefully!