I used ChatGPT from the beginning, and for a while I barely wanted to look at anything else.
I knew how to use it, and I liked it.
Somewhere along the way, that became a reason to dismiss other tools before trying them.
That changed with Claude Design
We hadn't pushed AI on the team at first. But once I started using Claude Design, I wanted our designers to try it.
Keeping the same process simply because it was familiar stopped making sense to me.
I still recommend it for design work.
That doesn't mean I've moved everything to Claude
I like Cowork for automation, especially when it can work with the files and tools on my computer.
Access matters because a task can look straightforward until the tool cannot reach something it needs.
The desktop experience has suited me better.
Cloud access is changing, though. Cowork can now reach connected local files through its desktop app under specific conditions.
My experience shouldn't become a claim that cloud tools cannot do it.
Now Astra has me looking at ChatGPT again
I see a place for it in SOPs, operations, and backend setup.
OpenAI documents computer use and document creation among its capabilities.
I want to test those against the work we actually need finished.
Here's Astra's documentation if you care to read it.
I'm still working out where I'd trust it with changes that affect a live system.
A promising result is enough to keep testing.
From operations, I'd compare the whole task
Give both tools the same brief, then count the time spent checking and correcting their work.
For a designer, that could mean taking an approved brief through to a page ready for review.
For operations, it could mean turning an existing process into an SOP someone else can follow.
The first output is only part of that comparison.
Comparing two tools on the same brief
Same brief to both. Count the whole task, not the first output.
| Task and tool | Time to first output | Time spent reviewing | Time spent correcting | Total | Ready for review? |
|---|---|---|---|---|---|
| Designer · approved brief → a page ready for review | |||||
| Tool A | —— | —— | —— | —— | —— |
| Tool B | —— | —— | —— | —— | —— |
| Operations · an existing process → an SOP someone else can follow | |||||
| Tool A | —— | —— | —— | —— | —— |
| Tool B | —— | —— | —— | —— | —— |
The first output is only part of the comparison. The last three columns are where the difference usually shows up.
Why I'm uncomfortable building custom software for every small need
I like custom software.
In 2025, we had a growing community inside a weight loss company and couldn't find a membership app with the features we wanted.
The business was large enough to consider paying for a custom one.
That was a specific problem worth exploring.
AI makes that option more accessible now, but I'd still want someone responsible for testing, security, and maintenance.
If that isn't solved, you're buying yourself a whole lot bigger problem.
Similarly, with all the "custom" solutions on apps that work perfectly fine
If an existing tool did the job for $15 a month, I'd need a good reason to replace it.
The subscription is easy to see.
The time spent fixing a broken integration is less obvious, especially when it interrupts something else.
An established product can have problems too.
But I'm paying for the product and for a team to maintain it.
What the subscription line hides
Before replacing a tool that already does the job, price both columns.
An existing tool at $15 a month
Easy to see
- The subscription, on the invoice every month
- You are paying for the product and for a team to maintain it
- An established product can have problems too
Custom software you generate instead
Less obvious, and still yours to carry
- Someone responsible for testing
- Someone responsible for security
- Someone responsible for maintenance
- Time spent fixing a broken integration, and whatever it interrupted
Generating the app does not settle testing, security, or maintenance. Someone still has to own them.
How I'd approach agency adoption
For agency adoption, I'd start with a task the team repeats.
Agree on what a finished result looks like, try the tool, and include review time.
I'd also ask the person doing the work where it helped and where it created extra steps.
A tool that helps me might make a designer's day more difficult.
Then I'd decide whether it belongs in that process.
Trying a tool on one repeated task
One repeated task, one agreed result, then decide.
Pick a task the team already repeats
Agree what a finished result looks like
Try the tool on it
Count the review time, not just the first output
Ask the person doing the work where it helped and where it created extra steps
Decide whether it belongs in that process
A tool that helps one person may make another person's day more difficult. Step 5 is where that shows up.
Right now, I'm happy recommending Claude Design, keeping Cowork in consideration, and testing Astra for more operational work.
Originally published on my Substack.