CobbleWeb Client Journey: Build your Online Marketplace the Smart Way

Who is this article for? 

If you have an online marketplace idea you would like to make a reality, but you are unsure or intimidated about how to get started, then this is for you. This article will illuminate how CobbleWeb’s marketplace development framework works and why it offers you the best chance of reaching your business goals (and avoiding the perils that lurk in the complex jungle that is online marketplace development).

Read on to discover what our value propositions are and all the steps you can expect on your CobbleWeb client journey.

A little bit of background 

One of the most common queries we get from first-time marketplace entrepreneurs is to help them untangle the mess that a turnkey “marketplace builder” got them into. Whether lack of extensibility, clunky UX that chases users away, unscalable infrastructure, or unsupported revenue streams – the issues seem endless. And the missing ingredient every single time? 

DIY marketplace builders are not the only guilty parties. A common phenomenon that makes us chuckle at CobbleWeb are software development agencies that plaster technology badges like Microsoft Partner, Google Cloud Partner or AWS Partner all over their home pages. This ‘proof’ of technical prowess is usually accompanied by a long list of all the different products and features they have built. 

We call the above type offerings assembly-line syndrome. Projects are simply churned out based on templates and tech biases, with minimal regard for business outcomes. There’s a reason why turnkey marketplace builders and non-specialised software developers obfuscate their case studies with vanity metrics (traffic, investment rounds), instead of concrete business results such as liquidity, profit, turnover, and traction.

Check out some other red flags when it comes to selecting a marketplace development partner here:
How to choose a champion software developer for your marketplace project

Back to the real deal though 😊. As experts in custom marketplace development, we pride ourselves on serving our clients the best possible opportunities for success. Building an online marketplace can be a complex and intimidating affair, fraught with numerous pitfalls. Which is why we spend lots of time and effort on perfecting our recipe for tasty marketplaces that will delight your users.

The two main ingredients of our framework: 

A proven product development approach 

combined with

A highly-efficient project management process

User-centric product-led marketplace development

At the heart of our recipe is a desire to build the best possible marketplace solutions in the most efficient way. For that purpose, we follow lean methodology and agile principles to validate our clients’ assumptions about their marketplace concepts.

Our product development approach utilises basic product versions (MVPs) and rapid cycles of experimentation, based on granular user feedback, to refine your value proposition and establish product-market fit. This laser-like user-focus – in combination with our extensive marketplace development expertise – has several advantages over an off-the-shelf template:

• Get to product-market fit faster (utilising iterative “build – measure – learn” loops) 
• Less risk of wasting your precious resources (we know the challenges and pitfalls)
• Flexible and extensible (better alignment of technology and business goals)
• Scalability is built into our tech stack selection.
• Better at identifying opportunities (new revenue streams, growth hacking, etc.)

Learn more about:
Our best-in-class marketplace development approach

But your journey with CobbleWeb involves much more than software development!

We see ourselves as guides that collaborate closely with our clients at each stage of their marketplace project to give it the best chance of success. 

So let’s take a closer look at all the project steps and interactions that you can expect on your CW journey:

1. Enquiry phase
2. Engagement phase
3. Development phase
4. Optimisation phase

Enquiry phase

When you first reach out to us, it may help to have a few ducks in a row. Here are some of the aspects of your marketplace concept that you should consider before we engage:

Tell us your vision. We want to understand your marketplace concept from the ground up. Which parties (buyers and sellers) are you aiming to connect? What problems are you solving? And how do you see your platform addressing it?

Unpack your market. Who are your ideal buyers and sellers? What research have you done to understand their needs and behaviours? Have you identified specific pain points that your marketplace can alleviate?

Charting your course. How you envision your users interacting with your platform. What journey will they take? What features are essential to make this experience seamless and rewarding? And how will you turn this interaction into a profitable business? Have you investigated a go-to-market strategy or considered a revenue model?

Team & Status Quo. Let’s discuss your team’s expertise and the stage of your project. Are you just starting out, testing the waters with a low-fidelity MVP? Or do you have a live platform that needs a boost? What technologies have you tested?

Budgeting for the long haul. A successful marketplace is a journey, not a destination. it requires a process of refinement until your intended users’ needs are met satisfactorily. That means multiple iteration cycles to refine your value proposition. Your budget should therefore align with a development road map instead of focussing on a single cost. 

Don’t worry if you don’t have all the answers. We’re here to help you fill in the blanks. 😉

Engagement phase

First meeting: getting to know each other

Once you have scheduled your first (remote) meeting, we will go over your initial enquiry in more detail to gain a solid understanding of your marketplace concept. We will share examples of previous projects and technology we worked with. This is also an opportunity for you to grill us about anything. Get to know us!

Once we have a broad understanding of your marketplace vision and business case our technical and business teams will put their heads together to map out the main user journeys and identify the features that will support them. There may be some follow-up questions to clarify certain aspects.

The product roadmap

User journey mapping provides a high-level view of the user experience. We start by outlining the stages in the paths that different user types (e.g. buyers, sellers, and marketplace administrators) take to solve their particular cohort’s pain points and achieve satisfactory outcomes. Any existing business data provided by you, such as market research, traction stats, or revenue numbers, will be taken into consideration.

For brand-new marketplaces we also look at:

• Acquisition – how do users find your marketplace? E.g. via organic search (SEO), social media, affiliate marketing, or paid search (PPC).

• Activation – how do users interact with your marketplace? E.g. via landing pages, product navigation, and customer onboarding.

In addition to the user journeys, we also take the following aspects into consideration: duration (each epic* should take 20 – 40 man days to complete), dependencies (some 3rd-party integrations may impact multiple user journeys), capacity (availability of team resources), and risk (some features may increase or decrease your project’s risk profile).

At the end of this exercise we will supply you with the following:

• A list of epics* that supports the primary business goals
• A ballpark cost breakdown based on high-level estimates of each epic

If you are comfortable with the ballpark cost breakdown it’s time for the next step:  drilling down into each epic so that we can provide you with more granular budget, resource, and timeline estimates.

Second meeting: storyboard and estimate

In our next meeting we will present you with a storyboard and a more detailed estimate of costs. The storyboard breaks down each epic into a collection of interrelated user stories* that describe part or all of a specific user journey [See below image].

During this meeting we will also take you through projects with similar features we have worked on and share our recommendations for the most suitable technology stack. This will help you, with our assistance, to prioritise initial features according to cost and impact. 

* User stories are short descriptions of user-product interactions written from a particular user type’s perspective. The user could be the product owner, a platform admin, a seller, a buyer, a  guest, etc.

The proposal

Once the initial features have been signed off on, we’ll forward a proposal that includes the project scope and goals, the finalised storyboard and associated cost breakdown, the estimated timeframe, as well as some terms and conditions.

Proposal costs are time based and typically include the following services:

Service	Core Deliveries
Business analysis	Create detailed briefs with clear requirements and expected outcomes for each project, identify business needs and evaluate potential business solutions, define project scope and objectives, ensure technical feasibility.
Project management	Identify potential roadblocks, prioritise features, plan sprints, track epic progress, calculate delivery dates, identify and manage risks, track budget, adjust project scope, manage support requests.
UX/UI design	Map user journeys based on user analysis, create prototypes/mockups, design application user interfaces.
Software engineering	Construction of the marketplace platform via a combination of programming languages, frameworks, and architectures. Includes the integration and optimisation of 3rd-party software such as payment platforms (e.g. Stripe).
Quality assurance	Define quality criteria, document the QA process, and implement QA tools. Monitor and regularly test the application to ensure it functions as planned and to correct any flaws before commercial launch.
Infrastructure set-up	The scaffolding upon which your marketplace will be built. Includes cloud servers and databases (e.g.AWS), as well as development and staging (for application testing) environments.
Deployment	Make the live application available to public users so that they can interact with it. Includes the planning, scheduling, and controlling of software releases to ensure smooth deployment and minimise risks.
Analytics	Selection, tracking and evaluation of relevant metrics to test the assumptions upon which you have built your platform. Also provides business intelligence for future growth paths.

The proposal includes a budget calculator that will give you a cost breakdown of the various project services. Changes to the storyboard will automatically update the cost breakdown.

Timeframes are usually expressed as the number of available man days per month over the number of months required to cover all the estimated epics. For example: Project kick-off is the 13th of June, with a monthly capacity of 40 man days for five months (for a total of 200 man days).

* Important! The scope, cost and timeline may change during discovery. That is because some complexities may only reveal themselves at a later stage. Changes in the chosen solutions may also impact the budget. For example, when hiring a third-party specialist or implementing a new more suitable technology.

Additional user stories

Note that user stories added on a contingency basis after project commencement (i.e. signing of the contract) are not covered by the proposal. They can be added to the storyboard during development at an extra cost, subject to capacity constraints.

Team composition

An average-sized marketplace project with medium complexity will usually have two squads assigned to it. Each squad is led by a product manager and a tech lead. Both squads are supported by a UX/UI designer and a DevOps specialist.

Two developer squads:

• A lead squad and a subsidiary squad
• 5 – 6 software engineers per squad
• Combination of full-stack -, front-end -, and back-end specialists

Two product managers (one per squad):

• The PM of the lead squad will be your primary point of contact
• They are the key pivot between your business and the development team
• Responsible for driving team objectives and goals

Two technical leads (one per squad):

• A highly experienced software engineer
• Responsible for assigning and supervising tasks, identifying and fixing technical problems, and resolving technical queries

A UX/UI designer:

• Works on graphic elements, page layouts, and interface design

A DevOps specialist:

• Sets up the coding pipeline by dividing work into smaller manageable tasks
• Sets up the platform infrastructure, e.g. AWS servers
• Sets up the testing environment
• Monitors the development, integration and deployment process
• Maintains, monitors, and troubleshoots applications in production
• Evaluates each release and generates reports 

Payment Terms and Capacity Options

Our project payment schedule has been designed to balance risk and reward for both parties. In a nutshell, you will be responsible for a rolling deposit and a monthly bill.

The deposit: To get the project off the ground, we require a rolling deposit of 30% of the allocated development capacity (i.e. man-days per month). Thus if 40 man-days per month have been allocated to your project, the deposit would work out to 12 times the daily rate. Note that if the monthly development capacity is increased or decreased, the rolling deposit will be adjusted accordingly.

Monthly billing: Each month you will receive a detailed invoice for the epics and miscellaneous (Kanban) work completed the previous month. This will need to be settled within fifteen days of receipt.

We’ve built some flexibility into the payment schedule by offering two monthly capacity options. Each one has its own advantages, which will depend on your budget and timeline constraints.

Secured monthly capacity: This option reserves agreed-upon resources for your project, e.g. 20 man days per month. This is a contractual obligation and you will have to commit to spending the agreed-upon amount every month for the duration of the contract.

Agreed-upon monthly man days is an average and may fluctuate with up to 30% depending on the length and complexity of the epic. For example, an epic that was estimated at 60 days may require 15 man days in month one, 25 man days in month two, and 20 man days in month three.

Ideal for rapid execution, this option works well for clearly-defined product roadmaps that require tight control over the timeline.

Pay-as-you-go: Work is conducted based on available resources. You decide how many work days you would like to reserve a month in advance. We will execute accordingly, subject to our own capacity constraints. For example, in June, you request 7 man days of work to be done in July. We may be able to offer you 5 man days.

This gives you more control over your budget and is ideal for very early-stage projects or third-party integrations with existing marketplaces. 

Budget tracking

Transparency is one of our core principles. Which is why we have made it as easy as possible for you to stay on top of your budget. 

During the development phase you will receive weekly notifications of the time spent (month-to-date) on each epic. Any potential budget overruns will be immediately flagged and communicated to you. You will also have access to the Jira project management tool so that you can check issues (Jira-speak for tickets) and track your budget at any time.

Once you have accepted our proposal, we can get down to the really exciting stuff – building your marketplace platform!

Development phase

Our development process rests on three interrelated pillars that ensure transparency and superior outcomes. Firstly, we are committed to close collaboration and iterative improvement throughout the project’s lifecycle. Secondly, we emphasise ownership and accountability at all levels. Thirdly, we embed a culture of quality assurance in every step of the development journey. 

Ownership of your project is driven in a number of ways:

Collaboration. Your assigned team will work closely with you, delivering regular updates, scheduling meetings, and arranging demos.

Business goals. The team will keep the goals of each epic front of mind during every phase (discovery, design and development) to ensure the best possible outcomes.

Flexibility. The technical team is given space to come up with the best solutions for your project.

Accountability. Each team role has clearly defined areas of responsibility and expectations.

Our emphasis on ownership has proven its worth as a productivity driver, in particular keeping the development timeline within agreed parameters.

When it comes to quality assurance, our philosophy is that quality is the responsibility of everyone involved in the project. We promote this mindset by putting guidelines, including functional specifications, in place for each task and involve clients closely in the testing process.

You will have the opportunity to approve functional specifications and graphic designs from the outset. After each milestone in the development roadmap, the product manager will schedule a demo to present the work done up to date. Milestones are aligned with user journeys to give demos a more realistic feel.

Demos are followed by User Acceptance Testing, where you can test functionalities and user journeys in a simulated live environment. User-friendly feedback buttons allow you to leave feedback directly on the site. This is supported by tools like Bugherd and Usersnap, which automatically link technical details such as the browser version and which UI elements were interacted with.

Discovery

Anyone who has ever been involved in any form of project management will agree that the better the planning phase, the better the execution, and usually the project outcomes. 

The discovery stage of the development phase is therefore considered absolutely critical to building a marketplace platform that delivers the best possible business results. Which is why we’ve made sure that there is a clear process and close collaboration between all the stakeholders.

Our discovery process contains three interrelated steps, each with its own deliverables: interrogation, design, and documentation. At the end of the discovery we will be in agreement about (1) what we are going to build in version 1.0, (2) how we are going to build it, and (3) what the resource requirements are.

Step 1: Interrogation

The purpose of this step is to gain a deeper understanding of your business and its users. In a series of meetings, we will discuss user personas, user journeys, and business parameters in more detail. We evaluate the friction and goals of each feature of the platform and whether it makes sense to invest any effort in them. 

Deliverables: 

• A grooming brief. Check out this example we created for a new feature of a property management platform.
• User data evaluation in case of an existing platform (E.g. engagement metrics or drop-off rates)

Step 2: Design

The design team – in  close collaboration with your UX/UI designer (if you have) and our developers – starts working on the look and layout of the platform, taking into account the various user scenarios and their corresponding user flows. This step evaluates which solution would be best suited to the frictions and goals identified previously. 

Deliverables: 

• List of user flows*
• Design elements such as branding
• Mockups, wireframes, flow charts

*User flows are more granular than user journeys and focus on the practical steps required to accomplish on-platform tasks.

Step 3:  Documentation

During this step we capture the business rules in more detail. We map out and document how things should work from both a functional and technical perspective. Our senior engineers are closely involved to (1) ensure epics are technically feasible and (2) map out the technical requirements that will support them best.

Deliverables: 

• A detailed storyboard that takes technical and functional requirements into consideration. This includes the more granular re-estimation of costs we mentioned previously.
• Functional specifications: This entails use cases for each epic (e.g. onboarding of sellers vs buyers), UI interactions (e.g. what happens when a button is clicked), a mapped-out revenue model, and a glossary that defines the terms that will be used in project.
• Technical specifications: APIs, the data model, email triggers, automated tasks, and integration documentation such as how to manage third-party endpoints.

The prepared documentation is shared with you so that you can comment. After we’ve resolved all your queries and you’ve signed off on the discovery and re-estimated epics, we can progress to the actual engineering stage.

Software engineering

We kick off the engineering stage by scheduling and assigning a delivery date for each epic. The first version (1.0) will be delivered epic by epic, each of which usually runs over one or two sprints. 

The average epic requires 20 man days to complete, at the end of which a demo is given  before the feature or feature component is tested by you in a UAT environment. Note that some early-stage epics, which require additional technical foundation or dependencies (which can’t be split into smaller epics), may require up to 50 man days.

The size and frequency of epics are also influenced by how soon you would like to release a

feature or version. Sometimes it makes sense to split a large epic into several smaller epics to ship more often or to address urgent issues. 

In addition to epics, sprints can also contain Kanban tickets. We use Kanban for tickets that involve:

• Bugs that are independent (standalone) issues as a result of previously released epics
• Urgent bugs that have an impact on the operability and business viability of the platform
• Upgrades or new features that require a small effort (less than 2 days). This minimises the risk of tech debt or implementing a non-optimal solution. 
• Analysis that supports a potential epic. It could for example be an investigation of the feasibility of a new payment provider that will be discussed with the client during the discovery phase. Otherwise, analytical tickets usually form part of a signed-off epic. 

* Sprints are fixed-length development cycles – usually  two weeks – during which a set amount of work is completed.

Client support dashboard

We use the Jira Service Desk ticket system for issue logging, comments and billing. It offers individual accounts for different users which has several advantages:  easy to keep track of work progress, simplifies the billing process, and makes the support process much more transparent. 

Members of both teams are able to log issues, report bugs, view who raised tickets for quicker follow-ups, and receive notifications of new comments on a specific issue. Access levels can be set for each user.

Final test and platform launch

Once all the epics for version 1.0 are completed you will be able to test the platform as a whole and report bugs and/or adjustments. We iterate until all queries have been resolved.

Post-delivery support

This phase consists of optional, additional services. Our basket of support services (preventative, corrective and evolutive) are geared towards platform risk management, health monitoring, and growth strategies.

Preventive support: Pay-as-you-go service to explore data to pre-empt issues that may crop up in future. This requires a one-time setup fee for implementation of support software (error tracking tools, notification system) and technical metrics. Note that the cost of software licences is not included in this fee.

Corrective support: Tracking and fixing platform issues that crop up after the release of version 1.0. Note that these are separate from issues picked up during development testing.

Evolutive support: Identifying opportunities for platform optimisation, growth and scaling. For this we will group tickets into epics with estimates to help you prioritise work and build a strong product roadmap.

Support components

★ Setting up and monitoring the technical health of the platform utilising tools such as New Relic, Sentry, CloudWatch and/or Airbrake.

★ Application Performance Monitoring to identify and implement platform optimisation opportunities (e.g. API server response times)

★ Tracking and fixing potential API, front-end (JavaScript) errors, and server errors

★ Installation and maintenance of a comprehensive notification system which will include logs and alerts

★ Identification of relevant technical metrics and implementation of tools to measure them

Key user journeys to be monitored 

The following metrics will be monitored for back-and frontend errors and performance:

★ Customer onboarding

★ Business onboarding

★ Subscription flow

★ Payment flow

★ Offset tracking

Key technical metrics that will be tracked

★ API requests per second

★ Average response time

★ Peak response time (notifications will be implemented to identify peak times)

★ Server uptime (to make sure the platform is always available for use)

★ HTTP server error rate

★ Time to last/first byte (if this takes too long we look at overall file weight (JS, CSS, images), user location, etc.)

★ Thread count – number of concurrent server requests at a particular time. E.g. multiple customers buying the same item at the same time. It’s usually a sign that the platform needs to be scaled further (bigger servers etc.)

---

FAQs

---

---