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.