At my job, we’ve already stopped using a bunch of SaaS products/services, as we can just replicate them with our own solutions which we vibe-coded. I work in the data science and analysis space.
I hope that's a trend that catches on generally. However hard a job is to do, it often gets harder when refracted through the SaaS kaleidoscope.
The job of a SaaS product owner is to ensure that you're as screwed-as-possible without their product. That's not the same as ensuring that you've met your own goals. Having five or six such people all fighting over your workflow with no coordination between them (since they don't know what other SaaS products you're consuming) is 3 parts helpful, 4 parts confusing.
Yes. I'm so tired of hearing: "we have to use this software because our boss bought it, except it doesn't actually help us in any way".
People who need help with software should hire software engineers, not buy a product built by software engineers. That way the engineers can gather domain expertise since their co-workers are specialists in that domain, and also the domain experts can gather software expertise in the same way. What we're doing creates needless complexity, silos, and fragility on both sides.
That's called NIH, or not invented here, and it happens at big companies like Google. It fragments the expertise pool, and saddles workers with tools that eventually fall behind the best of breed.
"We have to use this software because our company developed it."
There are exceptions: (Protools, Solidworks) but I think that most of the time the best of breed ends up being built by its users, not as a product for sale to some users (VLC, Blender, Pandas, ...). Not to mention all of that software that just doesn't make sense as a product to begin with (Linux, TCP, Kubernetes...).
Focusing on software products, rather than on whatever the actual job is, creates a mountain of distractions related to marketing and billing and shareholder fluffing such that we'd have a lot more talent to apply if we stopped playing games with moats and applied ourselves instead to, you know, the tangible things that need to get done. We're on an increasingly inefficient path here, it seems like the available work gets less meaningful each year.
As for fragmenting the expertise pool... I'm not sure which represents more fragmentation:
- specialist users, together with their associated tool specialists (a.k.a. software engineers) such that the software folk are separated from each other
- tool specialists separated from the people who need those tools, such that the software folk are together
One group is split, but the other is unified, seems like more or less a wash to me. Or it did, pre-LLM. But now that AI is rather applicable to software problems I think it makes more sense to use it as a bridge between the software engineering diaspora such that they're as close as possible to their users (if not just being the users themselves).
Ask anybody who is not a software person: software people end up increasingly disconnected from reality the more time they spend in the company of other software people. It's why we have this: https://xkcd.com/2030/. We're better of helping the others, not helping each other.
We work with data from a bunch of different sensors (radar/optical/etc. from satellites/drones/planes, acoustic, text, and a bunch more) - some of the tools in our tooling pipeline has previously been paid services by companies that specialize in those things.
For example, say you have a SAR image, and want to classify if there are some vessels on that image, and if so - identifying what vessels? A company will do that for you. For approximately $100 pr. image. Or maybe some tool to analyze the radar parameters of some object (like what sort of radar a vessel or airplane has), also something niche companies will do for you, at a price. People would be surprised to hear now many thousands a license to some analysis package costs annually.
The people that use these services, tend to be analysts and domain experts. Personally I have SWE experience prior to moving to analysis, but I've always been too bogged down with analysis-work to actually develop the tools I've wanted. And budget constraints have made it hard to hire a team of devs to only work on building tools.
Luckily the advancements in LLMs have made that part much, much easier. So now we are able to get together, plan out the tools we want, and actually get things done.
I was maybe a bit loose with the "vibe-coding" part. We are mainly domain experts, but the software engineering experience varies from very little - to quite experienced, so we're not completely fumbling in the dark.
