Design review for material changes
Any change touching the data model, permissions or an integration goes through professional review before it is built. This is the step that saves most of the rework.
Support & continuous improvement
Salesforce does not end on go-live day.
The organization, the users and the processes keep changing. Our ongoing care model lets you maintain, improve and extend the system in a documented, prioritized and measurable way — without accumulating new technical debt.
Operational Control Loop
One operating loop, not a request list
The difference between support that puts out fires and care that creates value is a closed loop: every request is measured, prioritized, delivered and verified — and the result feeds the next cycle.
Operational Control Loop
- 01
Intake
A single request channel with classification, ownership and visible status.
- 02
Prioritization
Joint ranking by business impact, risk and effort.
- 03
Build & test
Built in a sandbox, acceptance-tested and released under control.
- 04
Measure & learn
Activity reporting, adoption metrics and exception review.
↻ The cycle repeats — each round feeds the prioritization of the next
Scope of responsibility
What ongoing care can include
- Incident handling
- User support
- Changes & adjustments
- Flows & automation
- Apex & LWC development
- Reports & dashboards
- Permission management
- Data quality
- Integration monitoring
- Release management
- Backlog management
- Training & enablement
- Governance & design review
- Quarterly roadmap
- Technical-debt reduction
- Salesforce release readiness
Models
Chosen by need, not by package
| Model | When it fits | What you get | Limitation worth knowing |
|---|---|---|---|
| Hours package | Small, variable needs | Full flexibility in choosing tasks | Less suited to long-term planning |
| Monthly retainer | A steady stream of enhancements and support | Known capacity and monthly prioritization | Requires prioritization discipline from the client |
| Ongoing delivery team | A core system with broad usage | Support, development and maintenance under one management | A broader engagement |
| Fractional architect | There is an in-house team but no senior technical decision-maker | Design review, governance and technical-debt control | Does not replace delivery capacity |
| Focused improvement project | A defined goal with a start and an end | Clear scope and deliverable | Does not cover ongoing support |
Hours package
- When it fits
- Small, variable needs
- What you get
- Full flexibility in choosing tasks
- Limitation worth knowing
- Less suited to long-term planning
Monthly retainer
- When it fits
- A steady stream of enhancements and support
- What you get
- Known capacity and monthly prioritization
- Limitation worth knowing
- Requires prioritization discipline from the client
Ongoing delivery team
- When it fits
- A core system with broad usage
- What you get
- Support, development and maintenance under one management
- Limitation worth knowing
- A broader engagement
Fractional architect
- When it fits
- There is an in-house team but no senior technical decision-maker
- What you get
- Design review, governance and technical-debt control
- Limitation worth knowing
- Does not replace delivery capacity
Focused improvement project
- When it fits
- A defined goal with a start and an end
- What you get
- Clear scope and deliverable
- Limitation worth knowing
- Does not cover ongoing support
Pricing and SLA terms are discussed on a call and are not published on the site.
Governance
Four mechanisms that keep a system healthy over time
Technical-debt control
Duplicate automations, dead fields and over-broad permissions are measured and managed as real backlog items, with dedicated capacity allocated to them.
Release readiness
Salesforce ships three releases a year. We check in advance what changes, what might break and what is worth adopting.
Adoption measurement
Usage metrics by role reveal where the process is not actually working — before report data stops being trustworthy.
FAQ
Support & ongoing care — questions we hear often
What is the difference between support and ongoing managed care?
Support handles incidents and user questions and restores the system to a working state. Ongoing care also asks what should change: prioritizing enhancements, controlling technical debt, design review for larger changes, and a roadmap that looks ahead. An organization that buys support alone ends up with a system that works but never improves.
What counts as an urgent incident?
An event that blocks a business process for a group of users with no reasonable workaround — a failure in lead intake, a core automation crashing, or an integration that stopped running. A request for a new field or a new report is not an incident, however important it is. That distinction is agreed in writing up front.
Does every change go through a test environment?
Yes. Every material change is built in a sandbox, tested against a business scenario and only then released to production inside a defined window. The only exception is fixing a blocking incident, and even then it is documented and returned to the standard track in the next cycle.
How is priority decided?
By business impact, number of users affected, risk and effort — in a standing prioritization meeting with the process owner on the client side. We do not prioritize alone, because prioritization is a business decision, not a technical one.
What happens to technical debt accumulated before we started?
At the start of the engagement we map duplicate automations, unused fields, untested code and over-broad permissions. The findings enter a prioritized list, and a fixed share of the monthly capacity is allocated to reducing debt — otherwise it only grows.
Can we start ongoing care even if you did not implement the system?
Yes, and it is a common case. In that situation we start with a short system review that maps the current state, so the engagement is based on understanding rather than guesswork.
Next step
Review a support model
We will look at usage scope, open needs and the level of governance required — and propose a model that fits your pace.