Use the Platform. Don't Let It Run Your Business.
Salesforce, Microsoft and Apple can remove a lot of friction. The problem starts when an easy platform decision quietly becomes a rule about how your business is allowed to work.
On a recent project, a client wanted a new website that could handle ecommerce. Internally, they used Salesforce. Their existing WordPress site pulled data from it.
We looked at using more of Salesforce for the new site, including Salesforce Commerce. It would have worked, but staff would have had more work to do to keep the site up to date. That would have been a step backwards from the system they already had.
That got me thinking about platform lock-in. Salesforce could do the job. The day-to-day work would still have been worse.
Why platforms keep expanding
Microsoft 365 is already in the business, so Teams is the natural place to talk. SharePoint follows for documents. Somebody builds a process in Power Automate because the licence is there. Six months later, a customer-facing requirement arrives and the first question is, “What does Microsoft have for this?”
Salesforce follows the same pattern. It starts with customer and opportunity data, then picks up quoting, service, marketing and reporting. Apple can do it at device level: the Macs and iPhones work nicely together, so a workflow gets designed on the assumption that everybody who touches it lives inside the same environment.
Teams start choosing software because it is familiar, approved or apparently included. Fit comes later.
An included product still has a cost. A Power Automate flow that only one person understands takes time to support. A bundled CRM module that sends staff back to spreadsheets wastes time every day, even if the licence line looks cheap.
Give each platform a clear job
Salesforce remained the commercial source of record because the wider business relied on it. The website and internal tools had different jobs. The website organised events for customers, the internal tools supported staff, and Salesforce received the results it needed. Keeping those roles separate meant the website could change without requiring Salesforce to change with it.
Go deep where the work should be standard
Identity is the clearest example. Most owner-run businesses do not create commercial advantage by assembling their own login, access-control and device-security stack. A well-run Microsoft environment can remove support work and give the business one place to manage accounts, permissions and devices.
Email, calendars, office documents and endpoint management often belong in the same category. The work matters, but it probably isn’t what makes the company different. Standardisation is valuable because it removes decisions and reduces the number of ways something can break.
Apple can be a sound device choice for similar reasons. A small team may value consistent hardware, straightforward support and the way a Mac, iPhone and iPad work together. The boundary appears when that internal preference creates problems for customers, suppliers or staff outside the Apple environment.
Coherence is useful for standard capabilities. Flexibility matters more when the process affects how the business competes or serves customers.
Stop when convenience starts changing the business
Pay close attention when staff say the software “doesn’t really work that way” and propose changing the operation to suit it.
Sometimes the software is exposing a bad process. Businesses do carry habits that should have been removed years ago, and a new system can be a useful reason to do that. But sometimes the process exists because customers need it, because the commercial model depends on it or because it deals with an awkward exception that the vendor ignored in the demo.
Stop and look again if:
- staff export data to a spreadsheet before they can finish the work;
- a commercially important process has been bent around the platform’s data model;
- business rules are spread across proprietary workflows that nobody can confidently explain;
- customers, suppliers or contractors need expensive workarounds to participate;
- replacing one product would now require rebuilding half the company.
A spreadsheet may be evidence that the official system does not represent how the business really operates. Dismissing it as user resistance can hide the problem.
Best-of-breed can create a different mess
A business can have excellent individual tools and a dreadful overall system. Each product has its own accounts, permissions, supplier, contract and copy of the data. Staff move information between them by hand because the advertised integration handles the happy path and little else.
That approach gives you more vendors without necessarily giving you more freedom. If nobody knows which system is right when two records disagree, the business has lost its source of truth.
Specialist products earn their place where the work differentiates the business, where the main platform is a poor fit, or where the improvement for staff and customers justifies another boundary to manage. The ownership still needs to be explicit. Which system owns the customer? Which owns stock? Where does the final decision get written back?
The integration diagram is less important than being able to answer those questions.
Four questions before you add another module
Does it match the work people actually do?
Look past the process manual. Where are the unofficial handovers? Which spreadsheet appears before month end? What does the experienced member of staff do when the normal route fails?
If the product only fits the tidy version of the process, the business will end up operating around it.
What responsibility will this system own?
Reading customer data does not make a product the customer source of record. Displaying availability does not mean it should own stock. A system needs a defined job, including what it must return to the systems around it.
What happens outside the ecosystem?
Internal convenience can create external friction. Customers, suppliers, future acquisitions and temporary staff may not share your accounts, licences or device choices. Their part of the process needs to work too.
Are we choosing it because it fits, or because it is there?
Familiarity has value. It lowers training, procurement and support costs. That value should be stated honestly and weighed against the operational compromise.
Check the exit before signing: a real data export, useful documentation and an interface another system could use. “There is an API” is not an exit plan.
Use the useful parts, then draw the boundary
Salesforce, Microsoft and Apple can all be sound choices. Microsoft can simplify identity and productivity. Salesforce can hold commercial data. Apple’s device integration can make a team easier to support. Specialist software belongs where the work needs it.
Whichever route you choose, document what the platform owns and what stays outside it.
The business should still be able to change a customer journey, bring in a better specialist product or build a focused application without asking whether the platform vendor permits that version of the future.
If you are about to extend a major platform or sign a significant technology proposal, I can review it before you commit — a plain-English verdict on whether to sign it, change the terms or walk away, and why.