The work we take on
Four kinds of build, AI-first across all of them, every one through the same QA process, and every one maintained afterwards by the people who wrote it.
01 · Service
Salesforce AI
AI agents and workflows that run inside your own org, next to the data they need.
Who this is for
Teams who want AI working on a real business process rather than bolted on as a chatbot, and who would rather build it in the org they already have than license another platform.
What this includes
- Agents that carry a process end to end: something arrives, the agent gathers what it needs from your connected systems, and a person gets back a record they can act on
- Workflows hosted and orchestrated by Salesforce, so there's no second platform to buy and no second place for your team to work
- Your existing sharing rules and permissions apply to the agent, because it runs as part of the org — you decide what it can see
- The judgement about where AI genuinely helps and where ordinary deterministic logic is the better answer, written down
- AI-assisted delivery on everything else we build: the predictable parts drafted fast, every line reviewed by a senior engineer
Why Lanvale
“We build AI where it beats plain deterministic logic, and we'll tell you where it doesn't.”
02 · Service
Custom Development
The complicated builds your admin has neither the time nor the tooling for, from a Flow that outgrew itself to Apex nobody left understands.
Who this is for
Teams whose backlog needs a real developer: logic too complex to configure, automation that has stacked up over years, components the standard UI can't express, code inherited from someone who left.
What this includes
- Apex classes, triggers and batch jobs that survive governor limits at real volume
- Lightning Web Components for anything configuration can't express
- Flow where your admin can still maintain it, Apex where Flow can't hold the job
- Untangling old automation that overlaps and fires in the wrong order
- Rewriting inherited Apex that nobody left at the company understands
- Keeping existing Aura and Visualforce running
- Data models designed for how you actually query them
- Approvals, routing, platform events and scheduled jobs that hold up at volume
Why Lanvale
“Most Salesforce work goes wrong at the line between 'use Flow' and 'write Apex'. We get that call right and write down why, because in two years we're the ones maintaining it.”
03 · Service
Integrations
Connecting Salesforce to the systems that were never designed to talk to it.
Who this is for
Teams whose Salesforce org has to trade data with an ERP, a finance system, or anything else that predates it, reliably and every day.
What this includes
- REST and SOAP callouts, named credentials and external services
- Connections to ERP and finance systems
- Middleware, when a native connection is the wrong tool
- Sync designed around what happens when records conflict
- Retries, logging and alerts when something fails
Why Lanvale
“Integrations tend to fail quietly. Ours log, retry, and tell you when something has gone wrong.”
04 · Service
Quality Assurance
Salesforce only asks for 75% test coverage. We test for whether the code survives production.
Who this is for
Teams whose Salesforce changes keep breaking production, or who have nothing between a developer finishing and users finding out.
What this includes
- Apex tests aimed at edge cases and the ways code actually fails
- A regression run after every metadata deployment, so one change can't quietly break another
- Load testing at real volume, because limits behave differently at 10,000 records than at 50
- Written test plans, and support for your team through UAT
- QA gates built into the deploy process itself
- AI drafts the test scaffolding; a senior engineer decides what should break and reviews every test as closely as production code
Why Lanvale
“We test because we'll still be here when it breaks. Something that fails in three months lands back on our desk.”
05 · Service
AppExchange Apps
Build it, harden it, get it through the Security Review.
Who this is for
ISVs, and teams turning an internal tool into a product: anyone who needs a managed package that clears the Security Review.
What this includes
- Managed package architecture
- Getting an app through Security Review, and fixing what it flags
- Features and fixes on apps already published
- Namespaces and upgrade paths that don't trap you later
- Release management
Why Lanvale
“We've taken our own products through the Security Review twice. We know what it fails you for.”
Not sure which of these it is?
Describe the problem and we'll tell you what it would take. You'll talk to an engineer, not a salesperson.