On September 14, Salesforce announced a new Agentforce portfolio organized around jobs such as customer service, employee support, shopping, and back-office work. Its pitch is that companies can start with agents that already have relevant skills, actions, and data models, then tailor them.
There is an availability distinction worth keeping straight. Salesforce lists several agents as generally available, while its Hunter outbound-sales agent is in pilot with general availability planned for November. Hunter is also the first agent using the new runtime for work that extends across days and weeks. That does not make every announced capability available today.
What caught my attention was the starting point: a job that existing software already knows something about.
If you are a beginner with an app idea, this raises an uncomfortable question. Before you ask an AI coding tool to build your business software, have you made an existing tool attempt the actual job?
I studied entrepreneurship before software engineering, and I build apps with AI. I like building things. That makes this question especially useful for me. A working prototype can make a decision feel settled before I have compared the alternatives.
My rule is to earn the custom build with evidence: find one important task that your available tools cannot handle acceptably, then decide whether owning new software is the best way to close that gap.
If describing that task is where you get stuck, my $1 AI App Builder Starter Prompts give you a guided starting point for turning an idea into a first build. Use the exercise below before committing to that build.
Give the existing option a fair attempt
Imagine a fictional freelance studio that wants an AI project-update app. The owner wants to turn project notes into a weekly status update.
An attractive first prompt would be: “Build a dashboard with clients, projects, AI summaries, and email delivery.”
I would start with a smaller investigation. Choose one representative project and write down the required result:
“Produce an update that distinguishes completed work from planned work, includes the latest client decision, and leaves disputed items for my review.”
Now attempt that job with the tools the studio already has. A document, an existing project tracker, and a manual review step may be enough to learn something useful. You do not need a new subscription to begin.
Use three sample inputs: an ordinary week, a week with a changed decision, and a week with contradictory notes. Use fictional or appropriately sanitized material when evaluating a tool that should not receive client information.
Judge the result against the written requirement. A feature list that says “AI summaries” cannot tell you whether the update silently treats a proposed deadline as an agreed one.
Write down the gap precisely
Suppose the existing workflow produces a decent draft, but it cannot distinguish a client-approved decision from an internal suggestion.
That is a useful finding. “I need a better AI dashboard” was a preference. “The update needs an approval state attached to each decision” describes a missing capability.
I would classify each failure before creating a development task:
- A missing setting: the capability exists, and we have not configured it.
- Missing or unclear input: the tool cannot identify approval because our notes never record it.
- A missing connection: the information exists in another tool but does not reach this workflow.
- Missing product behavior: the available system cannot represent or enforce the rule we need.
Those diagnoses lead to different amounts of work. A notes convention may solve the second problem. A supported export may solve the third. The fourth may justify a custom component.
Ask the existing workflow to fail honestly before giving a new app credit for solving it.
Compare three paths on the same task
For the fictional studio, I would consider three options.
First, configure the current tools and keep a person reviewing the draft. This can be a good fit if updates are infrequent and the review is quick.
Second, add a narrow extension that records decision status and prepares the update. Keep the established project tracker if it already handles the rest of the job well.
Third, build a dedicated app because the approval behavior, recurring volume, or required user experience makes the smaller options inadequate.
Give every option the same sample inputs and required result. Record where it fails, what a person still has to do, and what you would have to maintain. For an unbuilt option, label the result as a hypothesis until a small prototype demonstrates it.
This comparison prevents an unfair contest between an existing tool’s real limitations and an imaginary app that has none.
It also keeps you from building an entire project-management system to obtain one approval field.
Count the work after the first demo
In his 2020 AWS essay on build-versus-buy decisions, Gregor Hohpe explains why development cost alone is an incomplete comparison. Time spent creating one system cannot also be spent elsewhere, and writing your own software creates commitments of its own.
My beginner version is to name the recurring chores before celebrating the saved subscription.
Who corrects the source data? Who notices that the update is wrong? Who handles a changed integration? Who helps a new user? Can you return to the manual workflow if the tool becomes unavailable?
Packaged AI also requires this work. Salesforce’s Testing Center documentation describes evaluating responses and actions across scenarios. It warns that tests consume requests and credits and can modify CRM data, so testing belongs in a sandbox.
That is relevant even if you never use Salesforce: obtaining an agent does not complete the job of operating it. For a zero-budget evaluation, write your cases and examine the current workflow first; do not assume a vendor’s test button is free.
I would keep a short list of the chores each option leaves with me. If nobody can own them, the option is not ready to become part of the business.
Set a condition for changing your mind
There is a limitation to starting with existing tools. You can spend too long adapting your work to a system that cannot express the thing customers value.
The answer is to put a limit on the investigation. For this example, I might allow one afternoon to test the three sample inputs and the relevant configuration. If the approval rule still cannot be represented, I would prototype only that missing behavior.
Those are example limits, not universal benchmarks. Your consequence, workload, and available time should determine yours.
Record why you chose the current path and what would make you reconsider. Perhaps manual review becomes too slow. Perhaps a recurring exception becomes the main customer need. Perhaps the existing product adds the missing capability and your extension is no longer worth maintaining.
You are allowed to retire your own clever solution. The repository does not get a vote.
The question I would give AI next
Try this with your actual workflow:
> Compare using my existing tools, adding one narrow extension, and building a custom app for this task: [task]. Use the same required outcome and three representative inputs for each option. Separate configuration problems, missing information, missing connections, and missing product behavior. Mark untested capabilities as unknown. List the recurring work I would own, propose a limited evaluation, and state what evidence would justify a custom build. Start with what I already have; do not purchase or activate paid services.
Choose one task today and attempt it with your current setup. Then write down the first important gap you can demonstrate.
The $1 AI App Builder Starter Prompts can help you turn that gap into a guided first-build conversation. For the organized path from idea through implementation, QA, and publication, my $9 AI App Builder From Zero e-book includes all 40 Starter Prompts as a free bonus inside its PDF and EPUB. You do not need to buy the prompts separately with the book.
Review Radar is coming soon. Its planned public-review research, tailored screens, and AI-ready project folder are intended to help you define a specific app before implementation. Explore the public preview and join the email waitlist. Checkout is not open, and the package does not promise a finished app or revenue.
Build when you can explain the important gap, show why it matters, and accept the work of owning the solution.
You can also find me here:
Medium: https://medium.com/@marcusykim DEV.to: https://dev.to/marcusykim Website: https://marcusykim.com/ X: https://x.com/marcusykim LinkedIn: https://www.linkedin.com/in/marcusykim/ Upwork: https://www.upwork.com/freelancers/marcusykim
Marcus Kim | AI App Builder 