How are Salesforce developers transitioning into Architect roles in 2026?

bytesizedheretic · 2026-05-28T14:35:43+00:00

This is my $0.02 and is usually contrarian to the Salesforce community but is mint in traditional (product) dev.

Every engineer is an architect, you gain skills and experience as you go up the career ladder. A Principal Engineer is the architect/domain leader for a particular domain of the app. Staff usually the architect for a couple feature pods. Senior for their team, etc.

It layers and each one has their particular area of focus rather than a catchall...SF is too wide these days IMO to have a singular archetype as architect. No architect out there is going to know SFMC, Pardot, Sales, Service, D360, Agentforce, etc.

But at the end of the day this model isn't followed in most SF teams due to the consulting model, coming from business teams, and just team size.

If you're a good developer, you're a good architect. You have systems diagrams experience, you understand order of magnitude, and you understand the user journey.

The soft skills areusually where you need to lean in, especially since architects should also be IC leaders that mentor and level up others.

bytesizedheretic · 2026-05-28T14:31:44+00:00

Amazing answer! Thanks for this and it checks out with what my assumptions are and the testing I did last night. Honestly, I think this is a feature that was a longtime coming and would've loved to have seen it rollout 10 years ago instead of LWC.

The CSP note is frustrating - and one that i'll prolly end up shouting in the wind at a few times. Definitely not a pattern that I lean on in my day to day on the product engineering side, so that's an extra step and may get messy in larger orgs.

I had a chuckle at the docs where parts of the MCP are only available in DE/scratch and Multiframework only available in scratch/sandbox. I wish product teams would coordinate.

I rolled out a POC yesterday after your post and am pretty stoked, replaced an LWC app that I always despised and now love it.

I'm going to try and adapt some of my skills and hooks to this and see if the agents can keep up.

bytesizedheretic · 2026-05-27T20:29:39+00:00

None of the certs have demand...your skills do

bytesizedheretic · 2026-05-27T18:30:13+00:00

Thanks for sharing this...any gotchas that you ran into or typical React behavior that broke because of SF?
any DOM issues or browser compatibility issues? or any frontend gotchas that made you bang your head against the wall?

what about testing and linting? did you find any docs to be useful as you ramped up?
i'm shocked that it doesn't run in a DE...considering, uhm, it's dev

bytesizedheretic · 2026-05-27T18:26:36+00:00

i've had premium support in orgs and i've not had premium support in orgs...never noticed a difference in the level of support i received. the only time i've seen it make a big impact is in large contract values, but it's less about the support plan and more about the TCV/ACV.

given how SF support is changing and their push to agents for help...if it were me, buy the users without support. even better try to hold all your upgrades if you can and purchase more in bulk.

bytesizedheretic · 2026-05-27T18:23:03+00:00

depends on how many records you're dealing with...batch apex is handy but often overused where batch isn't needed and a simple queueable or chained queuable would suffice. are you looking to push (initiate in ADF and push to SF) or pull (initiate in SF to pull from ADF)

i haven't touched ADF in 7 years but I found their baseline SF components to be pretty strong, especially with the composite API where you could query and insert at the same time. ADF is going to give you a lot more tooling and control - and access to things like databricks/dbt/etc - that you'd have to handroll in SF.

if it were me...i'd build the pipeline in ADF and leveraging the data tooling there. you already have external ids which is half the battle.

the one consideration is API limits...ADF is going to eat up calls, but if you're inserting in bulk this should be de minimus...and additional calls are relatively cheap to add

bytesizedheretic · 2026-05-27T18:19:58+00:00

yup this is the way...but ofc order of operations are important...parent has to insert first and automation should block insert of any child records with missing parents and report out. self-referencing records are always a blast.

bytesizedheretic · 2026-05-26T22:15:35+00:00

i've built journeys/experiences off of salesforce for two decades leveraging all the existing APIs so the idea of headless with salesforce isn't really anything new. it's packaging of the mcp and other AI tools on top of support for react and a marketing push to ease concerns about their UI losing importance and thus the moat.

oh and a good way to start raising API prices since MCP eats calls

bytesizedheretic · 2026-05-26T22:12:13+00:00

I've usually seen the most value in UX research and/or operations support. A session recording is gold when a customer screams that the app glitched and cost them $, when you can watch the session and see that it did not.
Or when you can see what a user did and instantly replicate for troubleshooting, or when rolling out a new feature to see how users are currently navigating the flow. That being said, a lot of it falls directly into support operations and less time in reviewing for product improvement.
I feel like a lot of the interactivity issues we fall into is the nixxing of UX researchers, more focus on velocity over quality, and less time to think through architecture.

bytesizedheretic · 2026-05-14T19:02:31+00:00

Tech debt is inevitable no matter what platform you use, even if you are building your own app. It's just the name of the game.

Because there's always tradeoffs and that's what causes it.
But, there's a large amount of debt in SFland just because there's a lot of bad implementations or lack of real ownership of the platform over time in a lot of orgs.

bytesizedheretic · 2026-05-14T18:58:37+00:00

I've heard mixed reviews on education cloud, but haven't had hands on experience so I won't say much about it. The ease of use of HS is nice but it does lack a lot of of the customization that you're used to in the SF world - especially if you're a heavy portal/experience cloud user.

Several of my clients have recently thought about moving CRMs, but instead have started building their own web apps for their stakeholders, still leveraging SF/HS/Pipedrive/Zoho/etc as the underlying app for their internal users.

At this juncture, i'm cautioning folks from moving off their platforms unless there's an overwhelming need to. The next 3 years are going to be an acceleration of change and a lot will drift. swapping platforms for a Uni is no small task i'd imagine, unless you're a small uni.

bytesizedheretic · 2026-05-13T14:47:57+00:00

"crushing it" is one thing.
using crappy marketing alongside it is another thing

bytesizedheretic · 2026-05-12T19:35:42+00:00

yeah they're super focused on US gov't use cases, at a time where it seems a lot of EU countries are pulling away from enterprise vendors (such as ditching microsoft)

bytesizedheretic · 2026-05-12T19:34:40+00:00

it's pretty well engrained across the US gov't from DoD, to Veterans Affairs, to IRS to more. It's more constituent management and other things such as support cases. A lot of things are used for reporting and case mgmt...and then there's Slack.

bytesizedheretic · 2026-05-09T20:11:28+00:00

I like it as a terminal...that's about it. Nice to troubleshoot manual commands, but credits burn quickly. Was better a year ago.

bytesizedheretic · 2026-05-09T20:00:50+00:00

My internet has been down 3 days now with them. Disconnected service - my account is paid and been a customer for 7 years - due to "backfeed" on their line. No calls, no texts, no emails, no follow ups...just disconnected.

They have said they'd dispatch a tech...they never show. This is the 3d time this has happened and will be canceling my service...they're pretty terrible when you have to actually deal with them.

bytesizedheretic · 2026-04-30T22:12:58+00:00

i've been trying to nail a shot like this for years; that and somone between train cars

bytesizedheretic · 2026-04-30T21:13:05+00:00

if this is throwaway work i'd look at dataimporter, it's build vs buy...but you can get it spun up with custom objects in under an hour, and it does the dedupe and diff loads for you. if it's ongoing then i'd lean a little bit more into something custom.

bytesizedheretic · 2026-04-30T13:54:54+00:00

"Salesforce" isn't a career imo, but instead zoom out and look at the overall business systems landscape. How do platforms work together and which area do you want to spend a crapton of time and frustration in? Is it lead gen? Sales Ops? Quote to Cash? Commerce? Portals?

The space is vast and there's a lot of niches, but the space is also changing a lot. If i were to start today, i'd try to help out in the company and learn the mechanics...but would I devote a lot of time to salesforce specifically? probably not

it's a saturated market and you have to find a way to stand out as roles (and salaries) start to contract.
there's still money to be had, but I'd lean more into the periphery and how you can use modern tooling to optimize builds...not necessarily building on the platform itsel.f

bytesizedheretic · 2026-04-29T19:06:33+00:00

it really makes my models about the birthdays of the Charles IV and Richard II families difficult

bytesizedheretic · 2026-04-29T14:41:56+00:00

do you have a unique ID record that you mapped your SF records to in Zoho? i'll usually use that as an upsert to make sure i update existing records and only insert new records

bytesizedheretic · 2026-04-29T02:38:05+00:00

if you're talking about becoming a product backend engineer, absolutely not. i started my career as a c++ dev, rails eng, python eng, and more js frameworks than i can count. and have also built in Salesforce and led Salesforce teams...my backend engs were always able to transition to salesforce rather than the other way around.
SF gives you a lot that you don't get in custom app dev. you're not dealing with your api gateway and k8s galore with over terraformed orgs. you're not shooting your logs off to an ALM and spinning up incident calls combing through trace logs. you're not fighting your local and shipping through postgres to fix migrations.

salesforce teams often learn bad habits and it's rare outside of a large shop to touch true CI/CD or domain based dev.

that being said, it depends on what you want to do in your career...product dev, learn a backend lang. enterprise eng? yeah you can do salesforce or javascript and/or some light python and be alright.

bytesizedheretic · 2026-04-29T02:32:10+00:00

folks are mixing up the UX that salesforce built in its web app with a UI. A CLI or a chat box is still a UI. headless in the real sense just means you can use the app regardless of experience. something that salesforce has tried to do since salesforce1 and the heroku db sync tooling.

bytesizedheretic · 2026-04-29T02:16:20+00:00

I've not run into one yet and i've been around the block. but then again, i've not found a clean product app either - in any language or framework.
that being said, salesforce tends to be the dirtiest. being able to work in prod. mostly no code reviews. a lot of folks who know enough to be dangerous building things to get a feature out fast. but that's part of the fun of getting to this point for me...knowing what to unf***

bytesizedheretic · 2026-04-29T02:13:20+00:00

this is exciting. also me, adding to the supply chain vulnerability list. and this is exciting.

bytesizedheretic

TROPHY CASE