Skip to content
Architecture

Five questions to ask any Salesforce development partner before you sign

By the Agentic Labs team · APR 2026 · 5 min read

An illustrated checklist of five diligence questions beside a magnifying glass reviewing a Salesforce development contract.

Draft · for internal review

Choosing a Salesforce development partner is one of the higher-consequence decisions a business makes about its own systems. The wrong choice does not fail loudly on day one. It shows up months later as brittle automation, an unmaintainable data model, and a backlog of rework that costs more than the original build.

The market has also gotten noisier. Some vendors staff engagements with a rotating bench of junior developers and bill you for the learning curve. Others now lean hard on AI, promising speed while quietly shipping generated code that no senior engineer has actually read. Both problems are hard to see in a polished sales call.

The five questions below are the ones that surface who you are actually hiring. None of them require you to be technical to ask. What matters is whether the answers are specific and confident, or vague and rehearsed.

1. Who actually writes the code?

Why it matters. Many agencies win the deal with a senior architect in the room and then hand delivery to whoever is available on the bench. You end up paying senior rates for junior work, and you inherit the consequences long after the engagement closes.

What a good answer sounds like. A named person, or a small named team, with the experience level stated plainly: certified architects and senior developers who own the work end to end. A strong partner can tell you who will be in your org, what they have built before, and who reviews their work — without checking who is free that week.

If the answer is a generic "our delivery team" with no names and no seniority, treat it as a bench in disguise.

2. How do you use AI, and is our org data safe?

Why it matters. AI tooling can make a senior engineer dramatically faster. It can also be used to paper over a lack of expertise — generating code nobody on the team fully understands, or sending your org's data and schema to tools with unclear retention terms. You need to know which of those you are buying.

What a good answer sounds like. A clear line between what the AI does and what the human does: the AI accelerates the mechanical work — scaffolding, boilerplate, first-draft code, test stubs — while a senior engineer makes every design decision and reviews every line that ships. On data, expect specifics: which tools, configured so your data is not used to train third-party models, scoped to the minimum access required, with retention and handling terms your security and legal teams can review.

Vagueness here is the warning sign. "We use AI to move fast" is a slogan. "Here is exactly where AI touches your data, and here is what it never does" is a policy.

The right partner is not the one who promises the most speed. It is the one who can tell you exactly where speed comes from — and where a human still has to own the call.

3. Will you work inside our existing org?

Why it matters. Most Salesforce work is not greenfield. You have an org with history — existing automation, customizations, integrations, and admins who know where the bodies are buried. A partner who ignores that context tends to rebuild rather than integrate, creating duplicate logic and new technical debt on top of the old.

What a good answer sounds like. A discovery-first posture. A good partner wants to understand your data model, your existing Flows and Apex, and your release process before proposing anything. They plan to work with your in-house admins and developers, follow your source-control and deployment conventions where they exist, and leave your team able to own what gets built.

Be wary of anyone who quotes a firm price before they have looked inside the org. It usually means the number is a placeholder they intend to revise once reality intervenes.

4. What does your code-review and testing process look like?

Why it matters. On the Salesforce platform, discipline is not optional dressing — it is what keeps a deployment from breaking production. Source control, peer review, and test coverage are the difference between a change you can trust and a change you hope works. This is also exactly where AI-generated code needs the most scrutiny, because it can look correct and still be wrong.

What a good answer sounds like. A concrete process: work lives in source control, every change is peer-reviewed by a senior engineer, tests are written and meaningful rather than padding to clear a coverage number, and deployments move through staged environments rather than straight to production. Crucially, AI-generated code is held to the same review bar as hand-written code — no exceptions.

If a vendor cannot describe how a change gets from a developer's laptop to your production org, they do not have a process. They have a habit.

5. What happens after launch?

Why it matters. A build that ships and then goes dark is a liability. Salesforce releases three times a year, your business changes, and undocumented work becomes unmaintainable the moment the people who wrote it are gone. What happens after go-live often determines whether the investment compounds or decays.

What a good answer sounds like. A real handoff — documentation, knowledge transfer, and a clear plan for who owns what once the engagement ends. If you want ongoing help, a good partner offers it as an explicit option: release management, technical-debt paydown, and continuous optimization, priced transparently. Either way, your team should be able to operate what was built without depending on the vendor to keep the lights on.

"We'll be around if you need us" is not a plan. Ask what documentation you receive, and what the first month after launch actually looks like.

Putting it together

You do not need to run a technical interview to protect yourself. Ask these five questions, and listen for specificity. A senior partner answers with names, processes, and clear boundaries around where AI helps and where human judgment takes over. A weaker vendor answers with adjectives.

The goal is not to catch anyone out. It is to make sure the confident, capable team you met in the sales call is the same team that will be in your org — and that the tooling they use is leverage for their expertise, not a substitute for it.


The Agentic Labs team
Certified Salesforce architects and senior developers

Agentic Labs is a senior-only Salesforce development practice. We use agentic AI as leverage for our engineers — the AI does the typing, judgment stays human — across custom development, integrations, and Agentforce builds.

Keep reading

Related insights.

AI Practice

AI-accelerated, not AI-generated

Where agentic tooling belongs in a serious Salesforce build — and where a senior engineer still has to own the call.

MAR 2026 · 6 min read

Read →
Agentforce

Agentforce vs. traditional automation

When an agent earns its place over a Flow — and the questions to ask before you build one.

FEB 2026 · 8 min read

Read →

Asking the hard questions? Good.

Put these five to a senior architect on our team. You will get specific answers, and a scope before you commit to anything.