You merged the last pull request, the staging demo looks great, and the client is ready to say "thanks, we're done." On a Sharetribe project, that moment is where a lot of future pain gets created. A working demo proves that something runs today. It does not prove that anyone else can deploy it, maintain it, or safely change it six months from now.
This post is a practical handover checklist for Sharetribe marketplace builds, written from the point of view of the team doing the delivery. Treat it like a definition of done for the whole project rather than for a single ticket. If you are on the founder side, you can use the same list to review what you are being handed.
One caveat before we start: scale the checklist to the scope. A pure no-code configuration in the Sharetribe Console will not produce a repository, a CI pipeline, or a custom hosting setup. A heavily customised Sharetribe Web Template will produce all three. Skip the sections that genuinely do not apply, but write down that you skipped them and why.
1. Reconcile the scope against what actually shipped
Start from the agreed scope of work, every approved change request, and the acceptance criteria. Then walk through each requirement and give it one of three states:
- [ ] Complete – delivered and verified
- [ ] Deferred – intentionally moved out of this phase
- [ ] Awaiting decision – blocked on a business call, not on engineering
The trap here is vague sign-off. "Booking works" is not an acceptance statement. "A logged-in customer can request a booking for an available date range, the provider receives a notification, and the provider can accept or decline" is. Name the action, the conditions it must work under, and the evidence you used to confirm it (a test run, a recording, a screenshot of the transaction in the Console).
If requirements moved during development, which they almost always do, update the acceptance record so it reflects the scope you actually built, not the one from the kickoff deck.
2. Code, access, and the rights attached to it
For custom-coded builds, the repository section of the handover should answer three practical questions:
- Where does the code live, and who has access?
- Which branch or tag is running in production?
- How does a new developer get it running locally?
That third point deserves a real README, not a Slack message. Something like:
git clone <repo-url>
cd marketplace-web
yarn install
cp .env-template .env # fill values from the secure vault, never from the doc
yarn run dev
Here is the part developers often skip: access is not the same as ownership. Giving the client admin rights on the repo does not settle how the code may be used. The contract and the licences do. Commercial plugins, paid templates, and third-party dependencies may come with terms that do not allow the same transfer or reuse as your own custom work. List them explicitly.
Finally, write a short customisation log: what you changed in the template, where it lives, and why. The goal is that another qualified Sharetribe developer can locate an important change and understand its purpose without needing a call with you.
3. Accounts, environments, and deployment
The account register
A marketplace rarely runs on Sharetribe alone. You will typically have hosting, a domain, a payment provider, transactional email, and a few integrations. Build a simple register:
- service: Payment provider
business_owner: Founder (company account)
billing: Company card
authorised_users: [founder, ops lead]
recovery: Company email + 2FA device held by founder
- service: Frontend hosting
business_owner: Company
billing: Company card
authorised_users: [founder, dev team]
recovery: Company email
If the delivery team manages any of these on the client's behalf, document how access, data, and configuration would move if that arrangement ends. And please: transfer credentials through a secure method, not inside the handover document itself.
Environments
Sharetribe gives you Test, Dev, and Live environments. The handover should state which frontend points at which environment, and where acceptance testing was actually performed. A flawless demo on a dev application tells you nothing certain about production configuration. Verify Live settings through an agreed release check, and do not use real customer transactions as your test suite.
Deployment
For a custom frontend, record:
- [ ] Hosting provider and account owner
- [ ] Release process and who is allowed to publish
- [ ] Currently deployed version
- [ ] Required environment variables and configuration
- [ ] Rollback or recovery procedure if a release fails
Remember the split of responsibility: Sharetribe keeps operating the hosted backend, but a custom frontend adds hosting and maintenance work that belongs to someone else. The handover should say who.
4. Test journeys, not screens
Unit tests and screen-by-screen QA catch a lot, but marketplace bugs love to hide in the gaps between steps. Test the complete actions customers, providers, and operators need to finish.
Pick scenarios that match the business model:
- Rental marketplace: availability → booking → cancellation → deposit handling
- Service marketplace: request → provider response → job completion
Then add the exceptions the system is supposed to handle. A useful example comes from Journeyhorizon's rental marketplace case study for Side By Side Share, which involved identity verification, deposits, location privacy, agreements, and messaging integrations. The point is that a verification screen rendering correctly is only half the requirement. You also need to agree what happens when verification is incomplete or fails, and how that changes the user's next step.
Keep the test record easy to read: scenario, expected result, observed result, status, open issue link. Be honest about its limits, too. A test report supports acceptance of what was reviewed; it does not prove the absence of defects.
5. Document integrations like you will be paged for them
For each integration, write down:
- What is connected and what data moves between systems
- What triggers each exchange
- Which system is the source of truth
- Required permissions and known constraints
Then cover failure handling, which is the section everyone forgets:
- [ ] How does a failed update become visible?
- [ ] Are there automatic retries?
- [ ] Who investigates?
- [ ] What manual recovery steps can an operator take?
Pair this with operating instructions for recurring tasks: reviewing new listings or submissions, handling transaction exceptions, updating content, and triaging reported problems. A short recorded walkthrough next to the written docs makes the transfer of responsibility much smoother.
6. Known issues and post-acceptance support
Before closing the project, split the backlog into three buckets: unresolved defects, approved exclusions, and future feature requests. Each item gets an impact, a status, and a next action.
Then define support after acceptance: the contact route, what is covered, response expectations, and who owns hosting, application maintenance, and third-party services. Keep any initial defect-fix window clearly separate from ongoing maintenance and new development, or you will spend months arguing about what counts as a bug.
If you customised the Sharetribe Web Template, agree on how upstream template updates will be reviewed and applied. And if a different team is taking over, schedule a walkthrough of the app, the repo, the deployment process, and the open issues before they touch anything.
A quick FAQ for the client conversation
Does every Sharetribe project need a repo? No. Pure Console configuration may not create one. If there is custom code, confirm how it is delivered, who can access it, and the usage rights.
Does receiving the source code mean the client owns it? Not automatically. Check the agreement and the terms of any third-party components.
Must every issue be fixed before acceptance? It depends on the acceptance criteria and impact. A bug that blocks an essential journey is a different decision from a polish item that can be scheduled.
How can a non-technical founder review this? Walk through the business journeys, the account register, the operating instructions, and the open-issues list with the team, and ask for demos tied to specific acceptance criteria. For code quality, security, or architecture, an independent technical review is reasonable.
Takeaway
A good handover is a record of three things: what was delivered, how it was verified, and who maintains it from here. Ship that alongside the code and the next developer, possibly future you, will thank you.
This checklist is adapted from Journeyhorizon's Sharetribe project handover guide. If you want a second pair of eyes on a Sharetribe build or handover, the team behind Journeyhorizon's Sharetribe development services does this kind of review regularly, and you can find more of their marketplace engineering work at Journeyhorizon.
Top comments (0)