Someone on your team has probably said it: “Why do I have to enter this twice?”
Or: “The software won't let me do it that way.”
For years, the answer was often to work around it. Keep another spreadsheet. Copy the information. Train the next employee to follow the same awkward steps.
AI gives us another option. A person who understands the work may now be able to describe a better way and help turn it into a working tool, even without a programming background.
It's a bit of a MacGyver moment. Look at the problem, look at what you have, and find a practical way through it.
But a clever fix raises another question: Should your business own this piece of software once it works?
Keeping that tool useful is part of the decision.
Start with the photos nobody could find
Here's a small example from our own work.
Staff were asked to take photos for the business. They took them, but the photos sat forgotten on personal phones.
We created an app that takes a photo and sends it immediately to the company's Google Drive.
The useful part is simple. Taking the picture and getting it into the company's hands become part of the same action. There is less to remember later.
That is a much clearer problem to solve than “Let's build our own software.” We didn't need to reinvent cloud storage. We needed to close a gap between a person taking a picture and the business receiving it.
Could an existing product or a different setup have handled it? That's a fair question to ask about any build, including ours.
The goal is a better working day. Owning more code is optional.
When the business bends around the software
In another company, staff use a customer relationship management system, or CRM, alongside a separate tool for tracking WSIB information. They enter the same job number in both.
Why twice?
Perhaps the systems can connect. Perhaps the current plans don't allow it. Perhaps somebody needs to check the job before it moves across. Those are things to investigate. I am describing an opportunity, not an integration we have already built.
I've also spoken with an owner frustrated by a rigid, older point-of-sale system. The store's needs have changed, but the owner cannot adapt the software to fit.
Packaged software has to serve many businesses. Yours may handle deliveries, returns or job records a little differently. Over time, workarounds become habits. Eventually, nobody thinks to question them.
Still, an awkward step isn't automatically wasted effort. An approval may prevent the wrong order from going out. A second check may catch an expensive error.
Before removing a step, ask what it protects. Before replacing a system, ask whether the friction is in the whole product or just one part of the process.
What has changed in the last two years?
The distance between describing a small tool and trying it has become shorter.
Back in October 2024, experienced developer Simon Willison documented 14 small tools he made with Claude Artifacts in a week. He reported that most took under five minutes. These were focused utilities, not replacements for a company's core systems.
By February 2025, Anthropic's introduction of Claude Code described tools that could inspect existing code, edit files, run tests and use other development tools. That widened the work an assistant could help with beyond producing a snippet to copy and paste.
There are examples outside traditional development roles too. In a Replit customer story, a Rokt executive says he and a colleague built a compliance-checking app within a day. That's the vendor's account, not an independent assessment of its reliability.
And the effort hasn't vanished. In a Lovable interview about Elora Health, a founder with no coding experience described a month of work, spending more than three hours a day and working through changes that broke things.
That combination matters: more people can try, while testing and persistence still count.
Impressive demos deserve a second look
You may have seen claims about people recreating familiar software with AI.
Nathan Cavaglione's Slawk project is described as a 14-day experiment building a Slack-like application with Claude Code. It's an interesting open-source project. The claim doesn't establish that it matches Slack's security, scale or full range of features.
For a useful reality check, look at PhotoCraft's own project notes. This open-source photo editor explicitly calls itself early alpha and says it is not yet a Photoshop replacement for daily professional work.
These projects make the possibilities easier to see. They also show why “the screen looks familiar” and “we can run the business on it” are different milestones.
How many lines of code can AI write in a minute? I wouldn't use that to make a business decision. More code can mean more to maintain. A short, tested solution may be worth more than pages of code that almost work.
Some small first versions can take minutes or hours. There is no honest rule that weeks of development now always become one hour. Better coding capability also doesn't make every answer or change reliable.
Ask whether the tool completes the job correctly, including the awkward cases.
You have four choices, not two
The decision is often described as “buy or build.” There are two useful steps in between.
Buy. An existing product already does the job well. Use it, learn it and let its provider maintain the common features.
Configure. Your current software may already have the field, form, automation or setting you need. Ask someone who knows it to show you.
Connect. Keep the systems that work and build a small bridge between them. Move the approved job number once, for example, if both products support that connection.
Build. Create a focused tool when the work is distinctive enough, the alternatives fall short, and someone can own the result.
An acquaintance of mine built an easier interface on top of QuickBooks. That's a useful way to think about a bridge: improve how someone works with a system without taking on the whole accounting product. An easier front end still needs correct records, permissions and bookkeeping checks. Available connections also depend on the account, plan and country.
The connection itself needs care. As the practitioner article You Can't Buy Integration explains, buying the systems doesn't make the work between them disappear.
For the CRM and WSIB example, I'd want to know which tool owns the job number, what happens when someone changes it, and how staff find out if a transfer fails. Otherwise, we may simply hide the duplicate work until it becomes a harder problem.
A subscription can still be a good deal
Suppose a tool costs $10 a month and does what you need. Buying it may be the easiest decision you make that day.
Suppose another costs $1,000 a month. That may still be good value if it handles important work reliably, connects properly and gives your team useful support.
Those are hypothetical Canadian-dollar examples, not quotes. The point is to compare the complete cost of getting the work done.
A custom tool can have hosting costs, AI usage charges, repairs and staff time attached to it. Somebody has to test updates, manage access and help when it stops working. A subscription also has costs beyond the invoice, including training and workarounds.
What do you spend either way? What does the business receive in return?
This is the same distinction I explore in AI subscription versus AI integration: access to a tool matters when it changes useful work.
What happens to all those specialist tools?
I've used Glitter AI to record software use and create standard operating procedures, or SOPs. It was a separate paid subscription for a defined job. Glitter's workflow turns recordings into step-by-step guides.
Some of that work can now overlap with a general AI assistant. Give an assistant clear instructions and supported screenshots or recordings, and it may help draft a procedure. For example, Claude's documented “Record a skill” feature can capture a workflow in Cowork for Mac on Pro, Max and Team plans. A reusable skill and a finished staff SOP are different outputs, but parts of the capture and instruction-writing work overlap. Check what your actual product supports, then have someone follow the steps.
My view is that this puts pressure on products built around one narrow feature. A task that once justified another subscription may become something your existing assistant can help do.
But the specialist may still be better at capturing the right steps, keeping guides current, controlling access and supporting a team. Those are reasons to pay.
Software sold by subscription isn't disappearing because AI can imitate a feature. Providers have to keep earning their place in the workflow. So do the people offering to build an alternative.
Look for small possibilities, then test the details
The photo app is one real example. There are other possibilities worth exploring, depending on the business.
A receipt workflow could pull details into Excel or prepare them for accounting review. Before building it, check the product you already use: QuickBooks documents receipt extraction with review and matching. Check the features available in your own account. Reading a receipt isn't the same as recording the right transaction.
A GPS tool could help with distance checks, but it needs testing on the devices and in the places where people will use it.
A food-photo tool might estimate nutrition. Portions and hidden ingredients make that an estimate, not a measurement you should treat as exact.
These are illustrative ideas, not projects I'm claiming we built. Each starts with a possible convenience. Each needs a clear limit and a way to check the result.
Who owns it on Monday morning?
Before a trial becomes part of the business, work through a few plain questions:
- What can our current software already do, and can the vendor demonstrate our actual workflow?
- What does each connection allow us to read or change, and who should have access?
- Who tests the ordinary cases, mistakes, missing information and failures?
- If it stops working, who notices, who fixes it and how does the work continue?
- If the employee who built it leaves, does the business control the accounts, code and instructions?
- Does a small trial show enough benefit after setup, checking and repairs?
Ask current users about their experience too. A polished demo won't tell you everything about support or daily use.
Pick one workflow and record what happens today. Try a small change with a limited group. Count completed tasks, corrections and time spent checking, along with any time saved. Keep a clear way back to the old method while you learn.
The employee who understands the problem can make an excellent guide. They don't have to become the only person who can keep the solution alive.
Bring one frustrating workflow
The opportunity is real. Small businesses have more room to shape how they work, and staff can take part in solving problems they once had to put up with.
That doesn't mean every owner needs to become a software company.
Vendors have something to sell. Consultants do too, including us. Ask either one to show why their proposed option fits your work. A good review may end with a setting change or an existing product.
MacGyver made good use of what was available. That's a useful habit to borrow.
Start with the problem. Use what you have. Build the missing piece when it earns its place.
AI assistance disclosure: This article was prepared with AI-assisted research, writing and editorial review, including a Google Search AI Mode rewrite, using Stephen Lau's reported experiences and the linked sources. Reviewed and approved by Stephen Lau. Illustrations are conceptual AI-generated scenes.