Two-Sided Marketplace

IT Staffing

B2B SaaS

Enterprise

Contract Systems

Cortech Talent

A managed talent marketplace started as a website that sold developers. I turned it into a two-sided platform with four distinct role systems, a semi-automated contract workflow, and a marketplace architecture covering the full lifecycle from application to contract end.

Two-Sided Marketplace

IT Staffing

B2B SaaS

Enterprise

Contract Systems

Role

Lead Product Designer

Scope

Full Platform V2, Both Portals

Platform

Web Application

Company

Cortechsols

The brief was a list of five website additions. I identified that what Cortech Talent actually needed was a two-sided marketplace. I defined the product before I designed it.

My Role

Every design decision across both portals. From zero.

I owned every design decision across both portals and all modules. Research, information architecture, user flows, onboarding systems, module design, and developer handoff documentation were all mine.

There was no existing design system, no prior UI framework, and no product specification beyond the V2 brief document. I defined what the product was before I designed what it looked like.

I owned every design decision across both portals and all modules. Research, information architecture, user flows, onboarding systems, module design, and developer handoff documentation were all mine.

There was no existing design system, no prior UI framework, and no product specification beyond the V2 brief document. I defined what the product was before I designed what it looked like.

"Two complete portal systems. Four role types. Five major modules per portal. One significant product decision reversed through reasoned pushback. The platform moved from a marketing website to a structured marketplace."

I owned every design decision across both portals and all modules. Research, information architecture, user flows, onboarding systems, module design, and developer handoff documentation were all mine.

There was no existing design system, no prior UI framework, and no product specification beyond the V2 brief document. I defined what the product was before I designed what it looked like.

The Problem

V1 was a marketing website. V2 needed to be a platform.

The CEO gave me a V2 brief containing five additions: an Apply button, pricing packages, a partnerships form, SEO pages, and an industries section. On paper, that described a larger marketing website. But the business was already operating like a managed talent service, which meant the real design problem was larger: clients, talent, partners, contracts, access rules, and lifecycle management all needed a product structure of their own.

What the brief asked for

"Apply as Developer" button + form

Pricing menu with fixed packages ($3,000/$5,500/$7,500)

Simple partnership contact form

SEO pages with "Hire Now" form

Industries page as trust signal

What was actually built

Complete Talent Portal with structured onboarding, profile insights, and evaluation trackingToptal

Hiring requirements capture system. Requirements generate the plan, not the other way around

Partner Portal with tiered access, commission tracking, and direct messaging

Full client marketplace with onboarding, matching, and contract lifecycle

Identified that a marketing website was not the product. Proposed the managed marketplace architecture instead

The brief was written by the same CEO who had just seen Easy Agent V1 fail at Doha. He brought me in to apply the same thinking: find what the product actually is, not what the brief describes.

"V1 was a website that described a service. V2 is a platform that delivers one."

The CEO gave me a V2 brief containing five additions: an Apply button, pricing packages, a partnerships form, SEO pages, and an industries section. On paper, that described a larger marketing website. But the business was already operating like a managed talent service, which meant the real design problem was larger: clients, talent, partners, contracts, access rules, and lifecycle management all needed a product structure of their own.

"V1 was a website that described a service. V2 is a platform that delivers one."

The brief was written by the same CEO who had just seen Easy Agent V1 fail at Doha. He brought me in to apply the same thinking: find what the product actually is, not what the brief describes.

Research and Discovery

Identifying the right marketplace model before designing anything

I started by identifying what type of product this actually was. The V2 brief described features. I needed to understand the underlying marketplace model first.

Cortech Talent sits between two existing models. Platforms like Toptal and Turing handle the full lifecycle including vetting matching and ongoing management but they are opaque to clients. Platforms like Upwork give clients direct access to talent but remove the managed service layer that Cortech’s business model depends on.

Cortech needed a third model: managed marketplace. The platform handles matching and contract management. The human team handles quality and relationships. The product makes both sides visible and accountable without removing the human layer.

I started by identifying what type of product this actually was. The V2 brief described features. I needed to understand the underlying marketplace model first.

Cortech Talent sits between two existing models. Platforms like Toptal and Turing handle the full lifecycle including vetting matching and ongoing management but they are opaque to clients. Platforms like Upwork give clients direct access to talent but remove the managed service layer that Cortech’s business model depends on.

Cortech needed a third model: managed marketplace. The platform handles matching and contract management. The human team handles quality and relationships. The product makes both sides visible and accountable without removing the human layer.

I started by identifying what type of product this actually was. The V2 brief described features. I needed to understand the underlying marketplace model first.

Cortech Talent sits between two existing models. Platforms like Toptal and Turing handle the full lifecycle including vetting matching and ongoing management but they are opaque to clients. Platforms like Upwork give clients direct access to talent but remove the managed service layer that Cortech’s business model depends on.

Cortech needed a third model: managed marketplace. The platform handles matching and contract management. The human team handles quality and relationships. The product makes both sides visible and accountable without removing the human layer.

Core finding: Clients needed structured access to talent without feeling like they were using a generic job board. Talent needed professional visibility without feeling like a commodity listed in a catalogue. The product had to serve both simultaneously with the same underlying data. These were not separate design problems. They were one interconnected system.

Product

Toptal

Turing

Upwork

Letsremotify

Cortech Talent V2 (only one)

Managed service layer

Client direct access

Client direct

access

Structured requirements capture

Structured REQ

capture

Structured requirements capture

Transparent contracts

Transparent

contracts

Transparent contracts

Talent

visibility

Talent

visibility

Talent visibility

Yes

Partial

Users and the power dynamics I designed for

Client

Needs vetted talent with structured requirements and transparent contracts. Does not want a job board wants a managed service with platform visibility.

Talent

Needs professional visibility and performance feedback. Does not want to feel like a listed commodity. Wants to understand how they are performing and growing.

Partner

Has a formal commercial relationship with Cortechsols. Needs different access rights than standard clients including direct talent communication and commission tracking.

Key Design Decisions

The decisions that turned a website into a marketplace

Decision 01 — Most Strategic

Redesign client onboarding as a requirement-capture system, not a sign-up form

Without structured requirements at onboarding, every hire still required a manual call. I made the platform collect that data itself.

The original V2 plan showed a basic sign up. I identified that client onboarding was actually the most strategically important flow in the entire product it was the moment the platform captured structured hiring requirements that would drive everything downstream including talent matching contract creation and quota management.

I designed the onboarding as a five-step system. Account setup, company details, then a hiring requirements screen where the client selects the number of talent units they need across role categories. This produced a quota. The next screen presented subscription plans calibrated to that quota. After plan selection, the client reached the most distinctive step: a talent design canvas where they could optionally refine their requirements by selecting specific skills, removing role types, and adjusting team composition. This step was optional and non-blocking.

The original brief had no mechanism for capturing structured requirements. Without structure at onboarding, every hire would still require a manual call. This decision was what made the platform actually function as a platform rather than an online inquiry form.

The original V2 plan showed a basic sign up. I identified that client onboarding was actually the most strategically important flow in the entire product it was the moment the platform captured structured hiring requirements that would drive everything downstream including talent matching contract creation and quota management.

I designed the onboarding as a five-step system. Account setup, company details, then a hiring requirements screen where the client selects the number of talent units they need across role categories. This produced a quota. The next screen presented subscription plans calibrated to that quota. After plan selection, the client reached the most distinctive step: a talent design canvas where they could optionally refine their requirements by selecting specific skills, removing role types, and adjusting team composition. This step was optional and non-blocking.

The original brief had no mechanism for capturing structured requirements. Without structure at onboarding, every hire would still require a manual call. This decision was what made the platform actually function as a platform rather than an online inquiry form.

The client’s requirements become the system’s matching criteria. Onboarding is not a form it is a structured intake.

The original V2 plan showed a basic sign up. I identified that client onboarding was actually the most strategically important flow in the entire product it was the moment the platform captured structured hiring requirements that would drive everything downstream including talent matching contract creation and quota management.

I designed the onboarding as a five-step system. Account setup, company details, then a hiring requirements screen where the client selects the number of talent units they need across role categories. This produced a quota. The next screen presented subscription plans calibrated to that quota. After plan selection, the client reached the most distinctive step: a talent design canvas where they could optionally refine their requirements by selecting specific skills, removing role types, and adjusting team composition. This step was optional and non-blocking.

The original brief had no mechanism for capturing structured requirements. Without structure at onboarding, every hire would still require a manual call. This decision was what made the platform actually function as a platform rather than an online inquiry form.

Decision 02

Separate client and partner access at the permission level, not just the UI level

A flat permission model would have let any authenticated user bypass the commercial relationship that protects the entire business model.

The product had two types of buyers: clients who hired talent and partners who were affiliates or agencies with a commercial relationship with Cortechsols. These looked similar from the outside but had meaningfully different access rights.

I designed the permission system so that several features were visible to all authenticated users but functionally inactive unless the user had partner status. The most significant example was the message initiation button on talent profiles. Clients could view any talent profile and see the message button but it was disabled with a clear explanation. Partners with active contracts could initiate direct communication.

This was not about restricting access arbitrarily. It reflected the actual commercial relationship. A client who has not yet entered a contract with Cortechsols should not have direct access to talent. A partner who has a formal relationship should. The tiered permission model protected the business model without making the product feel locked down.

The product had two types of buyers: clients who hired talent and partners who were affiliates or agencies with a commercial relationship with Cortechsols. These looked similar from the outside but had meaningfully different access rights.

I designed the permission system so that several features were visible to all authenticated users but functionally inactive unless the user had partner status. The most significant example was the message initiation button on talent profiles. Clients could view any talent profile and see the message button but it was disabled with a clear explanation. Partners with active contracts could initiate direct communication.

This was not about restricting access arbitrarily. It reflected the actual commercial relationship. A client who has not yet entered a contract with Cortechsols should not have direct access to talent. A partner who has a formal relationship should. The tiered permission model protected the business model without making the product feel locked down.

"Same profile. Different relationship. Different access. The platform reflects commercial reality."

The product had two types of buyers: clients who hired talent and partners who were affiliates or agencies with a commercial relationship with Cortechsols. These looked similar from the outside but had meaningfully different access rights.

I designed the permission system so that several features were visible to all authenticated users but functionally inactive unless the user had partner status. The most significant example was the message initiation button on talent profiles. Clients could view any talent profile and see the message button but it was disabled with a clear explanation. Partners with active contracts could initiate direct communication.

This was not about restricting access arbitrarily. It reflected the actual commercial relationship. A client who has not yet entered a contract with Cortechsols should not have direct access to talent. A partner who has a formal relationship should. The tiered permission model protected the business model without making the product feel locked down.

Decision 03 — Most Distinctive

Propose a chat oversight model that protects privacy instead of adding an admin to every conversation

The product owner wanted an admin in every chat. I pushed back and proposed system-level monitoring instead. They agreed.

The product owner wanted every client-talent conversation to automatically include a Cortechsols admin as a third participant. The stated reason was privacy protection and ensuring both parties stayed within the platform relationship.

I pushed back because permanently placing an administrator inside every client-talent conversation would change the perceived privacy of the interaction and could encourage users to move sensitive conversations off-platform. The oversight requirement was valid, but I believed it should be handled through platform controls rather than permanent third-party participation in every thread.

I proposed an alternative a conversation management system on the admin side where administrators could review flagged conversations search message history across the platform and take action on specific violations without being a permanent participant in any chat. I also proposed a visible moderation policy that users could see before initiating any conversation so they understood the oversight model without feeling surveilled.

The product owner agreed after the discussion. The client-talent conversation experience stayed private. The oversight capability stayed intact. Trust is not a feature. It is the foundation the entire marketplace sits on.

The product owner wanted every client-talent conversation to automatically include a Cortechsols admin as a third participant. The stated reason was privacy protection and ensuring both parties stayed within the platform relationship.

I pushed back because permanently placing an administrator inside every client-talent conversation would change the perceived privacy of the interaction and could encourage users to move sensitive conversations off-platform. The oversight requirement was valid, but I believed it should be handled through platform controls rather than permanent third-party participation in every thread.

I proposed an alternative a conversation management system on the admin side where administrators could review flagged conversations search message history across the platform and take action on specific violations without being a permanent participant in any chat. I also proposed a visible moderation policy that users could see before initiating any conversation so they understood the oversight model without feeling surveilled.

The product owner agreed after the discussion. The client-talent conversation experience stayed private. The oversight capability stayed intact. Trust is not a feature. It is the foundation the entire marketplace sits on.

"Users have a direct one-to-one conversation without an administrator participating in the thread. Platform moderation remains available through disclosed audit/flagging tools."

The product owner wanted every client-talent conversation to automatically include a Cortechsols admin as a third participant. The stated reason was privacy protection and ensuring both parties stayed within the platform relationship.

I pushed back because permanently placing an administrator inside every client-talent conversation would change the perceived privacy of the interaction and could encourage users to move sensitive conversations off-platform. The oversight requirement was valid, but I believed it should be handled through platform controls rather than permanent third-party participation in every thread.

I proposed an alternative a conversation management system on the admin side where administrators could review flagged conversations search message history across the platform and take action on specific violations without being a permanent participant in any chat. I also proposed a visible moderation policy that users could see before initiating any conversation so they understood the oversight model without feeling surveilled.

The product owner agreed after the discussion. The client-talent conversation experience stayed private. The oversight capability stayed intact. Trust is not a feature. It is the foundation the entire marketplace sits on.

Decision 04

Design the contract module as a semi-automated transparent record system

Full automation was not possible and was not honest. The managed service model required human judgement. I designed the platform to make that process transparent rather than hide it.

The contract module was the most complex design challenge in the entire product. The client operated in a real world context where contracts involved legal review budget negotiation and multiple document types NDAs scope documents talent CVs. Full automation was the wrong answer.

I designed the contract module as a transparent record system. When a client submitted a talent request the admin team received it conducted their manual process of requirement clarification and talent matching and then uploaded the resulting contract and associated documents into the platform. The platform displayed the full contract record to both client and talent status payment amounts subscription details validity dates assigned developers financial summaries payment history and all attached documents.

I added an audit request feature a button within the contract view that allowed the client to generate a formal audit request which the admin team received as a structured task. The activity log tracked every change document uploads plan changes status updates creating an accountable history that protected both the client and Cortechsols.

The contract module was the most complex design challenge in the entire product. The client operated in a real world context where contracts involved legal review budget negotiation and multiple document types NDAs scope documents talent CVs. Full automation was the wrong answer.

I designed the contract module as a transparent record system. When a client submitted a talent request the admin team received it conducted their manual process of requirement clarification and talent matching and then uploaded the resulting contract and associated documents into the platform. The platform displayed the full contract record to both client and talent status payment amounts subscription details validity dates assigned developers financial summaries payment history and all attached documents.

I added an audit request feature a button within the contract view that allowed the client to generate a formal audit request which the admin team received as a structured task. The activity log tracked every change document uploads plan changes status updates creating an accountable history that protected both the client and Cortechsols.

"Honest about how the business works. Transparent about every step of the contract lifecycle."

The contract module was the most complex design challenge in the entire product. The client operated in a real world context where contracts involved legal review budget negotiation and multiple document types NDAs scope documents talent CVs. Full automation was the wrong answer.

I designed the contract module as a transparent record system. When a client submitted a talent request the admin team received it conducted their manual process of requirement clarification and talent matching and then uploaded the resulting contract and associated documents into the platform. The platform displayed the full contract record to both client and talent status payment amounts subscription details validity dates assigned developers financial summaries payment history and all attached documents.

I added an audit request feature a button within the contract view that allowed the client to generate a formal audit request which the admin team received as a structured task. The activity log tracked every change document uploads plan changes status updates creating an accountable history that protected both the client and Cortechsols.

Decision 05

Give talent a profile insights module built on client evaluation data

Most managed talent platforms waste client evaluation data by keeping it in an admin system. I surfaced it back to the talent who earned it.

The talent portal needed to give developers something beyond profile management. The evaluation data that clients submitted at contract end was a genuinely valuable signal that most platforms never show to the talent themselves.

I designed the profile insights module to surface that evaluation data back to the talent in graphical form. Developers could see how clients had rated them across dimensions, how those ratings trended over time, and how their profile was performing in terms of client views and search appearances.

Most managed talent platforms treat talent as a supply to be managed rather than professionals to be developed. The insights module repositioned Cortech Talent as a platform that invested in talent growth a meaningful differentiator when competing for good developers who have other options.

The talent portal needed to give developers something beyond profile management. The evaluation data that clients submitted at contract end was a genuinely valuable signal that most platforms never show to the talent themselves.

I designed the profile insights module to surface that evaluation data back to the talent in graphical form. Developers could see how clients had rated them across dimensions, how those ratings trended over time, and how their profile was performing in terms of client views and search appearances.

Most managed talent platforms treat talent as a supply to be managed rather than professionals to be developed. The insights module repositioned Cortech Talent as a platform that invested in talent growth a meaningful differentiator when competing for good developers who have other options.

"Client evaluations go back to the talent who earned them. Not just to the admin who filed them."

The talent portal needed to give developers something beyond profile management. The evaluation data that clients submitted at contract end was a genuinely valuable signal that most platforms never show to the talent themselves.

I designed the profile insights module to surface that evaluation data back to the talent in graphical form. Developers could see how clients had rated them across dimensions, how those ratings trended over time, and how their profile was performing in terms of client views and search appearances.

Most managed talent platforms treat talent as a supply to be managed rather than professionals to be developed. The insights module repositioned Cortech Talent as a platform that invested in talent growth a meaningful differentiator when competing for good developers who have other options.

The Design Principles I Applied

Every principle backed by a specific decision

Architecture before interface

→ Applied in Decision 01

The onboarding system defines what the platform can do downstream. Getting it right first made everything else possible.

Trust is structural, not cosmetic

→ Applied in Decision 03

The chat oversight decision preserved direct client-talent communication while keeping moderation and accountability available at the platform level.

Honest about constraints

→ Applied in Decision 04

Trying to automate a process that required human judgement would have broken every time reality did not match the rules. Transparency about the real model is better design than fake automation.

Both sides of the marketplace matter equally

→ Applied in Decision 05

The profile insights module returned client evaluation data to talent instead of treating it only as administrative information, giving developers visibility into their own performance.

Architecture before interface

→ Applied in Decision 01

The onboarding system defines what the platform can do downstream. Getting it right first made everything else possible.

Trust is structural, not cosmetic

→ Applied in Decision 03

The chat oversight decision preserved direct client-talent communication while keeping moderation and accountability available at the platform level.

Honest about constraints

→ Applied in Decision 04

Trying to automate a process that required human judgement would have broken every time reality did not match the rules. Transparency about the real model is better design than fake automation.

Both sides of the marketplace matter equally

→ Applied in Decision 05

The profile insights module returned client evaluation data to talent instead of treating it only as administrative information, giving developers visibility into their own performance.

Outcome

A website became a marketplace

Cortech Talent moved from a marketing website that described a staffing service to a launched two-sided marketplace, with client and talent portals, four role types, structured onboarding, permission-based access, contract lifecycle management, platform-level moderation, and talent insights.

Complete portal systems designed end to end: Client Portal and Talent Portal.

Distinct role types with separate access architectures: client, talent, partner, and admin.

Significant product decision reversed through reasoned pushback: the chat oversight model.

Complete portal systems designed end to end: Client Portal and Talent Portal.

Distinct role types with separate access architectures: client, talent, partner, and admin.

Significant product decision reversed through reasoned pushback: the chat oversight model.

Cortech Talent was developed and launched during my time at Cortechsols. At the CISO Middle East Summit in Doha, it was demonstrated to the same enterprise clients who had previously seen Easy Agent V1. Their response was different: Cortech Talent was described as the product that worked, and the feedback highlighted that the UI was “very clean and polished,” the flows were “very clear,” and that “the design itself educates new users.”

That feedback mattered because one of the central design goals was making a managed staffing model understandable through the product itself rather than requiring someone from the company to explain how every part worked.

“Cortech Talent's design was appreciated at the Doha meeting. The clients found it easy to use and problem-solving.”

— CEO, Cortechsols

Cortech Talent moved from a marketing website that described a staffing service to a launched two-sided marketplace, with client and talent portals, four role types, structured onboarding, permission-based access, contract lifecycle management, platform-level moderation, and talent insights.

That feedback mattered because one of the central design goals was making a managed staffing model understandable through the product itself rather than requiring someone from the company to explain how every part worked.

Reflection

What I would do differently

The hiring requirements step is the most structurally important screen and also the most cognitively demanding for first-time clients. I would run structured usability testing on that specific flow before launch, not after. Watching a real client try to explain their hiring needs in the quota system would tell us whether the guidance built in is enough or whether more scaffolding is needed. The Doha contrast between Easy Agent V1 and Cortech Talent suggests the platform works when the onboarding is clear. The hiring requirements step is where clarity matters most.

Cortech Talent reinforced that the most consequential marketplace decisions are often rules rather than screens: who can see what, who can communicate with whom, what gets automated, and where human judgement stays in the loop. The chat oversight decision is the one I value most because it required challenging the proposed solution while still solving the underlying business need.

The hiring requirements step is the most structurally important screen and also the most cognitively demanding for first-time clients. I would run structured usability testing on that specific flow before launch, not after. Watching a real client try to explain their hiring needs in the quota system would tell us whether the guidance built in is enough or whether more scaffolding is needed. The Doha contrast between Easy Agent V1 and Cortech Talent suggests the platform works when the onboarding is clear. The hiring requirements step is where clarity matters most.