Do you do code (Apex) or configuration?

Both. I favour declarative tools (Flows, configuration) when they're enough, and move to Apex/LWC for custom needs or large volumes.

Can you integrate Salesforce with my site or my tools?

Yes: connection via REST/Bulk API, data synchronisation, webhooks, web-to-lead, and bridges to your billing or your Laravel/WordPress site.

Do you work on an existing org?

Yes. I start with an audit (objects, automations, technical debt, tests) before stepping in, so as not to break anything in an org already in production.

Do you handle deployments and tests?

Yes: mandatory Apex tests, deployments via Salesforce CLI or change sets, sandbox testing before any production release.

Expertise

Freelance Salesforce developer

Salesforce developer: Apex, LWC and custom integrations

Salesforce is powerful — and it quickly sprawls out of control if no one is steering. I build the Apex, Lightning components and integrations that fit the way you actually work, without turning your CRM into an unmanageable mess.

Tell me about your project View services

Kylian Bellegarde, freelance Salesforce developer in Martinique, working on Apex code and a Lightning interface on screen.

Apex (classes, triggers, tests) and SOQL/SOSL mastered.

Lightning Web Components (LWC) for custom interfaces.

Automations (Flows) and integrations via REST/Bulk API.

I've been developing on Salesforce for two years: Apex, Lightning Web Components, automations and integrations. I help companies adapt their CRM to their real processes — not the other way around — with tested, maintainable code.

Salesforce can do a huge amount without a single line of code. Custom objects, fields, validation rules, formula fields, Flows: before reaching for Apex, I push the declarative approach as far as it will go. It's faster to set up, easier for your team to take over, and it survives the three releases a year that Salesforce imposes far better. An automation built as a Flow stays visible and editable from the interface; an Apex class, by contrast, assumes a developer is on hand for every adjustment.

But declarative has its limits. When a trigger needs to run precise calculations, when a process touches tens of thousands of records, when logic has to execute in a guaranteed order, or when you need an interface the standard components don't cover, I switch to code. The rule I hold myself to is simple: code only when it genuinely brings something a Flow can't do cleanly. Too many orgs are buried under Apex classes that should have stayed configuration — and that turn into debt no one dares touch anymore.

The opposite happens too, and I watch for it just as closely: an org where everything is a Flow ends up stacking dozens of automations firing on the same object, in an order that's hard to follow, until one harmless change breaks another somewhere else entirely. Striking the right balance means knowing how to group, name clearly, and keep a record of what each automation does and why. The goal isn't to ban code or to code everything: it's to make sure every building block is in the right place, readable, and justified.

In practice, that means I start every engagement by framing the business side — which objects, which processes, which rules, who sees what — before deciding what will be declarative and what will be coded. I lay out the data model properly, because a poorly thought-out relationship between two objects is expensive to fix months down the line. You come away with an org where every automation has a documented reason to exist, rather than an opaque pile your team works around instead of using.

On the code side, I work in Apex — classes, triggers, batches, asynchronous methods (futures, Queueable), scheduled jobs — and in Lightning Web Components for custom interfaces. LWCs let me build screens that go beyond the standard: a guided data-entry wizard that cuts down on errors, a business dashboard that aggregates what your users actually look at, a component embedded in a Lightning page, a Flow Screen, or an Experience Cloud site opened up to your customers or partners. I'm also fluent in SOQL and SOSL to query your data efficiently, with no wasted requests.

On Salesforce, Apex tests aren't optional: the platform refuses any production deployment under 75% coverage. I don't treat that threshold as a box to tick with empty tests. I write tests that verify real behavior — edge cases, volumes, permissions, records that don't meet the expected conditions — so your automations don't fall over the day a user does something unexpected. A serious test is also your best insurance during releases: if a Salesforce release changes a behavior, the test suite reveals it before your users do.

I'm equally mindful of the platform's own constraints: the famous governor limits that cap, per transaction, the number of SOQL queries, rows processed, DML statements, or CPU time. Coding on Salesforce means coding with volumes in mind from the very start. A naive trigger that works on ten records blows up on an import of a thousand; I design with bulkification — one query that processes the whole batch rather than one query per record inside a loop — so it holds up no matter what volumes your business reaches.

Security is part of the same reflex. On Salesforce, who sees what and who can edit what is governed by profiles, permission sets, roles and sharing: I respect those rules in the code rather than bypassing them, so a sales rep never stumbles onto data meant for management. When I deliver LWC or Apex, I make sure object and field access is enforced, and that user input is handled cleanly. A CRM holds sensitive data: it deserves to be coded with that level of care.

A CRM that lives in isolation only does half the job. The real value comes when Salesforce talks to your other tools: your website, your billing, your support, your ERP, your email platform. I integrate through Salesforce's REST and Bulk APIs — REST for real-time, record-by-record exchanges, Bulk for high-volume batches — and I set up web-to-lead, webhooks (Platform Events, outbound calls) and two-way data syncs, with proper handling of failures and retries so no information gets lost along the way.

This is where my background as a full-stack web developer makes the difference. I don't just wire up API calls on the Salesforce side: I code the other end too. A bridge between your org and a Laravel back office, a WordPress form that cleanly creates a lead without duplicating it, a catalog or order sync from your online store — I handle both ends of the pipe. That spares you the endless back-and-forth between two providers passing the buck the moment an integration stalls, and it noticeably shortens the time to get things working.

Before connecting anything, I set the ground rules: which source is authoritative for which data, how a Salesforce record is matched to a record in your other tool (by external ID, by email, by reference), and what to do in case of a conflict. It's that invisible work that separates a reliable integration from a sync that creates duplicates and that everyone eventually unplugs. I document these choices so that, later on, you know exactly how information flows between your systems.

For deployments, I work with Salesforce CLI, version control and sandboxes: we test in an isolated environment, a copy of your org, before any go-live — never directly on the org that runs your business. For lighter setups, change sets remain a valid option and I adapt accordingly. And if you already have an existing org, I start with an audit — objects, automations, technical debt, state of the tests, integrations in place — so I can step in without breaking anything that's already running.

I'm based in Martinique and I work with clients across the Caribbean — Martinique, Guadeloupe, French Guiana — as well as in mainland France. Since Salesforce is a cloud platform, distance changes nothing about the quality of the work: a shared sandbox, delegated access to your org, video calls and regular check-ins are enough to move forward together. The time difference with mainland France stays reasonable, and for a Caribbean business, having a contact in the same time zone and the same working culture avoids plenty of misunderstandings and meetings at impossible hours.

In practice, you don't need to hand me the keys to everything: I work with access scoped to what the engagement requires, and at each step I report back on what I changed and why. You keep control of your org, and you never inherit a black box you'd be unable to evolve without me. For one-off needs, I also work task by task — a trigger to fix, a component to add, an integration to make reliable — without forcing a large project on you that you have no use for.

Salesforce remains a world of experts, often handled by large consulting firms with the rates and timelines that come with them. My niche is the opposite: a single contact who codes, who explains their choices in plain language and who hands you back a documented org. For SMEs, nonprofits and organizations without an in-house Salesforce team, that's often the right fit — enough technical expertise to build something solid, enough closeness for you to understand what you're paying for and what you're getting.

I'm upfront about one thing: I've been developing on Salesforce for two years, I don't present myself as an architect with ten years of certifications. On Apex, LWCs, Flows, the data model and integrations, I'm solid and I deliver concrete results. For a large-scale multi-cloud rollout (Marketing Cloud, CPQ, a regulated sector with heavy governance) or an org overhaul at enterprise scale, I'll tell you so honestly and point you to the right resource, rather than taking on a project outside my zone. That's part of working honestly too: knowing your limits and saving you time.

Apex + LWCTested custom code

75%Minimum test coverage required

2 yearsOf Salesforce development

API REST/BulkIntegrations with your ecosystem

The advantages

A single contact who codes Salesforce AND the rest of your web system — no ping-pong between providers over integrations.
Declarative first, Apex second: a leaner org, easier to take over, that weathers Salesforce's three annual updates better.
Genuinely tested Apex code, beyond the mandatory 75% threshold: your automations hold up against edge cases and volumes.
Bulkified design built for governor limits from the start — what works on ten records keeps working on thousands.
Permissions and sharing respected in the code: each user only sees the data they're entitled to.
An audit before any work on an existing org: we map the debt and the automations before touching anything in production.

Limitations to be aware of

Salesforce carries real licensing costs, per user per month: for a small organization on a tight budget, the bill can outweigh the need compared to a lighter CRM or a custom solution.
The platform imposes its governor limits (SOQL queries, rows processed, DML statements, CPU time per transaction): you can't code everything exactly as you'd like, you have to work within those caps.
Salesforce imposes three major updates a year: you have to anticipate possible adjustments and test your customizations with every release — it's ongoing maintenance.
My experience spans two years: for a large-scale multi-cloud architecture or an enterprise org with heavy governance, a specialized firm will be a better fit, and I'll say so.

Salesforce is a remarkable platform, but it isn't always the right tool. Here's how I reason through it when we discuss your project.

Choose Salesforce if…

You're already on Salesforce and you want to tailor it to your processes rather than bending your business to the standard tool.
You have complex sales or business processes that justify a properly structured CRM, with roles, permissions and automations.
You handle large volumes of data and records that call for a platform that can take the load.
You need your CRM to connect cleanly to an existing ecosystem of tools through robust APIs.
Your team or your industry already mandates Salesforce as the standard and you want someone who codes on it properly.

Prefer something else if…

Your need boils down to tracking a few contacts and simple follow-ups: a lightweight CRM, or even a no-code tool, will cost you far less.
You're starting a business on a tight budget: Salesforce licenses add up fast, so it's worth starting simpler and migrating later if it grows.
What you mainly want is a very specific custom business tool: a dedicated Laravel build may be more relevant, with no per-user license cost.
You have no one in-house to keep the org running day to day and you're not planning for support: a turnkey solution will need less upkeep.
Your data volume and your processes stay modest: Salesforce's power would be overkill for what you'd actually use.