Make or Build? The scales are tipping
Make or Build. What is it?
Back in the olden days of software and enterprise tech, make vs build is always something stakeholders need to weigh when trying to improve business processes. As a stakeholder, you are always weighing timeline, implementation costs, do you have the developers, how does it integrate with your existing stack, would an external vendor be able to do a better job, and can you even build it internally?
If you are running a lean IT team, or don't really do development it is likely you would be more likely to outsource or pick an off the shelf product.
But that feels like its being turned on its head, especially for smaller tools. It's now as easy as just asking an LLM to generate a simple html page artifact and you can have simple, useful tools, that can do some type of calculation or transformation of data that you may not have been able to (or have the time to) create before.
Mini/Simple Tool Builds
Building tools have never been as simple as they are now. This feels like the Excel version of programming. Just like you could open up a new sheet and just enter in formulas to build a custom little tool, now simple code tools are just a prompt away.
So far a couple examples of what I've built:
- This new blog from the ground up.
- Custom TCG centering tool with perspective correction.
- A simple SaaS churn calculator. Used to visualize the effect of churn on SaaS.
- A custom drag and drop solution for Vue using just html + css. The alternative was the VueUse useSortable composable which also required the
sortablelibrary to be installed. When I was building this tool the sortable library had not been updated in over a year so it was hard to tell if there was any active development. - Custom form builder. Takes a json array of fields and dynamically builds a web form.
- Local development web tunnels. Originally I used to use
ngrokto generate a tunnel from a single command, but have always wanted to move over to Cloudflare tunnels but it is a complicated process to setup a new tunnel requiring multiple api calls. I spent a few hours building a simple TUI that just requires you to enter the entry url and localhost port where your server is running and it generates new tunnels on the fly. I was able to unsubscribe fromngrokbecause that was the only feature I had been using it for.
While all of these things could be done without AI, I likely wouldn't have had the time to learn the ins and outs of every technology in order to be able to build each tool if I was just on my own.
Benefits of your own tools
There are many benefits of generating your own tools for simple, non-mission critical parts of your business. First of all it works exactly the way you want it. Take my Vue drag and drop implementation, I dropped a stale dependency and built a modern, web-forward solution that met my use case. You aren't pigeon holed into another way of thinking, or adapting your workflows that have already proven to be efficient.
It also leads to less bloat. An existing tool may have dozens of features when you only need a single one. Also popular libraries you may be used are generalized to as many use cases as possible, so they may not be as efficient as building for the single use case you may need to use it for.
Reducing dependencies also potentially reduces breaking your app and builds from 3rd parties. If anyone remembers the left pad incident, it was a super simple library that just added padding to a string. So for example if you have a number like 42 and then ran leftpad(42, 5, 0) you would end up with a string like 00042. Even back in the day if you were a serious developer you wouldn't be using a library like this and could just roll your own.
But now there is no excuse, building little libraries is easier than ever with AI. A simple prompt like Write me a function that accepts a string, a length, and a padding value, and return a string with padding added will result in a function that can handle any type of left padding without needing an external dependency.
Every dependency removed is one less issue or potential attack vector removed from your software stack. Building these libraries yourself will keep your stack clean from rogue dependencies that may become problems.
Where building doesn't make sense.
Your core stack needs to be as reliable as possible. If its mission critical for your business, trying to build your own may not make sense. You also have to keep in mind what happens if the tool goes down, stop working, has a critical bug, or can potentially leak personal information. Take an entire CRM system. It may be tempting to replace an expensive CRM with a home grown solution, but a CRM is the lifeblood of your business. If you lose the data or get hacked how would that affect your business? Using 3rd party tools that have guarantees for uptime and reliability are still a good reason to purchase tools that may be out of the scope or your typical business development.