Every Sharetribe project I have seen go sideways shares one trait: someone opened a code editor before they opened the Console. The team assumed the platform could not do something, wrote a ticket, estimated it, and started building, only to discover weeks later that a configuration toggle or an existing integration would have covered most of the need.
This post is a practical decision framework for developers and technical founders working on Sharetribe marketplaces. The goal is simple: treat custom code as the last step of a diagnostic process, not the first. It draws on the guidance in Journeyhorizon's article on when to customize Sharetribe with no-code versus custom code, reframed as something you can actually run through before a sprint planning session.
The core rule: code is a response to a proven gap
A Sharetribe marketplace can be launched and operated without any custom development. That is the whole point of the hosted backend and the no-code configuration layer. Custom code earns its place only when a specific group (customers, providers, or the operations team) needs something the current setup cannot reasonably support.
Valid triggers usually look like one of these:
- a booking or ordering journey that has to behave differently from the default flow
- an integration with another system that the business genuinely depends on
- a dedicated mobile app that users have shown they need
An untested assumption about what users want is not a trigger. It is a hypothesis, and hypotheses get validated before they get built. Also remember that platform capabilities change over time, so check the current configuration options and documentation before you classify anything as a development task. Sharetribe's own guidance on custom coding makes the same point: get the no-code setup as close to your requirements as possible first.
Step 1: Run the default journeys end to end
Before writing a single requirement, configure the closest workable version of the marketplace and walk through it like a QA engineer.
[ ] Provider path: sign up -> complete profile -> publish a listing
[ ] Customer path: search -> view listing -> transact -> complete
[ ] Operator path: the admin work needed to keep both paths running
[ ] Log every gap as an observable problem, not a feature idea
That last line matters more than it seems. "We need better onboarding" is not actionable. "Providers cannot finish registration without emailing support to send extra documents" is. The second version tells you who is blocked, where, and what the workaround currently costs.
For each logged gap, check three places before escalating: Console settings, supported integrations, and operational alternatives (a manual process, clearer copy, a form outside the platform).
Step 2: Map the requirement to the right first move
A useful way to triage is to match the type of requirement to the first thing you investigate:
| Requirement type | First move |
|---|---|
| Content, branding or field changes | Check what the Console currently allows |
| A different customer or provider journey | Map the required steps against the existing flow |
| Data exchange with another system | Review available connectors and API requirements |
| A dedicated mobile app | Assess a separate frontend app or a suitable template |
| A feature nobody has asked for or tested | Validate demand before building |
Treat this as a triage table, not a list of hard platform limits. What is possible depends on your exact requirements and on what the platform supports at the time you check.
Step 3: Spec the unhappy paths, not just the happy one
When a requirement does point to custom code, the most common estimation mistake is specifying only the success path.
Custom transaction flows
Imagine a service marketplace that needs a structured request, a clarification step from the provider, and explicit customer approval before the job proceeds. The happy path is three screens. The real scope includes the exceptions: the provider never responds, the customer changes the request mid-flow, the transaction is cancelled halfway. If those branches are not in the spec, they will show up in production.
Integrations
"Connect our CRM" is a starting point, not a requirement. Manual copying between systems is fine early on; it becomes an integration case when repeated transfers create delays, errors, or a growing workload. A spec worth estimating answers:
records: which entities move between systems
source_of_truth: which system owns the authoritative value
trigger: which event causes an update
permissions: who can read and write what
duplicates: how they are detected and handled
failure: how a failed sync is surfaced and recovered
Mobile apps
A mobile app should solve a demonstrated problem: repeated tasks, friction in the mobile browser, something an app would clearly improve. A marketplace that already works well in a mobile browser may not need one. And an app adds its own overhead: release management, device testing and ongoing support.
Step 4: Prioritise with evidence, not opinions
Support tickets, user interviews, abandoned journeys and repeated admin tasks are all evidence. Look at them together. One abandoned booking tells you nothing about why the person left, and it certainly does not prove a new feature would have saved it.
For every candidate customisation, fill in a short record:
- Problem: what is hard or impossible today?
- Evidence: what observations support it?
- Alternative: could configuration, clearer instructions or a temporary manual process solve it?
- Outcome: what will you measure after release?
- Ownership: who runs and maintains the solution?
Here is a typical example. Providers keep submitting incomplete information. The root cause could be unclear instructions, missing validation, or a workflow the platform truly does not support. Each cause implies a very different scope, cost and maintenance load, so diagnose before you build.
Step 5: Budget for operations, not just the build
Custom code has a lifetime cost. With a custom frontend, Sharetribe still runs the hosted backend, but your frontend needs external hosting and maintenance, and any extra services need named owners. If you customise the Sharetribe Web Template, upstream template releases do not flow in automatically; someone has to review and merge them.
Agree on these before kickoff:
- access to the repository, hosting accounts, deployment config and credentials
- the release approval process and who monitors production
- how production incidents are handled
- documentation that the business can follow even if the dev team changes
Testing should cover failure conditions specific to your change: interrupted payments, cancelled transactions, listings that become unavailable, and external services that stop responding. Ask for acceptance criteria and test results for your implementation, not generic quality promises.
Step 6: Write a brief a developer can actually assess
A good brief describes current behaviour, the required change and the business reason, ideally with screenshots, screen recordings or a process diagram. For instance: approved provider records must be pushed to an operations system, the marketplace holds the authoritative approval status, and failed updates must be visible to an administrator. With that, a developer can evaluate API access, constraints and options.
Ask for a proposal that lists assumptions, exclusions, dependencies, testing scope and ongoing responsibilities. If feasibility is unclear, start with a discovery task or a small proof of concept rather than a full build.
Ship the smallest independently testable change
Custom code makes sense when the requirement matters, the existing options have been checked, and someone owns the result. Where possible, pick a first release that can be delivered and evaluated on its own. Set acceptance criteria and baseline metrics before development begins, then review the results to decide whether further investment is justified.
A few quick answers to questions that come up in every project:
- Can we launch without custom code? Yes, if providers can publish, customers can transact, and your team can operate.
- Do we need a rebuild to add code? Not necessarily. The no-code setup can be the starting point for a custom frontend connected to the same hosted backend.
- What does it cost? There is no single price. Ask for estimates that separate the initial build from recurring hosting, maintenance and third-party costs.
Takeaway
Run the default journeys, log gaps as observable problems, check configuration first, and spec the failure paths before you estimate. That discipline turns a vague wishlist into a scoped, testable change.
If you are weighing a Sharetribe customisation and want a second opinion on scope, the team at Journeyhorizon offers Sharetribe development services and can review your current setup, the problem you are trying to solve, and the evidence behind it.
Top comments (0)