How We Deliver Salesforce Projects
Six phases, a reviewable artefact at the end of each, written sign-offs, and nothing in production without your approval.
This page describes how GeekMidst runs Salesforce projects. We work remotely from India, so the method is built for distance: decisions are written down, every phase ends with something you can review, and nothing reaches production without your sign-off. It's a general method that each proposal adapts to your scope.
For the principles behind it, see our approach. For commercial options, such as fixed scope or ongoing support, see engagement models.
Six phases, six artefacts
What each phase produces and how it is signed off
| Phase | Artefact you receive | Gate to move on |
|---|---|---|
| Discovery | Discovery notes, current-state findings and a scope statement with assumptions | You confirm scope and priorities |
| Architecture and design | Architecture document, data model and integration diagrams, security model | Your technical owner approves the design |
| Build | Working increments in a sandbox, demoed regularly, with configuration and code in version control | You accept each increment or log changes |
| Test | Test plan, test cases and results, with defects tracked to closure | Your users sign off UAT |
| Launch | Release runbook: steps, owners, timings, checks and rollback | A go/no-go decision made with you |
| Hypercare and support | Issue log during hypercare, then a support handover pack with documentation, known issues and runbooks | You accept the handover or move to managed support |
Quality gates
Each gate is a short written sign-off by a named person on your side. We don't start a phase on an unsigned gate; if we must proceed at risk to protect a date, we record what is at risk and who accepted it. Design reviews check limits, licences and editions against the vendor's documentation before build, because a design that needs a feature you don't license is cheaper to fix on paper.
Environments and release management
- Sandboxes first. All build and testing happens in sandboxes or scratch orgs. Production changes only through a planned release.
- Version control. Metadata and code live in a repository and are deployed with the Salesforce CLI (
sfv2) or Lifecycle Center (formerly DevOps Center), depending on what your team uses. - One promotion path. Typically development, then QA, then UAT, then production, with the same package moving through each.
- Release windows are agreed with you, set in your time zone, kept clear of your holidays and busy periods, and each has a rollback plan.
The details are on our CI/CD and release management architecture page.
How changes are controlled
Scope changes go through a simple change request: what's being asked, why, its effect on effort, timeline and risk, and who approved it. Clarifications within the agreed scope are logged but don't need a formal request. Nothing outside scope is built until it's approved in writing.
Communication across time zones
- A weekly status note covering progress, decisions needed, risks and next steps.
- Live sessions in the hours we share with you, which vary by country; our location pages list the overlap.
- A written decision log, so nobody has to remember what was agreed on a call.
Security and data handling during delivery
- No credentials in chat or email. We never ask for passwords or tokens in messages. Access comes through your own user provisioning.
- Least privilege. Named accounts with only the permissions each task needs, time-limited where possible and removed at the end.
- Production access is the exception. Read-only where it's needed at all, and write access only for agreed release steps.
- Test data. Masked or synthetic data in sandboxes wherever possible. If real personal data is needed, you settle the transfer basis with your legal adviser first.
- Integration secrets stay in Named Credentials or your secret store, never in code.
- AI tools get read-only access first, and any write action needs a person to confirm it.
Our trust and evidence page shows what we publish about how we work.
What you provide
- a project owner, and a named decision-maker for each gate
- sandbox access and user accounts, provisioned by your admins
- subject-matter experts for workshops, and testers for UAT
- details of your licences and editions, and vendor contacts where needed
- the policies we must follow, such as security, data handling and change windows
Questions we hear
Do you need admin access to our production org?
What if priorities change mid-project?
Sources
Talk through your project
Tell us what you need delivered and by when, and we'll explain how the phases and gates would fit your scope.
