If you have ever delivered a project, you know how it goes. You plan a path from point A to point B. It looks clean on a whiteboard. Then you start, and you run into the stuff that was never on the whiteboard: legacy quirks, a messy data model, an integration nobody documented.
Sorting out those surprises eats the schedule. The end date does not move, and the budget does not grow. If anything, budgets are shrinking while expectations climb. Clients want more for less, and they want it yesterday.
So what suffers? Usually the work we promise ourselves we will come back to. The documentation. The test documentation. The UX review. The final polish. It is easy to push to later, and later rarely comes. We still do good work, and we still (hopefully) ship on time. But some of that deferred work turns into technical debt and future headaches we never meant to leave behind.
The cheap-AI mistake
A lot of companies look at AI as a shortcut to do the same work for less time and money. That can be a mistake if you do not fill the gaps. Point AI at the same manual process and change nothing else, and you are not improving the result. At best, you are delivering the same outcome a little faster.
Used well, it does something more useful. It clears the repetitive work off your plate so you can spend your attention on the strategic and lingering tasks, the ones that never made it into earlier projects. Set up the right rules and AI handles the documentation and writes the test cases for you. You are not the one writing the artifacts anymore. The system produces them as you go.
Here is the part the hype skips. Some of the work gets longer, not shorter. You spend more time up front, not less, documenting and mapping the reality of the system before building. The gains show up later, in execution, in documentation, and in tweaks.
The expert and the AI
This is why the fear of AI wiping out expert jobs misses the mark. AI still needs an experienced human in the loop to do its best work. It has breadth, but it has no scar tissue. It has not sat in the meeting where the requirement changed three times. It does not carry the pattern recognition or the list of traps you only pick up by shipping real projects and watching a few of them break.
Pair an experienced practitioner with AI and you get something neither produces alone. The human brings judgment, spots the architecture that will not hold, and knows the legacy integration that breaks under load or the automation that fires twice. The AI runs the tireless first pass, drafts the inventory, and keeps the documentation current as the work changes. It can smoke test, and it can write a thorough test plan with expected outcomes for your QA team to run. It can produce a separate plan for the client to use during UAT, since the client does acceptance testing, not QA. Set it up correctly and the documentation updates itself as the requirements move.
This became clear to me recently. Salesforce announced a platform shift they call Headless 360 and backed it with an official hosted MCP server. In plain terms, they opened a secure path to the org's API: configuration, data CRUD, Apex and code pushes, queries. You can drive it from a connectable LLM like Claude or Gemini, an AI-powered IDE, or an app like Slack, without ever opening a browser.
Reactions came in quick. A thoughtful LinkedIn post from a GTM architect described his team rolling the official MCP out to non-engineers. The comments positioned the new tooling as great for in-house teams and a quiet worry for consultants. I read it the other way. For implementation consultants, this is an opportunity, not a threat.
Around the same time, Saltbox launched S1. Saltbox Mgmt is a Salesforce consultancy, and S1 is the tool they built for themselves and then turned into a product. It is a shared intelligence layer: it connects to your org and the systems around it, like Jira, Slack, and Google Workspace, learns from your meetings, tickets, and docs, and produces real outputs like documentation, code, user stories, and diagrams. It is a serious piece of work, and for a lot of teams it is a smart way to buy that capability.
I went a different direction, and the difference is the interesting part. S1 is one central brain that compounds knowledge across every client it touches. What I built is the opposite: an isolated context per client, deliberately kept apart. Both are real bets on the same question, whether client knowledge should mix or stay separate. Neither is the universal right answer. Mine goes against the grain on purpose, because I know every client project will need to take its own shape.
When a web app is the right tool, and when it is not
When teams see this kind of leverage, the first instinct is to build a polished, multi-tenant web app. Sometimes that is exactly right. If you are selling a standardized service to a large audience that wants zero setup, a web app wins.
For our world, running many client projects at once, a single web app is a trap in this scenario. To make one app serve everyone, you have to build a mountain of plumbing: parsing pipelines, search databases, multi-tenant security, and logic to decide which model or persona to pull in for each request. You also have to decide how trust works. Authenticate against a client org inside a shared app and either that access is exposed to everyone, or you build more machinery so each person works in their own bubble. It becomes a roadmap bottleneck, and the AI gets confused trying to be everything to everyone.
A simpler path: the sidekick
So I went the other way to see whether a simpler shape would hold up. I built a forkable starter pack, kept local-first, called a sidekick. It starts from a strong, shared base in our company GitHub: the skills, processes, expectations, and markdown that say how we work and what we expect.
You fork it once per client. Each fork takes the exact shape the project needs. Each fork is its own isolated context for that client, so there is no mixed data. Because the AI runs locally in the practitioner's IDE on existing credentials, there is no new third-party cloud holding client data. The trust question answers itself: the people on that engagement share that fork, and nobody else does.
A fork also comes with governance for free. Git log is the audit trail. A pull request is change control. When a teammate finds a sharper rule, they commit it back to the base, and the next project starts a little better than the last. The tool grows with the team instead of waiting on a product roadmap.
How the work flows
None of this requires a big team. One person can take a project start to finish in a single fork. But it also works the way a normal delivery team works, with everyone in the same repo:
- Project Manager: Seeds the fork with the promise we made (usually the SOW), meeting notes, and early documentation so the AI has real context to learn from.
- Discovery: We connect to the org and pull the current state of the union, which matters most when inheriting something another firm built and needing to understand what is there.
- Architect: Plans the solution, and the documentation gets written as that plan takes shape.
- Developer: Executes the build and runs dev tests.
- UI/UX: Walks the real experience and flow.
- QA: Runs full end-to-end testing.
- Feedback Loop: QA and UAT findings feed back into the repo for the next pass, and we go around again.
Every step lives in the same place. The repo is the shared brain of the project, so the next person picks up where the last one left off instead of starting cold.
This is bigger than Salesforce
None of this is Salesforce-only. It is the same pattern for marketers, designers, coders, lawyers, accountants, and analysts. The job at risk is not the consultant. It is the part of any job that lived entirely in manual grunt: the inventory spreadsheet, the setup clicks, the first-pass draft, the same query run for the third stakeholder this month. That work was never the part clients remembered, and it no longer has to be done by hand.
Use AI to amplify your best qualities (your judgment, taste, craft, and planning) and your work gets better and your footing gets stronger. Use it only for speed, and you risk shipping slop, and your reputation can pay for it. Refusing to engage at all is its own choice, and not a safe one, because you end up competing on hours against people whose hours now go further than yours.
We are a few weeks into beta testing this with a couple of teammates on a few newer projects, so it is too early to call the outcome. But the early signs are encouraging. The beta users see the vision, and they are getting quick wins that let them work differently than they could before. That is enough to suggest we are onto something. The goal is not doing the work cheaper. It is finally finishing the parts we always meant to.
The tools will not kill this kind of work. They can change what good looks like, for the teams willing to carry the heavier planning up front. The budget may shrink and the expectations will climb. Done right, the work you leave behind can still come out ahead.