Build vs Buy in software development – Part 1, the selection criteria

There is a common theme throughout life; “Should I build, or buy?” It doesn’t seem to matter which thing is under consideration, the process we used to make the decision should remain the same. This is a multi-part series on making the build vs buy decision for software projects.

This is WAAV Studio, a rapidly evolving application used for “Smart City” visualization and management. There are several components that go into it, and plenty of ‘build vs buy’ decisions to be made.

Here are the considerations I’ve had in deciding which way to go on several components

  • What is the scope of the component – How broad, and fundamental is it

  • Do I have the expertise to build it

  • How long will it take to integrate a purchased component

  • How long will it take to build it myself

  • What is the cost associated with purchasing it

  • How will maintenance look over time

  • The solution must be easy

  • The solution must be portable to multiple platforms

  • The solution must be small, fast, and intuitive

There are perhaps a couple more things to consider, but these are the highlights. There are some market considerations as well, but they essentially boil down to:

How important is time to market?;

and

What is your budget?

I’ll start with the WAAV Studio time to market and budget first. Time to market in this case is measured in months. A polished product needs to be available within a 12 month time period from when I started (January). The product must meet various milestones of usability along the way, but overall, the 1.0 version must be user friendly within 12 months.

Second, is the budget. This is the product of a very small team, using tools such as Copilot, and ChatGPT, as well as their core skills and programming tools. There is effectively no real budget to speak of, in terms of purchasing other bits of software.

With those hard constraints, I consider the list of ‘modules’ that need to be in this application.

  • Geo spacial mapping

  • Visualize various geo-spacial data sets

    • KMZ

    • GEOJSon

    • Shapefile

    • .csv data sets

  • Visualize various graphics assets

    • .png images

    • .gif images

    • .jpeg images

    • .svg images

That’s the rough list, with lots of detail on each item. The biggest and first build/buy decision was around mapping visualization. The easy and typical answer would be “just use Google Earth”, or something like that. Even before that, it might be “Use ArgGIS”, or any number of GIS software packages. Going this route might be expedient, but will lead you down a path of being constrained by whatever that core package is capable of.

A few of the criteria are around ease of use, and size. This application is something a typical city administrator will use on occasion. Their key job function might not be related to this software, so they need to be able to come to it after 3 months of absence, and still be able to pick it up and use it effectively to achieve some immediate goal. This is a hard one to achieve, and has to do with the UI elements, their layout, and natural usage. Again, when you select a core package, you may not have enough control over these factors to have a satisfying outcome. Using ArcGIS, for example, it has all the features a GIS professional could possibly want. The package size is measured in the 10s of megabytes, and the user’s manual would make an encyclopedia blush if it were printed in paper. This is not an app that can be picked up by your typical city clerk in a 10 minute session, let alone mastered six months later, without constant usage.

First decision: Create a core mapping component from scratch, without reliance, or dependence on any existing mapping components.

This is such a core, fundamental decision, it drives decision making across the other components, so, it better be good.

I have never built a mapping platform before WAAV Studio, so I started with the naive notion that I could actually do it. I mean, how hard could it be, right? All software engineers have the urge to build from scratch, and just jump onto any coding challenge. My years of wisdom told me, I better have a way to evaluate my progress on the task, and determine if it was time to abandon my naive first choice for a better choice later down the line.

In the next part, I’ll look into what goes into the core mapping platform, and which other components were chosen for the build vs buy machine.

Previous
Previous

Impressions – One week in a Tesla Model Y

Next
Next

SVG From the Ground Up — Can you imaging that?