Build vs. Buy in the age of AI
As a CFO who used to be technical, I specialize in working with engineer founders.
And it's in this context that I encountered something interesting this week:
I was sitting in a client team meeting and we were discussing updating their financial software stack as they move from seed stage to series A
Which is a typical conversation we have during growth:
Lower-cost solutions like Quickbooks, Xero, manual processing, on-the-fly analysis tend to break down when volumes go up, so it's typically when we'll discuss migration to a costlier but better tool.
There are lots of factors to consider during an ERP upgrade, CRM build out, or switching providers, but typically for startups, we're most times talking about BUYING software.
To date, the rule of thumb is that in the early days, you never think about BUILDING the software.
Because building internal software will take time away from your main goals, is likely to result in a worse solution, and doesn't tend to make sense until you're big enough to have an internal software team.
But as I sat in this conversation with this engineering team, they started talking about building internal software right away.
I immediately hesitated and got worried
(That's a big startup No-No!)
But then I realized this isn't a rule anymore: It's a framework that's worth questioning!
In the age of AI, how does our Built vs. Buy decision framework change?
I'm honestly still not 100% sure, but these are the 2 thoughts I'm having most strongly:
1) For small tools with low stakes, building definitely became more appealing
Startups and small businesses often get stuck with terrible software that barely fits their needs until they're big enough to afford something more customizable.
It's an annoying reality most of us have had to deal with for ages because low-cost providers make their businesses work by appealing to the masses.
Now, a lot of things we used to just struggle with may be easy to custom-build with AI.
On my shortlist of things to vibe code for my own business:
A new CRM, something to replace my booking software, something that helps me bring Stripe metadata into Quickbooks to make categorization less manual
This probably deserves a whole post of its own, but here's what I think defines these low-hanging-fruit projects:
They're for me and I can build them myself (I think)
They're in my area of expertise - they deal mostly with data and APIs (I think), so I feel confident I can instruct, manage, and validate the build
I require a very small set of requirements for each and my quality standards are pretty forgiving for these problems
Because of the nature of the problems I'm solving, I should be able to tell right away if it's working or if the project is a waste of time
They don't require scary write access permissions, sensitive data, or unregulated inputs (well, the booking software is a little borderline maybe because... calendar)
This isn't work-stopping critical infrastructure to my business
2) For teams of eager engineers, we need to remember there are MANY reasons (beyond the code) for BUYING software
In this client meeting, one of the engineers suggested that instead of us buying a new FP&A software for the business, he could just build my Finance team a custom reporting app.
We could pull in all the APIs from all our other softwares, from the product itself!
And we'd save so much money on those pesky $20k+ per year FP&A solutions!
But this project suggestion hits different:
Instead of looking forward to opportunities, I'm getting visions of my Christmas future that include PTSD of past internal corporate software:
Inflexible options limited to what a non-finance-expert thinks I need
Distracting the engineering team and myself every time the tool they've made for me needs issues fixed, upgrades, or maintenance.
Outputs I can't trust and don't understand that I have to stand behind
Every new person I hire has to learn the tool (and can't leverage prior experience or technical skills)
When this thing breaks at 11pm before a board meeting, what do I do?
When you buy software, you don't just buy the code.
You buy a support team, expert-derived flows, tested features, platform trust, regular updates, and it being someone else's problem when the thing breaks.
In sum, our build vs. buy methodology definitely needs to evolve with AI.
But thinking "we build everything now" or that all commercial software is dead seems naive.
...the kind of thing someone who's never suffered through trying to get their work done in a custom-built crashing SharePoint 2010 webpart before would think.
Enjoyed reading this article? Subscribe to receive more via email here.
Know a Founder or Entrepreneur who'd love this content? Please share it!
