Islands Everywhere
Own Your Data, Own Your Process
Hey folks! I’ve had a busy start to the year immediately following my honeymoon in Korea and Vietnam. In January I started a new role as a VP of Agentic Product Engineering and started building a practice around AI-assisted product development. Working on ambitious buildouts and rapid migrations I’ve been constantly learning. I wanted to take this time to share a few interesting things I’ve noticed along the way.
I’m hiring smart engineers excited to do product development with AI in Toronto so drop me a message if this sounds interesting to you.
In early 2026 we’re noticing a strong move away from traditional SaaS products and a rapid adoption of custom software. Customers paying per-user for massive suites of software (comprising features that are largely unused by the majority of customers) has lost its appeal in the face of more readily available bespoke solutions using AI tools like Claude Code or Claude Cowork. In our work we’re looking to pass on that benefit to our customer and do more for less which has attracted a pragmatic tier of interested founders and business leaders.
This has been noticed by general engineering consumers too. I specifically enjoyed this post about spending a weekend replacing software subscriptions using AI coding tools. I’ve recently done the same thing to replace Zoho Books with my own tool for easily managing business features. I never used the full set of features anyway and by replicating the features I actually use, I was able to even personalize those features to better fit my needs.
One underlying reason why building a custom solution is compelling is because it removes a “data island”. With SaaS software there’s a general attempt to lock-in the user to their system by holding a user’s data hostage. GDPR has helped in this sense because users are able to receive a raw export of their data on demand, but the interface for building live solutions on top of these software is often painful. If you want to build a custom AI tool that matches your data, you need easy access to that data. Frankly SaaS has mostly gotten in the way here as a result of their business model.
As it gets easier to build custom workflows and applications, it becomes more and more rewarding to gain control of the data these systems need. Rather than having an agent struggle with an API interface, run up against rate limits, or deal with data access gaps why not build the same solution with an interface that matches what your system needs? Interfaces and integrations remain one of the most important conversation topics when thinking about AI adoption.
As I’ve continued building on Benny Chat I’ve been transitioning how I work with third-party services. I went from leveraging MCP Servers for their ease of setup, to extracting those servers into custom tool hooks for AI agents, to now looking at removing the third-parties entirely and building my own. Todoist for example has an amazing API interface for managing tasks and has recently been leaning into AI features but how hard would it be now to just replace it for what I need.
The only concern is as we do these things are we not creating the same islands of data that we were trying to get away from? Perhaps data capture isn’t the right approach. I regularly use Obsidian and one of the features I rely on the most for integrating it with AI is that it’s built on a bunch of files sitting in my local filesystem. Almost any tool can read files. Because of this Obsidian doesn’t isolate their data on a data island and instead allows it to be easily accessible. As we look to build solutions for our own needs, it’s important we don’t accidentally isolate ourselves from our own data just because that’s the shape SaaS software has embedded in our minds for the last decade or more.
On Oz
Oz by Warp.dev released last week and presents an interesting tool for facilitating the use of AI agents. It’s an agent orchestrator that helps users define containerized environments where the agents can run. While I’m still experimenting with the tool, I have a few initial impressions.
I’ve been working on a process for compiling the dozens of email newsletters I receive on different topics down into a single digest of linked articles. I filter based on preferences Claude helped me pull out of previously highlighted articles I read in my reader app, Matter. I’ve been incrementally improving this system by reading an email at a time and ensuring that the AI is correctly using my preference to select linked articles. Having finally gotten to a point where there’s trust in the system, I’m at a point where automatically kicking off this process might make sense.
Oz did a great job of connecting to my code repository, automatically discovering the skills I’ve been developing, and allowing me to set private keys for giving my agent access to my email. Kicking off jobs and testing the system, I noticed that the behaviour of the runs changed which makes sense. Oz isn’t running Claude Code, it’s running on its own agent scaffolding which means that there’s a bit of an adjustment for my processes to run in their system. The iterations I’ve done to hone my process needs to be redone in their system to make the process reliable and this friction is annoying enough to turn me off of Oz.
While my use case is a largely personal one Oz was developed to solve a range of problems for teams. I’m solving similar concerns these days with Github Actions kicking off Claude Code jobs, pipeline tools like Trigger.dev, or custom LLM apps that can run processes on demand. While Oz offers a convenient interface for teams to use, I’m not sure if I like the process island that they’re forming. Do I really want all of my agentic processes to shift to going through their system? Especially when that might mean refactoring all of my agentic processes to better match their system. It’s enough to give me pause.
Impressive Agentic Feat of the Week
I recently migrated a Squarespace website of over 7,000 pages to a static NextJS app in just 5 hours. I leveraged AI scraping tools to get the raw data, batch LLM jobs for data transformations, and numerous `bun` scripts to extract, transform and load all of the content of the site. I scripted the migration of all of the images to GCS and wrote a simple image manager interface for uploading new content.
I’ve used a number of techniques we’ve been developing with our teams at Rangle and have been inspired by the work we’ve been doing in this space. Working on a handful of real businesses pushing with agentic processes has massively expanded what I thought was possible to accomplish and I’m thrilled I’ve been able to more and more consistently reproduce these great outcomes.
One thing that has become abundantly clear in the work we’ve done is that we’re never aiming to one-shot an outcome. Coming up with a singular perfect prompt doesn’t magically get you great results and I still see a lot of problematic practices with the adoption of agentic “skills” that offer the promise of perfect outcomes from essentially prompts. It seems like two things often produce the best outcomes: knowledge and taste.
When I work to create something with agentic processes I do a lot of shaping. I work at the plan layer multiple times, I run small samples of tests, and I try to shape the result before I let the agent fully attack the problem. That shaping is an active process that does feel slow at times but that ultimately produces a better result than a single run would do. I will actually let it run sometimes too but in those cases the result is a throwaway.
A big reason to throw away large generative work is to avoid being “pulled” by AI rather than being the one “pushing”. Where I’ve left gaps in my ideas, AI will try to fill in. Those helpful adjustments are painful when those details matter and they shift my work from dictating to analyzing to provide feedback. Sometimes this cleanup process is helpful but if you stay in this mode for too long you lose all semblance of structure and intent. You become a servant to the machine.
Planning is the new coding. Approach it with the same intentionality and rigor, and it will reward you well. And as you build, resist the gravitational pull of the SaaS mindset — whether that’s a vendor holding your data hostage or a shiny new tool asking you to restructure your workflows around theirs. The moment you stop owning your data and your process, you’re paying more than just the subscription fee.