How we plan, build and support Salesforce work
Seven phases, explicit quality gates and written decisions. Here is how a GeekMidst engagement moves from first conversation to a stable, supported solution.
Many Salesforce problems are not caused by the platform. They come from decisions nobody wrote down, requirements that were never tested against real data, or a launch that skipped a step because the date mattered more than the outcome. Our approach is designed to make those failures less likely.
It is the same whether the work is a Marketing Cloud Engagement journey, a Data Cloud (now branded Data 360) data model, an Account Engagement nurture programme or a set of Flows and Apex in your core org. The size of each phase changes with the project. The order and the gates do not.
What we hold ourselves to
- Understand before building. We look at your data, your org and your current processes before proposing a design.
- Write decisions down. Every significant design choice is recorded with the options considered and why one was chosen.
- Build in sandboxes first. Production changes happen only after testing in a non-production environment and your sign-off.
- Test with realistic data. A journey that works for one test contact can still fail for ten thousand real ones.
- Hand over properly. Documentation and walkthroughs are part of the work, not an extra.
The seven phases
- 01
Discover
We meet the people who own the outcome and the people who run the process today. We review the org, data sources, integrations and existing automation, then agree goals, scope boundaries and what success will look like.
- 02
Architect
We design the data model, integration pattern, automation approach and security model. Options and trade-offs are written up so you can make informed decisions, not just approve a diagram.
- 03
Build
Configuration and code are built in a sandbox or development environment in small, reviewable increments. Code is version-controlled where your setup allows, and peer-reviewed before it moves on.
- 04
Validate
We run functional, data and regression tests, then support your team through user acceptance testing. Defects are logged, triaged and retested before anything is marked done.
- 05
Launch
We agree a cutover plan with a rollback path, a go or no-go checkpoint and named owners. For marketing work this includes seed lists, send windows and suppression checks.
- 06
Optimise
After launch we review how the solution behaves with real volumes and real users, then tune queries, journeys, segments or automation where the evidence supports it.
- 07
Support
You choose how ongoing help works: a clean handover to your team, a period of hypercare, or a continuing support arrangement.
Quality gates between phases
| Gate | What must be true to move on | Who signs off |
|---|---|---|
| End of discovery | Goals, scope and known constraints are written and agreed | Your project sponsor |
| Design approved | Data model, integrations and security approach reviewed; open risks listed | Your platform owner or architect |
| Build complete | Peer review done; unit tests pass; deployment steps documented | GeekMidst lead |
| Ready for UAT | Functional and data tests pass in a sandbox with representative data | GeekMidst lead and your test lead |
| Go-live approved | UAT signed off; rollback plan agreed; support owners named | Your project sponsor |
| Handover complete | Documentation delivered; walkthroughs held; access reviewed | Your platform owner |
How decisions get made
We keep a short decision log for every engagement. Each entry records the question, the options, the recommendation, who decided and when. It sounds bureaucratic, but it saves time: six months later, when someone asks why a field is a picklist or why a journey re-enters contacts, the answer is there.
When we recommend something, we say what it costs you in effort, licence implications (where relevant, confirmed against your contract) and future maintenance. If a requirement is better served by standard functionality than custom work, we say so, even if that means less work for us.
When scope changes
Scope changes are normal. We handle them openly: describe the change, estimate its effect on effort and timeline, and let you decide before work starts. Nothing is quietly added or dropped.
Working with your team
We prefer to work alongside your administrators, developers and marketers rather than around them. Shared channels, regular demos of working software and early access to sandboxes mean fewer surprises at UAT. If you want your team to own the solution after we leave, we plan for that from discovery, using guidance like writing requirements developers can build and programme governance for growing teams.
Where to go next
Engagement models
Fixed-scope projects, phased programmes, specialist support or ongoing help, and when each fits.
→Security and data handling
How we access client orgs, handle credentials and treat your data.
→Testing and QA
Structured testing for Salesforce and Marketing Cloud changes.
→Implementation checklist
A practical list you can use to prepare for any implementation.
→Questions we hear
Do small projects go through all seven phases?
Can you start with build if we already have a design?
Who owns the documentation?
What if UAT finds problems late?
Do you work with other partners or internal teams on the same programme?
Talk through your project
Tell us what you are trying to achieve and where things stand today. We will explain how this approach would apply to your situation.
