GaneevEcoWhat we've seen teams actually build
The pattern across successful examples is remarkably consistent: someone had a specific, recurring annoyance, and instead of filing a ticket and waiting weeks for an engineering team's attention, they described the problem to Claude and had something working within an afternoon. None of these tools were ambitious in scope — that's precisely why they succeeded quickly.
- A finance analyst's own margin calculator, built in an afternoon instead of waiting on a BI team ticket that would have taken weeks to even get prioritized.
- An HR onboarding checklist tool that tracks progress per new hire without touching the HRIS or requiring any IT involvement to stand up.
- A sales rep's quick quote estimator for a rep who used to redo the same spreadsheet math by hand on every single call, losing several minutes of momentum each time.
The catch worth knowing upfront
Artifacts built this way are personal or team tools, not production systems — they don't inherit your company's access controls or data governance automatically the way an officially provisioned internal application would. Good for solving a real problem fast; the wrong place to put anything with sensitive data or a compliance requirement attached, without review first from whoever owns that responsibility in your organization.
This distinction matters because the tools that get built this way tend to work so well that people quietly forget they're informal. A calculator someone built for their own use in an afternoon can become the tool an entire team quietly relies on within a month, with nobody in IT aware it exists or what it depends on. It's worth having a light process for "graduating" a genuinely useful Artifact into something IT is formally aware of, rather than discovering it's load-bearing for a whole team only after the person who originally built it changes roles or leaves.
How to get your first team using this well
The teams that adopt this fastest usually start from a concrete, specific complaint, not an abstract pitch about the capability. Ask what spreadsheet or manual process people already actively dread doing, and build the first Artifact around exactly that particular pain point. Trying to explain the general capability first — "you can build tools now" — lands far less effectively than showing one person's actual daily annoyance transformed into something that works in twenty minutes right in front of them.
Once one person on a team has a working example they can point to, adoption tends to spread horizontally rather than needing any top-down encouragement or formal training push. Colleagues see a coworker's tool solving their own version of the same underlying problem and ask to build one for themselves — that peer-to-peer spread is usually a far stronger and more durable adoption signal than any formal announcement or training session could produce.
A light but genuinely useful practice worth adopting early: keep a simple shared list of who built what, even informally in a chat channel or a shared document. It costs almost nothing to maintain and pays off directly the first time someone asks "has anyone already solved this?" before spending an afternoon rebuilding something a colleague on another team quietly finished last month.