For a long time I’ve day-dreamed about a side-business building Jira add-ons. There’s so much that Jira doesn’t do natively that a simple add-on can solve. The pricing-model of add-ons means that for a small/medium business, it’s often within the discretionary spend of directors/managers, so the barrier to entry is low.
Even in my wildest dreams, I don’t become rich with this model. But, with modest success, I imagine I could cover the costs of my annual holiday even after Atlassian takes their cut.
Lately, I’ve been applying similar thoughts to SAAS products, and pondering whether incumbents’ business models will be at risk as agentic engineering lowers the threshold to build software. It’s not necessarily that SAAS products are easily replicated, but that other – potentially much simpler – solutions to an underlying problem might now be within reach, either by a third party or the customer themselves.
Buy-vs-build has always been a conundrum for businesses, but a lot of software has historically been immune from deliberation because of the perceived complexity, and therefore the effort required to replicate it.
Let’s take Miro as an example, and how it might be used in a 50-person start-up: They only use Miro’s basic capabilities in planning sessions and brainstorms, but they require SSO to satisfy their InfoSec policy which necessitates Miro’s "Business" plan at a cost of $12,000/year.
Until recently, this was considered to be a necessary cost of doing business, but now it’s viable for an engineer to devote just an afternoon or two with Claude Code to build a home-grown alternative that’s capable of everything they need – an infinite canvas, pre-defined shapes, connectors, and even realtime collaboration.
Naturally, a home-grown alternative won’t have anything like Miro’s full featureset, but let’s remember that most of those features weren’t used. It’s like fashioning a flat-head screwdriver out of a piece of metal in lieu of buying a mechanic’s tool chest. The tool chest is undoubtedly more complete, more capable, & more future-proof, but if you just need to tighten a loose cabinet handle, none of that matters.
The "cost of ongoing maintenance" exists, but contrary to what we might think, a lot of tooling doesn’t have a high maintenance overhead to begin with, and if people are intentional over what they build and how they build it, they can take advantage of that. The overhead will never be zero, but neither is the overhead of managing third-party providers.
The threat of AI-assisted home-grown solutions to SAAS companies is comparable to the threat 3D-printing presents to mass-manufacturing. That is to say, negligible in most cases. Designing parts is time-consuming and requires specialist skills and experience, as does the act of ‘slicing’ & printing itself.
The benefit of 3D printing to consumers who get it right, though, is significant. Small businesses can prototype parts at pace, allowing innovation and progress that wasn’t possible previously. Individuals can solve problems around their home with a tailored solution faster than Amazon can dispatch a suboptimal one.
Printing something is easy, much in the way that developing something with AI is. Printing a design from a library like Thingiverse.com is also fairly trivial, as is asking AI to recreate something it’s seen one thousand times before. But with either technology, solving novel problems is much harder, generally requiring a depth of understanding that extends to first principles.
This is an interesting dichotomy – a substantial difference at a micro level to how some companies choose to build or buy software, whilst seeing minimal difference at a macro level to the broader SAAS ecosystem. If you’re running a start-up or scale-up, the maths has significantly changed: we’ll see greater divergence in strategies across companies at different stages of growth, with smaller companies finding they can create tooling that would once be out of financial reach.