How to Choose a Salesforce Development Partner

Evaluating a Salesforce consulting partner is hard. Evaluating a Salesforce development partner is harder.

A CTO or IT director reviewing a proposal for custom Apex, a set of Lightning Web Components, or an AppExchange managed package faces a problem the proposal won't solve: you usually can't read the code. You can't tell from a slide deck whether what gets built will be clean, maintainable, and architected to survive Salesforce's three releases a year. The partner who wins the proposal isn't always the one who delivers the result.

Most buyers sense this and still evaluate on the wrong signals: price, total certification count, and case study logos. They rarely ask about test coverage standards, governor limit architecture, security review history, or who will actually write the code. Those questions separate a code shop from a real development partner, and most buyers only learn to ask them after one bad engagement.

This article is a framework for picking the right Salesforce development partner: which credentials signal genuine capability, how to judge expertise across the Salesforce clouds your build touches, what to ask at the proposal stage, what long-term support should look like, and the red flags that are easier to catch early. It's written by MagicFuse, a Salesforce development company and certified Product Development Outsourcer (PDO) with an AppExchange portfolio spanning ISV products, managed packages, and enterprise custom builds.

Read also: For a curated list of firms rather than a framework, see our Top 20 Salesforce Development Companies guide. This piece is about how to evaluate the partners you're already talking to.

Key Takeaways

• Most Salesforce work is configuration. Custom development means writing code: Apex, Lightning Web Components (LWC), and managed packages. It needs a different way to evaluate a partner.
• PDO status is the strongest single credential for development-heavy work. Salesforce has independently verified the partner can build production-grade managed packages, not just configure the platform.
• Match the partner to the Salesforce clouds and the industry your build actually touches, and to the specific developers who will write your code.
• A serious proposal names the technical team, sets code-quality standards, defines the deployment process, and states who owns the code after go-live.
• Post-launch is where most engagements fail. Ask how managed services, user training, and knowledge transfer work before you sign, not after.

What is the difference between Salesforce development and configuration?

Configuration is most Salesforce work, and development is the part that requires writing code. That single distinction decides how you evaluate a partner and what questions matter.

What do consulting and implementation partners actually do?

Consulting partners and implementation partners meet business requirements with Salesforce's declarative tools: Flows, page layouts, validation rules, reports, and dashboards. Most Salesforce implementations are built this way, and most Salesforce partners are, at heart, configurators. That solves a large share of business challenges without a line of code. A salesforce implementation partner who delivers a clean Sales Cloud rollout is valuable, but that isn't the same skill set as building a custom salesforce solution.

What does custom Salesforce development mean?

Custom Salesforce development means writing code on the platform. That's Apex for server-side logic (triggers, batch jobs, REST callouts, complex business processes), Lightning Web Components for custom UI and client-side behavior, and managed packages for AppExchange products. App development on Salesforce carries a different quality bar than configuration: every component needs tests, documentation, and a plan for maintenance. When someone says "custom development," this is the work they mean, and it's what the rest of this framework helps you judge.

Why "configuration first" protects you from technical debt

The best development partners reach for configuration first and write code only when they have to. Every line of custom Apex and every LWC component needs testing, documentation, governor limit awareness, and maintenance across three Salesforce releases a year. A partner whose first instinct is always custom code is generating technical debt with every sprint. Ask any partner you're considering to describe a recent case where they chose a Flow over Apex for a complex requirement. The answer tells you more than their certification count ever will.

Which credentials show a partner can really develop on Salesforce?

"Check their certifications" is where most evaluation guides stop, and it barely scratches the surface. It helps to know how Salesforce partners work: tiers and badges signal standing, but a certified Salesforce partner has only cleared a bar. A raw count of certified partners tells you how many badges a firm holds, not whether senior developers will touch your project.

PDO status and AppExchange track record

Product Development Outsourcer is Salesforce's designation for partners it has independently vetted to build production-grade managed packages and pass AppExchange security review. The vetting tests development capability, not sales volume, which is why the status is relatively rare. It's the strongest single credential for development-heavy work, AppExchange products for an independent software vendor, and complex integrations. Verify it on the partner's Salesforce AppExchange PDO profile, then ask how many times they've passed security review for a client product across their Salesforce projects.

Certified Salesforce developers and the certifications that matter

Ask which certified Salesforce developers would work on your project, by name, and which certifications they hold. Platform Developer II is the senior Apex certification, covering advanced patterns, governor limit architecture, and asynchronous processing; Platform Developer I is the baseline. A firm with 200 Salesforce certifications and zero Platform Developer II holders on your team does not have senior Apex developers on your team. A headline like "we have X certified Salesforce experts" means little until you see which credentials sit with the salesforce consultants actually staffing your build.

Architect-level expertise and technical depth

Application Architect, Data Architect, Integration Architect, and Sharing and Visibility Architect each signal real technical depth. An Integration Architect on a complex multi-system project is a meaningful advantage, and specialized expertise like this is where a partner's ability to design rather than just code shows up. The catch is the same as with developers: "our team holds architect certifications" is worthless if those experienced architects aren't on your engagement. Ask which architect credentials belong to your named team, and you'll quickly separate marketing from technical expertise.

Salesforce partner tiers, from boutique to Summit

Salesforce partner tiers describe a consulting firm's overall standing with Salesforce, based on certifications, delivery, and customer satisfaction. A Salesforce Summit Partner sits at the top tier, which signals scale and a long track record. But partner tier is a firm-level badge, not a project-level guarantee: a Summit partner can still staff your build with junior developers, and strong boutique partners often bring a deeper development focus than a large generalist. Read the tier as context, then verify the people and the code.

Can they show real code or an architecture review?

For larger engagements, a well-run partner should be able to share an anonymized code sample or architecture diagram from a similar project, something that shows how they handle governor limits and test coverage. It's less routine in the Salesforce ecosystem than in general software, but it's a fair ask. A partner who won't discuss code-quality standards at all during the sales process is telling you something worth hearing.

How deep is their expertise across Salesforce clouds and your industry?

Match the partner to the Salesforce clouds and the industry your build actually touches, because "Salesforce expertise" in the abstract means little. A partner strong in one cloud can be a novice in another.

Which Salesforce clouds does your build touch?

Salesforce clouds are not interchangeable. Sales Cloud, Service Cloud, Marketing Cloud, Revenue Cloud, Health Cloud, Financial Services Cloud, and Data Cloud each have their own data models, limits, and development patterns. A custom LWC that works cleanly in Sales Cloud may need a different approach against Salesforce Data Cloud or Marketing Cloud's APIs. Ask which clouds a partner has built custom development on, not just configured, with a specific example in the cloud your project depends on. Solutions come from partners who know the quirks of your clouds.

Does industry experience actually matter?

Industry experience matters most where compliance, data governance, or domain logic shape the build. A partner with industry expertise in regulated sectors already understands why field-level security and audit trails are not optional, and can anticipate the requirements your own team hasn't written down yet. It matters less for a generic internal tool. Weigh it honestly: relevant industry experience shortens discovery and reduces rework, but it never substitutes for the technical depth to build the thing well.

What should you ask a Salesforce development partner before you hire them?

Ask these six questions, because proposals are written to impress and answers are harder to fake. A capable partner responds immediately and specifically. A firm selling Salesforce development without deep Apex expertise starts to hedge.

"How do you handle governor limits in Apex? Walk me through a recent example."

Governor limits are Salesforce's per-transaction caps on SOQL queries, DML operations, heap size, and CPU time. A strong answer names a specific limit and a specific response: a batch job resized for heap, a trigger bulkified for 200 records, a callout moved to asynchronous processing. A weak answer, "we follow best practices," means they know the concept and may never have architected around it at the volumes that come with large scale Salesforce implementations.

"What's your Apex test coverage standard, and how do you keep tests meaningful?"

Salesforce requires 75% coverage to deploy to production. That's a deployment gate, not a quality standard. A strong answer sets a higher bar, 85 to 90%, with tests that exercise real logic: data factories, positive and negative cases, bulk tests at 200 records, plus Jest tests for LWC. Stopping at "we meet the 75% requirement" describes code that deploys and still fails in production.

"How do you decide between a Flow and Apex for a requirement?"

You want a clear rule of thumb: Flow for automation an admin can maintain, Apex when governor limits, complex branching, or asynchronous work make Flow impractical, ideally with an example of each. This is the judgment that keeps your salesforce environment maintainable. "We use whatever the client prefers," or a reflexive default to code, is the answer to worry about.

"Have you passed the AppExchange security review, and what issues came up?"

A partner who has been through Salesforce's security review names the failure points: Lightning Web Security violations, insufficient field-level security enforcement, insecure API key handling, cross-site scripting in LWC. Specifics prove experience. "We're familiar with the process" usually means they haven't cleared one, and that gap turns into months of rework.

"How do you handle Salesforce's three annual releases and regression testing?"

Salesforce ships Spring, Summer, and Winter releases every year. A strong answer is a documented process: sandboxes promoted to preview orgs before release, automated suites run against the upcoming version, and LWC tested against new browser security policies. "We keep up with the release notes" is not a process for protecting production code across the salesforce journey.

"Who specifically will write the code, and what's their experience?"

In custom development, the gap between a senior and a junior Apex developer is the gap between code that scales and code that becomes your problem. This question also surfaces integration depth: if the build involves integrating Salesforce with a payment processor or ERP, or connecting Salesforce to your data warehouse, ask who has done that system integration before. "We'll assign resources based on availability" should give you pause.

What if none of the answers are red flags, but none stand out either?

This is the most common outcome, not the exception. Most partners clear all six questions without a single answer vague enough to worry you, or sharp enough to convince you. That gray zone is where a lot of buyers just guess.

Don't grade the six answers one at a time. Read them side by side instead. A partner who's specific on governor limits and test coverage but goes soft on release-window planning is telling you where their real experience sits, and where it doesn't.

Then reduce the risk instead of guessing. Ask for a small paid pilot, a real Apex class or a scoped two-to-three-week module, rather than committing to the full build. A pilot turns "sounded fine on the call" into code you can actually review, and it costs far less than finding out six months into a fixed-price contract that mediocre was the ceiling, not the floor.

If a pilot isn't practical, go back to the anonymized code sample or architecture review mentioned earlier in this framework, and insist on it this time. A partner with real depth behind an average-sounding answer can usually still produce something concrete. A partner who can't is telling you what "mediocre" meant all along.

What should a Salesforce development proposal include?

A serious proposal covers five things, and the absence of any one is as informative as its presence. Read for them before you compare prices, because a proposal is the first real sample of how a partner thinks about project scope.

A discovery phase before any code

Architecture decisions (configuration vs code, data model, integration approach) need structured discovery before anyone writes a line. Discovery is also where a partner turns your business goals into a CRM strategy and an honest read of scope. A fixed-price proposal with no discovery phase is priced on assumptions, and those resurface as change requests the moment the requirements turn out deeper than a sales call revealed.

Named technical team members

The proposal should name the developers, LWC specialists, and architects who will do the work, with certifications and recent history. When they're missing, the team on the pitch is rarely the team that delivers. Ask for names before you sign.

Code quality standards

Look for a stated Apex coverage threshold (85%+ for complex work), a code review process, and documentation standards for custom objects, fields, and Flows. If they're absent, you'll inherit whatever the partner produces with no standard to hold them to, and no defense against accumulating technical debt.

A deployment and release process

The proposal should describe how code moves from sandbox to production, change sets versus Salesforce CLI, and what UAT looks like before anything ships. Without it, deployments are ad hoc and rollback is an afterthought.

Post-launch support and code ownership

Terms should be explicit: who maintains the code, the support SLA, whether you own the code and can take it elsewhere, how data governance is handled, and what knowledge transfer you receive at handover. Post-launch is where most development engagements quietly fail, and where most proposals say the least.

What does support look like after go-live?

The right partnership doesn't end at go-live, and how a partner handles the months after launch is where proven customer success is actually earned. Ask about it before you sign.

Managed services versus one-off projects

Some partners deliver a project and disappear; others offer ongoing managed services for sprint-based feature work, release management, and monitoring. Managed service providers and professional services teams differ in how they price and scope this, so be clear about what you need. Ongoing managed services make sense when your Salesforce footprint keeps growing; a one-off build with a clean handover makes sense when it doesn't. Strategic consulting services sit alongside both when you need direction, not just delivery.

Training, knowledge transfer, and change management

Custom development only pays off if people use it. Ask what user training the partner provides, what knowledge transfer your internal team receives, and how they support the change management processes that get a new tool adopted by a sales team or service org. A partner who hands over documentation and trains your admins is protecting your investment; one who leaves you dependent on them is not.

How the right partner protects customer success and ROI

The point of all of this is business outcomes. A partner focused on customer success ties the build to how it changes the sales process or the experience for your Salesforce customers, and measures whether it did. That's how custom Salesforce development supports business growth and helps you maximize ROI, rather than shipping code that quietly goes unused. Customer satisfaction tends to track one thing: whether the software made someone's job measurably easier.

What are the red flags when choosing a Salesforce development partner?

Watch for these six patterns, all drawn from development work that has gone wrong, the kind we're often called in to rescue. They're industry-wide, and all of them are easier to catch before a contract than after.

Code that works in sandbox and breaks in production

The classic failure mode, usually traced to governor limit behavior never tested at production data volumes, security-model differences between orgs, or hardcoded IDs that only exist in the sandbox. Ask how they test for production parity: what data volumes and org configuration the pre-production testing actually uses.

No mention of who owns the code

Custom Apex and LWC written in your org is yours, unless the terms say otherwise. Some engagements are structured so only the original partner can maintain what they built. Ask plainly whether your internal team, or a future partner, can maintain the code without them. You want a yes, backed by documentation.

Promising the security review without having passed one

The review has well-known failure points. Partners who've cleared it architect for it from day one; partners who haven't treated it as a final submission and wait, and it can stretch for months if the code needs rework.

A test coverage number with no context

"We maintain 80% coverage" sounds reassuring and says almost nothing. Coverage that touches lines without testing logic produces code that deploys cleanly and breaks anyway. Ask what their standard is for test quality, not the percentage.

A timeline that ignores Salesforce release windows

Three major releases a year means a project that doesn't plan around them risks shipping code that collides with a platform change. Ask whether the timeline includes a buffer for testing against the next release.

Complex integrations described as "straightforward"

"Integrating with your ERP is straightforward, we've done it before" is the sentence that precedes most mid-project escalations. Salesforce integrations break at the edges: duplicate records, API rate limits at volume, data type mismatches, and token expiry under load. Ask a prospective Salesforce integration partner for one integration that surprised them, and how they handled it.

How does MagicFuse answer this framework?

Here's the honest version of applying the framework above to ourselves.

MagicFuse against each criterion

MagicFuse is a certified Salesforce PDO and a Salesforce Summit Partner, independently vetted to build production-grade managed packages. With 12+ years in the Salesforce ecosystem, 450+ specialists, and 270+ Salesforce certifications (including Platform Developer II, JavaScript Developer I, and architect-level credentials), we name the people who'll work on your project at scoping, before you sign. Our voluntary turnover is 2.65% (6.37% overall), so the developer who starts your project is very likely the one who hands it over. Every build opens with a declarative-first assessment that documents what Flows can handle, what needs Apex or LWC, and why. Code quality is standardized: 85%+ meaningful Apex coverage, Jest tests for LWC, code review before promotion, and documentation of every custom object, field, and trigger at go-live. You own the code, and managed services are a genuine choice rather than an engineered dependency.

Proof from named builds

We've supported 15+ ISV products and built 3 AppExchange products of our own. Elements.cloud (UK, ISV) is a secure, scalable AppExchange managed package that passed Salesforce's security review and external security audits, with custom data sync across millions of Salesforce records using Apex, LWC, and AWS. A UK e-signature ISV came to us with an existing AppExchange product in poor shape; we rebuilt it to a production-grade baseline, added two-way Salesforce data sync, and guided it through a full security review, a code rescue and a review in one. For a global luxury hospitality group we built a custom Experience Cloud portal with LWC widgets, Lightning Message Service for real-time data exchange, and role-based personalization. Limio, ID-Pal, Riptide, Ascent Solutions, and Purlos round out the AppExchange track record.

Where your project starts

Wherever you are, there's a starting point in our Salesforce development services: custom Apex and LWC development, AppExchange managed package work (2GP packaging, security review, listing prep), Experience Cloud portals, third-party integrations, code rescue for engagements that have drifted into technical debt, or ongoing development managed services. The right salesforce partnership starts with a scope, not a sales pitch.