You can't automate a consulting workflow without new software by buying smarter software. The mechanism has to change.
Direct answer (verified 2026-05-01)
Use a computer agent that reads your screen and types into the apps you already open every day, instead of an iPaaS (Zapier, Make, n8n) or a suite (HoneyBook, Dubsado) that you would have to migrate to. iPaaS and suites ARE new software, even when the marketing says “use your existing tools.” You still learn a new builder, store new state in their database, and lose access if you stop paying. The mechanism that genuinely doesn't add a new app to your daily flow is screen-driving from a plain English instruction file, what Clone's architecture diagram labels the “Clone Computer Agent” layer.
Type “automate consulting workflow without new software” into any search engine and the answer page sells you new software. Zapier sells you Zapier. n8n sells you n8n. HoneyBook sells you HoneyBook. The consulting firms on the first page sell you a custom-script project that bills five figures and ends with a maintenance contract. Even the no-code listicles all amount to: install one of these ten tools.
The reason every page reframes the question is that “no new software” is mechanically hard. To automate something on your existing stack, something has to fire the trigger, read the data, and write the output. If that something is an iPaaS, you've added a new daily surface. If that something is a suite, you've replaced part of your stack. If that something is a virtual assistant, you've added a person on a payroll. There is one mechanism left that doesn't add either a tool or a person, and almost nobody writes about it: a background process on your computer that drives the apps you already have, the way you would.
This page names that mechanism, walks one execution end to end, and shows the row in the comparison table where the iPaaS approach quietly breaks. The argument has four moves: what counts as “new software,” why iPaaS isn't the answer even though it claims to be, what screen-driving actually does when an event fires, and what happens to your stack the day you stop paying.
“Clone's architecture.tsx ships a six-layer stack, three of which are explicitly tagged 'Clone layer (removable)' in the rendered legend. The top layer is You. The bottom two are Your Apps and Your Business. Remove the middle three and your business still runs from the same Gmail, CRM, and QuickBooks accounts.”
Source: src/components/architecture.tsx, lines 5-65, with the legend at lines 126-129. Verified 2026-05-01.
The category split
What counts as “new software,” honestly.
The phrase “without new software” sounds binary, but it's actually four overlapping categories. Most automation pages exploit the overlap to claim a category they don't belong to. Here is the honest sort.
1. Suites that replace pieces of your stack
HoneyBook, Dubsado, Bonsai, Ignition. They own the proposal, the contract, the invoice, the client portal. The deal is: hand us your back office, get one cadence in return. They are the most obviously “new software” on this list. Anyone selling them as “no new software” is selling you a migration.
2. iPaaS / workflow builders that wire your existing apps
Zapier, Make, n8n, Power Automate. They don't replace your apps; they connect them over APIs. So they market themselves as “use your existing tools.” The trick is: you still log in to Zapier. You still learn the trigger-action-filter-branch language. You still build flows in their canvas, store the flow definitions in their database, and lose every flow if you cancel. They are net-new software with a tactful marketing line.
3. Custom scripts written by an automation consultant
A boutique consultancy writes a Python script, a Google Apps Script, a few SQL views. Those technically run on your existing tools. But the maintenance contract is the new software, and the scripts go stale the moment Gmail changes a UI element or HubSpot rotates a field. The bill compounds.
4. A computer agent that drives the apps you already have
Software that runs as a background process on your machine, reads what is on your screen, and types into the same Gmail tab, the same CRM tab, the same QuickBooks tab you already had open today. The instruction lives in a plain text file you own. There is no separate dashboard to log into and no flow definition to lose. This is the only one of the four that delivers the literal promise.
When this guide says “without new software,” it means category 4, not categories 1, 2, or 3 with a softer marketing voice.
The iPaaS objection
The strongest objection: “Zapier already does this.”
The case for iPaaS sounds clean. You already pay for Gmail, HubSpot, QuickBooks. Zapier connects them. The data lives in your apps. The workflow definition just stitches them together. So why isn't this the answer?
Three reasons, in order of how much they bite.
A. The trigger surface is too narrow
Most useful consulting events are content events, not API events. A milestone signoff phrase in a client's email. A proposed budget number in a Zoom transcript. A specific paragraph in a SOW you uploaded to Drive. None of those fire a webhook. APIs don't see them. A Zap can't branch on them, because the data isn't in the API surface; it's in the screen the human reads. The Zaps that fire on clean events (a Stripe payment, a DocuSign signature, a Calendly booking) work fine. The Zaps that should fire on content events have to be either skipped or rebuilt as a fragile chain of email parsers.
B. The daily surface is still new software
Even on the events Zapier handles cleanly, you log into Zapier when a Zap fails. You read Zapier's logs. You learn Zapier's if-this-then-that grammar. You debug Zapier's rate limits. The fact that no data lives there in steady state doesn't change the fact that the troubleshooting and maintenance happen there. “No new software” in the literal sense means no new daily surface. iPaaS adds one.
C. Custom and legacy apps don't have a published API
This is the row that quietly fails. Many consulting practices have one or two apps that aren't wired into Zapier's catalog: a niche bookkeeping tool from 2014, a client's in-house Salesforce instance with custom objects, a vertical SaaS for that one industry, a browser-based portal a client requires you to use. iPaaS can't touch them. A Zap can't click a button on a portal page. A computer agent can. Clone's shipped comparison row “Works with custom or legacy apps” is a check on Clone, an X on Zapier, an X on HoneyBook, and a check on a virtual assistant. The mechanism that handles arbitrary apps is the one that drives the screen, because the screen is the universal interface.
iPaaS is the right answer for clean-trigger, well-published-API workflows: a webhook fires, a row is created, a notification posts. It is the wrong answer for the consulting back office, where the events are content and the apps are mixed.
The mechanism, executing
What “no new software” looks like, step by step.
Below is one execution. The setup happened once on Day 2: a five-line markdown file at ~/.clone/memory/invoice.mdthat says, in plain English, “when an inbound email matches a milestone signoff phrase, draft an invoice in QuickBooks for the SOW amount, ping me on Slack to approve.” That is the entire configuration. The screens it touches are screens you already opened today.
What 'no new software' looks like when an invoice loop fires from an inbound email
Notice what is not in the diagram. There is no Clone dashboard. There is no Zapier canvas. There is no HoneyBook portal. The agent reads your inbox the way you would, opens your QuickBooks tab the way you would, types the line items the way you would, and pings you in the same Slack DM thread you already use for approvals. The configuration lives in a text file in your home directory; the daily surface is the same one you had before you installed it.
Your stack, untouched
The apps that stay exactly where they are.
Every app on this list is one your accountant, your clients, or your team already knows how to find. The agent operates them in the background using your existing browser session and your existing credentials. None of them get migrated, mirrored, or replaced.
Gmail
the inbox you already check first thing every morning
Google Docs
the proposals and SOWs you've been writing for years
Google Sheets
the dashboards and trackers you wired up yourself
Zoom
the call tool your clients already prefer
HubSpot
the CRM with five years of contact history in it
Pipedrive
or whichever CRM you actually log deals in
QuickBooks
the books your accountant has already memorized
Stripe
the payment processor your invoices link to
Calendly
the booking link you've been sharing for two years
Slack
the team channel where approvals already happen
Notion
or your wiki of choice for engagement notes
DocuSign
the contract signature flow your clients know
The first week
What changes day by day, and what doesn't.
The day-by-day reads short on purpose. The point is what is missing from it: there is no migration, no onboarding session, no admin training, no new login, no workflow builder. The work happens against the apps you already use.
- 1
Day 1: install Clone, open nothing else
Clone runs as a background app on your machine. You don't open a workflow builder. You don't pick triggers from a dropdown. You don't migrate any data.
- 2
Day 2: write one instruction file
In a plain text file (~/.clone/memory/post-call.md is the canonical first one), describe one repeating task in plain English: what fires it, what to look for, where to put the output. Save the file.
- 3
Day 3: watch it run on your existing stack
After your next Zoom call, Clone reads the transcript, opens your CRM tab, types a contact note, drafts a follow-up email in Gmail, and pings you in Slack to approve. No tab you didn't already have open today.
- 4
Day 7: edit the file when your style changes
You don't open a settings page. You edit the markdown file in TextEdit. The next event uses the new behavior. The instruction file is the source of truth, not a vendor's database.
The counter-argument, answered
“What if I uninstall Clone tomorrow?”
The question every consultant should ask before installing a back-office tool. The answer for HoneyBook is: you migrate everything out of HoneyBook. The answer for Zapier is: every flow you built is gone, and any data Zapier was buffering is gone with it. The answer for Clone is supposed to be different, because the architecture file says so. Here is the test you can run yourself, on the same source files that ship the homepage.
Three things land. The legend “Clone layer (removable)” ships in the rendered architecture diagram. The architecture file contains zero instances of the words “replace,” “migrate,” “database,” or “export your data,” because there is nothing to migrate or export; your data was already in your apps. And the credentials Clone uses are your credentials, in your browser session, against your Gmail, your HubSpot, your QuickBooks. Cancel the subscription on a Friday and your business runs on Monday from the exact same accounts and the exact same files, with one fewer background process running.
This is the test the iPaaS and suite categories fail. They can't pass it, because their architecture requires you to put data or workflow definitions inside their product. Cancel HoneyBook, your invoice templates die. Cancel Zapier, your Zaps die. Cancel a screen-driving agent, the markdown files in ~/.clone/memory/ stay on your disk and your apps stay where they were.
Resolution
Where this leaves you.
The literal phrase “automate consulting workflow without new software” has a literal answer. It is not “buy a smarter Zapier.” It is not “hire a consultant to write Apps Scripts.” It is not “migrate to a suite that reframes the question.” It is: run a background agent on your computer that operates the apps you already have, configured by a plain English file you own. That mechanism is the only one of the four categories that doesn't add a new daily surface, doesn't require a migration, and doesn't fail on the custom or legacy apps every consulting practice ends up with.
If you want to test the claim before you trust it, the architecture file is open: read src/components/architecture.tsxand search for the word “removable.” If you want to start small, write one instruction file for the post-call admin loop and watch it close that loop end to end without you opening a tab you weren't already going to open. If you want to talk through the specific loops in your practice and which ones genuinely close on this mechanism vs. which ones don't, the booking link below is the right next step.
Walk through your stack on a 20-minute call.
Bring the apps you already use. We'll map which loops close on screen-driving alone and which want a different shape.
Frequently asked questions
Why does this question matter? Don't all automation tools use my existing apps?
Most claim to, but the claim hides a category split. iPaaS tools (Zapier, Make, n8n) connect to your apps over APIs, but the daily flow happens inside their builder, their dashboard, their alerts. You log in to Zapier every time something breaks. You learn Zapier's branching language. Suites (HoneyBook, Dubsado, Bonsai) replace pieces of your stack outright. A virtual assistant uses your apps but on a person's clock. The category that genuinely doesn't add a new daily app is screen-driving software that runs in the background and operates the apps you already had open. The phrase 'without new software' only has one honest answer in that sense.
Isn't Zapier 'no new software' since I already use the apps it connects?
Zapier IS new software in the way that matters. You sign up for it. You learn its trigger-and-action vocabulary. You build Zaps in their canvas. You log in to the dashboard when something breaks. You pay them every month. If you cancel, every workflow you built dies. The fact that the data flows into Gmail or HubSpot at the end doesn't change that the workflow lives inside Zapier's product surface. The same is true of Make and n8n. They're better than buying a suite, but they are still net-new tools you maintain forever.
What's the actual mechanism of 'no new daily app'?
Screen-driving. The agent runs as a background process on your computer. When an event fires (an inbound email matches a phrase, a calendar time hits, a deal stage moves), the agent opens the app you already have, reads what's on the screen, types into the form fields, and clicks the button you would have clicked. It uses the same Gmail account you check every morning, the same HubSpot workspace your contacts live in, the same QuickBooks file your accountant uses. The instruction lives in a plain text file you own. Clone's architecture.tsx labels this layer the 'Clone Computer Agent' with the sublabel 'Reads the screen, clicks, types, scrolls.'
How is screen-driving different from a Zapier graph that ends in Gmail?
Two big differences. First, the trigger surface. A Zap needs a clean event that fires on an API webhook (a button click, a calendar event, a Stripe payment). Screen-driving can fire on content (a phrase in a Gmail thread, a number in a Zoom transcript, a paragraph in a SOW). Most consulting workflow events are content events, not API events; that's why Zaps tend to break on the most useful triggers. Second, the daily surface. A Zapier graph asks you to log into Zapier when something breaks. A screen-driving agent has no separate dashboard you have to learn. The 'config' is a markdown file in a folder on your machine.
Where's the proof that Clone is actually 'removable' as the architecture claims?
Three places. (1) Your data lives in your apps, not Clone's database. There is no Clone database. The instruction files live in a folder on your machine (~/.clone/memory/) and you can delete them or read them in TextEdit. (2) Your accounts are your accounts. Clone signs in to Gmail, HubSpot, and QuickBooks the same way you do, with your credentials, in your browser session. Cancel Clone tomorrow and your accounts still have everything: contacts, notes, invoices, threads. (3) The architecture file labels the legend explicitly. Three layers (Planner, Computer Agent, Memory) are tinted as 'Clone layer (removable).' Three layers (You, Your Apps, Your Business) are tinted as 'Your existing stack.' The diagram is what ships on the homepage.
What about API integrations? Don't I want first-class API hooks?
You want them where they exist and work. Screen-driving doesn't reject APIs. It uses them when they're cleaner (a Stripe webhook on payment is fine; a HubSpot deal stage move is fine). It falls back to the screen when the API can't see what you can. Most consulting events are in the latter category: a milestone signoff phrase appears in an email, a proposed amount is mentioned in a Zoom transcript, a SOW expected number is in a Drive doc. APIs don't see those. The screen does. The honest line is: prefer the API when it works, and have a screen-driving fallback for the events your APIs miss.
Will it work with the custom or legacy app I have to use for one client?
Yes. This is the row in Clone's comparison table that quietly fails on iPaaS: 'Works with custom or legacy apps.' Zapier needs a published API. So does Make, so does n8n. If your client has a 2014-era practice management portal, an internal Salesforce instance with custom objects, a niche bookkeeping tool with no public API, or any browser-based app at all, an iPaaS can't reach it. Screen-driving can. The agent treats every app the same way: it reads the screen, types into fields, clicks buttons. Custom and legacy apps look exactly the same to it as Gmail does.
What does the daily setup look like? How long until it's running?
Realistic timeline: install Day 1, one instruction file Day 2, watch it run on Day 3, edit the file as your style changes from Day 4 onward. The first instruction file most consultants write is post-call admin: when a Zoom call ends, summarize the transcript, log the contact in HubSpot, draft a follow-up email in Gmail. That single file pays back inside the first week. By week four, most consultants have four or five files, each closing one recurring loop. None of those days involve learning a new dashboard, migrating any data, or signing into a new tool other than the Clone background app itself.
What's the price comparison vs. Zapier and a virtual assistant?
Clone is $49/month for solo, $129/seat for boutique firms, free 14-day trial without a credit card. Zapier is $49 to $599/month depending on volume and apps. HoneyBook is $39 to $129/month and replaces pieces of your stack you didn't ask to replace. A part-time virtual assistant is $3,000 to $6,000/month and works on their clock, not yours. The cost compounds differently: with iPaaS or a suite, you're paying for a tool you log into. With screen-driving, you're paying for a background process. The marginal hour cost on the four or five fuzzy-trigger loops in a typical practice is roughly 50x lower than a VA, and the daily friction is roughly zero, since there's no new daily surface to learn.
What's the smallest version I can run this week?
Pick one recurring task that has been costing you time, then write one plain English instruction file for it. Post-call admin is the canonical first one because it fires several times a day and the win is visible inside 24 hours. The instruction file looks like a memo: 'When a Zoom call ends, read the transcript. Find the action items. Log the contact note in HubSpot. Draft a follow-up in Gmail using my voice from the last five emails I sent to this person. Send me a Slack DM with the draft.' Save the file. The next call closes the loop end to end without you opening a tab you weren't already going to open.
Keep reading
Automate Consulting Back Office
The four mechanical shapes of 'automate' (Replace, Glue, Delegate, Drive) and the seven canonical consulting loops mapped onto them. Companion piece on which shape closes which loop.
Consulting Workflow Automation
Why Clone refuses to ship a 'pre-sale outbound' feature, what a grep of features.tsx returns, and what it means to start automation at 'deal won' instead of 'cold click.'
Consulting Back Office Automation
The seven loops in a real consulting practice, named, with their close windows, decay rates, and the handler files that close them on their own clocks.