Choosing a partner to build platform extensions is mostly about avoiding a specific outcome: work you cannot maintain, cannot understand, and cannot move away from.
The single most useful question: "if we stopped working with you tomorrow, what would we have?" A good answer includes source in your repository, documentation, credentials you control and a deployment process someone else can run. A vague answer is the whole assessment.
What actually predicts a good outcome
| Signal | Good | Concerning |
|---|---|---|
| Response to your brief | Challenges parts of it | Agrees with everything |
| Estimates | Ranges with named assumptions | A precise number, immediately |
| Handover | Described concretely, unprompted | "We will document it" |
| Testing | Specific about approach | "We test thoroughly" |
| Who does the work | Named, and you meet them | "Our team" |
| Platform limits | Raised proactively | Not mentioned |
| Prior work | Will discuss what went wrong | Only successes |
A partner who pushes back on part of your brief is showing you what working with them is like. One who agrees with everything is showing you that too.
Questions worth asking, and what to listen for
- "What in our brief would you do differently?" — Tests whether they think or just quote.
- "What would make this go over budget?" — A good answer names specific risks in your situation.
- "Who writes the code, and can we meet them?" — Sales teams and delivery teams are frequently different.
- "What does handover include?" — Should be a list, not a promise.
- "Where will the source live?" — Your repository, ideally, from day one.
- "Tell us about a project that went badly." — Willingness to answer matters more than the story.
- "What will we need from you in a year?" — Honest answers acknowledge ongoing needs.
Start with a small paid piece of work. An audit, a discovery phase, or one contained feature tells you more about how a partner communicates, estimates and documents than any number of reference calls. It costs a fraction of the main engagement and it is the cheapest information available.
Contract terms that protect you
- You own the intellectual property outright, stated plainly.
- Source in your repository from the first commit, not delivered at the end.
- Credentials and accounts in your name, never the partner's.
- Documentation as a deliverable, with acceptance criteria.
- A defined handover with specific contents.
- A support period after delivery, with a scope.
- Exit terms agreed while the relationship is good.
Warning signs during delivery
| Sign | Why it matters |
|---|---|
| You cannot see the code | You are accumulating unknown risk |
| Progress reports lack specifics | Detail is being avoided |
| Every question needs a change order | The relationship is adversarial already |
| The named developer has quietly changed | Continuity is not being managed |
| Testing keeps being deferred | It will not happen |
| Documentation is "at the end" | It will be thin |
Rate is the wrong primary criterion
The cost of a platform extension is dominated by how long it takes and how much rework follows, not by the hourly rate. A cheaper team that needs three attempts, leaves no documentation and cannot hand over costs more than a more expensive one that does it once. Compare total cost of the outcome, including the year after delivery.
What a good engagement feels like
- You know what was done each week, specifically.
- Problems are raised early, not at the deadline.
- The partner sometimes tells you not to build something.
- You can read the code and the documentation makes sense.
- Another developer could take it over.
- Estimates change with reasons, not surprises.
Evaluating partners for platform work? Send us the brief and see what we push back on. See our Salesforce and Zoho services, and extend or build.