Too often, teams get handed a tech-shaped solution before they’ve even agreed on the problem worth solving.

There’s a diagram I always carry in my head. On one side: the people in the field, in the work, trying to move faster, serve better, or just make their lives easier. On the other side: the systems we’ve layered up to support them. In between sits a gap, sometimes wide, sometimes subtle, but always a gap.

The reflex in enterprise environments is to close that gap by stacking more tools, integrations, and interfaces. But if we begin with the system, we inherit its shape. If we begin with the people, we give ourselves permission to shape the system.

That’s the real value of a good discovery phase. It isn’t a tech audit. It’s a truth-seeking process. What are people really trying to get done? What’s getting in the way? What friction matters enough to warrant change?

When you start there, the tech falls into place.

Experience and tech should move together

I’ve managed Salesforce orgs that carried the weight of the entire customer lifecycle from first contact to post-sale support. I’ve also seen how fast the UX can fall behind, even when the backend is humming.

The best solutions don’t ask customer experience to follow tech, or vice versa. They align them. That might mean building within Salesforce when the user flow aligns with CRM structures. It might mean layering a front-end app on Heroku or React when the field team needs something faster, cleaner, or more responsive. It might mean pulling data through middleware or building read/write APIs when the system of record lives somewhere else.

What matters most is that we’re designing for how people actually work. Not just what the system can do.

Choosing where a solution lives

Every enterprise team eventually asks the same question: Should we build this inside Salesforce, on top of it, or somewhere else entirely?

The answer depends on what kind of product you’re creating and for whom.

Build within Salesforce

A slide titled Native Salesforce App Experience shows a diagram of a Salesforce interface and a chat window. Bullet points describe benefits like centralized data, easy setup, and suitability for internal tools.

Use Salesforce as your design canvas when:

  • The data and workflow already live there. You’re working with Opportunities, Cases, Contacts, or CPQ rules that are already modeled in SFDC.
  • You want tight governance. Security, audit trails, permissions. Salesforce handles all of that out of the box.
  • Your audience already lives in Salesforce. Internal teams, especially Sales, benefit from not switching tools.
  • Speed matters. Experience Cloud templates and Lightning Web Components (LWC) allow quick prototyping using standard layouts, permissions, and automation.

We’ve seen tools launched in weeks by leaning on Salesforce-native patterns. But it only works when the user experience can live comfortably inside Salesforce’s structure.

Build on top of Salesforce

An illustration showing a smartphone with a finance app interface, connected via arrows to Salesforce and Heroku logos, alongside text describing a custom experience layer with Salesforce integration benefits.

Go this route when:

  • You need a tailored, flexible user experience. Field teams, customers, or partners often need a cleaner, mobile-first experience.
  • You want more control over performance and design. React or Next.js apps hosted on Heroku or similar platforms allow full customization while syncing back to Salesforce with Heroku Connect or APIs.
  • You’re layering in other systems. If your product pulls from Salesforce, SAP, and external services, a custom front end decouples experience from back-end complexity.

This is where experience and engineering really partner. The system can still be Salesforce at its core but the face of it becomes something that feels like your team, not like a CRM.

Build alongside Salesforce

A slide describing an independent app that integrates with Salesforce. The left side lists benefits, and the right shows a screenshot of the Mercury Marine Knowledge Portal on a desktop, featuring navigation tabs and text.

Sometimes the answer is neither inside nor on top but next to. This applies to:

  • Heavy analytics or AI workloads. These are better handled in platforms like Snowflake, BigQuery, or a purpose-built Python environment, then connected back into SFDC when needed.
  • Fast-moving MVPs. When you’re pressure-testing an idea, it’s often faster to stand up a standalone Node or Rails app, connect it loosely via API, and validate whether it’s worth making a deeper investment.
  • Data transformation or integration. Use middleware like Mulesoft, Workato, or custom services to connect SAP, Salesforce, and other systems without overloading any one of them.

These “adjacent” builds protect your core CRM from being over-customized and give you the room to innovate quickly.

Where a solution lives matters but only after you understand the job it needs to do.

  • Salesforce brings structure, speed, and data integrity.
  • External apps bring flexibility, control, and tailored experiences.
  • Middleware and standalone tools bring orchestration, insight, and agility.

Enterprise doesn’t have to mean bloated

Enterprise tools often get a bad rap: too heavy, too rigid, too slow. But that comes from treating every solution like a platform decision. We believe the best enterprise products are modular. Some parts live in Salesforce. Some extend through Heroku or middleware. Some connect to SAP through APIs or real-time sync.

There’s no one-size-fits-all. But there are good principles:

  • If the need is clear and the data lives in Salesforce, build the solution inside.
  • If the experience demands more, build the solution outside and let Salesforce do what it does best.
  • If the process spans teams or systems, find the integration points that serve the user, not just the architecture.

Modern enterprise design is about making thoughtful tradeoffs, not sweeping commitments. You can scale and stay nimble at the same time.

The work we choose to do first

We often tell our clients: building the right thing beats building the thing right.

That’s not a call to lower quality. It’s a call to sharpen the question. When teams take the time to align around the stakes, the business urgency, the user friction, the decision risk, then every design and engineering move after that is faster, clearer, and more likely to stick.

That’s what discovery gives us. A way to start small, on purpose, with eyes wide open.

Great enterprise products are built for clarity and impact. The clarity comes when tech and experience design sit at the same table, speaking the same language, focused on the same stakes that have impact.

Start there, and the rest will follow.

Originally posted on LinkedIn — Connect with Vince Cabansag over there 👋