There’s a version of this story where the headline is the speed. The speed is the least interesting part. What matters is whether the thing you just built gets used, or quietly joins the pile of apps nobody opens.
The Shift
The gap between needing a tool and having one just collapsed
I built a working inventory dashboard last week. I described what I wanted in plain English, an AI agent wrote the code, set up the environment, and put it live. No terminal. No brief. No budget meeting. No sitting in a developer queue. Start to finish, about twelve minutes.
That used to be a project. Now it’s an afternoon, often less.
The tool I used was Replit, a browser-based build environment with an AI agent sitting inside it. You describe the problem, it writes the code, fixes its own errors, and ships a live version. Nothing to install. You don’t write a line yourself. You just need a clear description of what you’re trying to solve. It isn’t the only tool doing this, but it’s the one I keep coming back to.
|
The Old Way A multi-week project. You scope it, a developer estimates it, you approve the budget, they build, you review, they revise, it ships. Thousands of dollars and a couple of months, gone. |
The New Way A clear prompt and an afternoon. You iterate live, watching it change as you talk. The running cost sits in streaming-subscription territory. The distance between “I need something that does X” and “the thing that does X is live” is basically zero. |
Worth Building
Most of what you could build isn’t worth building
The speed makes everything tempting, and that’s the trap. The builds that earn their place have two things in common, and the toys never do. They plug into data you already hold, and they take an action you can actually watch happen.
Four that I’ve seen pay for themselves:
01 · Interactive trade pack. Lives in the browser. Your team actions each item, and you can see what’s been picked up, what’s been done, and what’s been ignored. The status meeting that used to burn an hour mostly runs itself.
02 · On-brand image generator. Pulls your own product data and brand guide, then produces campaign and product imagery on demand. Compresses briefing, shoots, and edits from weeks down to hours.
03 · Live inventory and margin view. Connects to your store and shows you daily which SKUs are bleeding margin and which are about to run out. Something you open every morning, not a spreadsheet someone updates by hand on a Monday if they remember.
04 · Returns and complaints triage. Pulls live order and returns data, drafts the response, routes it, and tracks it through to resolution. The highest-volume, most repetitive job in retail, mostly handled.
Notice the pattern. Every one connects to real data and produces a visible action. None of them are won or lost on the build itself.
One caveat worth holding onto: build these on stable, widely available models, not whatever frontier release dropped last week. The most capable tool you tested can disappear by Monday, by policy or by outage. Anything your team depends on needs a foundation that’s still going to be there.
Where It Dies
The graveyard of apps nobody opens
Here’s the part that never makes it into the demo. I’ve watched teams get excited, build ten tools in a fortnight, and end up with a pile of apps in the cloud that nobody touches. Plenty of activity. Nothing actually used.
The build was never the hard part. The judgment around it is the whole game.
Three things decide whether you end up with a tool your team lives in or one more abandoned tab.
01 · Map the process before you build it. If you don’t understand the real workflow, the steps, the exceptions, who touches what, you’ll automate a mess and ship it faster. Map it first. Every time.
02 · Solve the boring problem, not the flashy one. The exciting build is rarely the valuable one. The valuable one is the dull, repetitive task quietly eating hours of your team’s week. Find that, then build for it.
03 · Make it invisible. If the tool is harder to use than the spreadsheet it replaces, your team goes back to the spreadsheet. The best internal tools are the ones nobody notices they’re using.
The Real Opportunity
The 80% that was never worth a real build
The sweet spot isn’t the big custom platform. It’s the eighty percent of internal tools that have lived in spreadsheets and email threads for years because they were never worth a developer’s time or a real budget line. That’s the category that just changed.
The build stopped being the constraint. Which means the constraint is now you, and whether you can see the right problem clearly enough to point the tool at it.
If you want help working out what’s actually worth building, and making sure your team uses it instead of abandoning it, that’s the work we do. We map your operations, find the highest-value build, and pressure-test the process and the experience so it doesn’t end up in the graveyard. Start the conversation here.
