ProFreelance — a global freelance marketplace on a shared core

01Project overview

ProFreelance is a global freelance marketplace where clients find specialists, post projects and short tasks, and freelancers submit proposals, run secure deals and build reputation through ratings and reviews. In product terms it is a full-fledged labour marketplace: a catalogue of freelancers, a feed of projects, proposals, messaging, secure settlements and a trust system, all assembled into one coherent service.

The defining characteristic of the project is that it is built on the same proven core as 24freelance, yet launched as a separate brand for a different audience and geography. This was a deliberate decision: instead of writing a second marketplace from scratch, we reused a battle-tested domain model — users, projects, proposals, deals, ratings — and grew a new brand layer on top of it, with a refreshed interface, a simpler onboarding flow and new ways of working.

Several things set ProFreelance apart from the base platform: a refreshed theme and redesign of the interface, social login for a fast start, balance top-up through the Payora crypto gateway, and a dedicated Tasks entity — short jobs that live alongside larger projects. Each of these decisions is not cosmetic but an answer to a concrete need: lower the barrier to entry, speed up settlements and widen the formats of work on the platform.

Below we break down why a second marketplace was needed, how the shared core is reused across the ecosystem's projects, which engineering and product decisions distinguish ProFreelance, and exactly what we designed and built — from architecture and onboarding to the interface and the payment integration.

02Context and the brief

The brief was pragmatic: the owner already runs a working freelance marketplace (24freelance) with proven mechanics for projects, proposals and secure deals. The goal was to launch a second marketplace under a different brand and a different geography — without rewriting everything, but also without turning it into a plain copy. The new product had to feel independent, look modern and have a lower barrier to entry.

Behind that brief sat a clear set of pains and constraints we worked with:

• Expensive ground-up development. A marketplace is not a landing page: catalogue, two-role profiles, proposals, deals, settlements, ratings, moderation, messaging. Writing all of that a second time just for a new brand makes no economic sense.
• High barrier to entry. Classic registration with email and confirmation loses part of the audience before the first action. For a new brand that is only building its base, every extra form means lost users.
• Slow, awkward settlements. Topping up a balance with banking methods in a cross-border scenario means fees, delays and rejections. A global audience needs a fast, predictable way to fund the platform.
• The narrowness of the project format. A large project with a detailed brief is not the only scenario. Often a short one-off task is needed, and forcing a full project for it is unnecessary friction.
• Brand and audience. The new product had to speak the language of its geography and look fresh, not like a clone of the existing site under a different logo.

The resulting framing: reuse the core, but not its face. Take the proven domain logic and services, wrap them in a new brand with a refreshed UI, simplify entry with social login, plug in fast crypto settlements and add a short-task format. Get a second marketplace faster and cheaper than building it alone — without any sense of it being secondary for the end user.

03Project goals

From the brief grew concrete product and engineering goals that we kept in focus at every stage:

• Launch a second brand on a shared core. Reuse the platform's domain model and services as much as possible, minimising code duplication across the ecosystem's projects.
• Lower the barrier to entry. Let people register and start using the platform in a couple of clicks — through social login, without long forms or mandatory email confirmation at the start.
• Speed up settlements. Connect balance top-up through the Payora crypto gateway so a global audience can fund the platform quickly and predictably.
• Widen the formats of work. Introduce a dedicated Tasks entity — short jobs alongside full projects, with their own lifecycle and simplified setup.
• Refresh the interface. Build a modern theme and redesign that set ProFreelance apart from the base platform and create the feeling of an independent product.
• Preserve deal safety and trust. Avoid losing — during the redesign and simplification — the very things a marketplace exists for: secure deals, ratings, reviews and predictable statuses.
• Lay shared services across projects. Use a single payment layer (Payora) and shared infrastructure so that every new ecosystem product connects to them without rewriting.

The key success criterion was simple: the new marketplace had to launch far cheaper and faster than ground-up development, while not looking or feeling like a secondary copy.

04What we did

ProFreelance draws its value from four large blocks that together set it apart from the base platform:

On top of these blocks sit a refreshed interface theme, redrawn key screens (catalogue, profile, feed, project and task cards), a simplified onboarding flow and the link to the ecosystem's shared services. All of it is deployed as a standalone product on its own domain, profreelance.biz, behind Cloudflare.

05Reusing the platform

The central engineering idea of the project is not to build a second marketplace from scratch, but to reuse a shared core. ProFreelance and 24freelance belong to the same engine family: they share a domain model and a set of proven mechanics. That means the hardest and most expensive part of a marketplace — the logic of projects, proposals, secure deals, ratings and statuses — is already written, battle-tested and does not require re-development.

What exactly is reused across the ecosystem's projects:

• The domain model. Users and roles (client/freelancer), projects, proposals, deals, ratings and reviews, messaging — a single framework proven on a live platform.
• Secure-deal mechanics. The logic that protects the money and obligations of both parties until the work is finished is carried over without rewriting.
• The payment layer. The shared Payora crypto gateway serves several projects at once: each connects as a separate merchant, but to the same service.
• Infrastructure patterns. The PHP stack, hosting behind Cloudflare, and the approaches to deployment and operations are inherited from the base platform.

And yet ProFreelance is not a clone. On top of the shared core lives a separate brand layer: its own theme, its own copy, its own audience and geography, plus brand-unique capabilities — social login and the Tasks entity. This gives the best of both worlds: the speed and reliability of a shared engine plus the independence of a standalone product.

The value of this approach grows with every new ecosystem project. Having invested once in a solid core and shared services, the owner can launch new marketplaces under different brands and markets, reusing a proven foundation and saving months of development on every launch. This turns a one-off product into a platform on which a family of services can be built.

06Solution architecture

Architecturally, ProFreelance is set up as a separate instance of the platform on top of the shared core, with its own brand, domain and set of add-ons. The base framework is inherited from the engine family, while the brand-unique functionality is gathered into add-ons that do not break the shared model.

Logically, the system splits into several layers:

• The domain core. Users and roles, projects, tasks, proposals, deals, ratings, messaging — the platform's shared model, reused from the proven base.
• The brand and UI layer. ProFreelance's refreshed theme, redrawn screens and copy — what makes the product independent visually and in tone.
• Onboarding. Social login on top of the shared user model: a social account is matched to a platform user record.
• The payment integration. The link to the external Payora crypto gateway for balance top-up: invoice creation, payment on the gateway side, and crediting on confirmation.
• The Tasks entity. A separate entity type alongside projects, with its own simplified lifecycle, feed and card.

Under the hood is a server stack on PHP, hosted behind Cloudflare (DNS, TLS, perimeter protection, static caching). This split into core and add-ons is fundamental: it lets the ProFreelance brand layer evolve independently without touching shared domain logic, and conversely, improvements in the shared core can reach several ecosystem projects at once.

07Social login

One of the main levers for lowering the barrier to entry is social login. Classic marketplace registration asks a person to fill in a form, invent a password, confirm an email — and all of that before they have seen any value. For a new brand that is only gathering an audience, every such step costs part of the users.

Social login changes the picture: a person presses one button, confirms access in a familiar service and lands inside the platform already authenticated. No passwords, no confirmation emails, no forms at the start. This is especially valuable for a global audience, where habits and trust toward different sign-in methods vary widely.

On the engineering side, social login fit neatly onto the platform's shared user model:

• Account matching. A social account is linked to a platform user record; signing in again through the same social network recognises the person and lets them into their profile.
• A single profile. Regardless of the sign-in method, the user lands in the same domain model — with a role, a profile, a rating and a history.
• Minimal friction. Missing profile data can be completed later, already inside the platform, instead of becoming a barrier at entry.

It matters that social login here is not a replacement for the domain logic but a convenient door into it. All the mechanics of roles, deals and ratings stay the same and proven; only the ease of getting in changes. This is exactly the case where a small product decision noticeably affects the conversion of the first visit.

08Balance top-up via Payora

Money on a marketplace has to arrive fast, predictably and without geographic barriers. For this, ProFreelance uses the Payora crypto gateway — the same payment service that powers other ecosystem projects. This is the tangible value of shared services: the payment layer is written and refined once, and several products use it at once.

The top-up flow for the user is simple: they specify an amount, the platform creates an invoice in Payora, the user pays it on the gateway side, and once the payment is confirmed the ProFreelance balance is topped up automatically. No manual checks, no "contact support and wait".

What this gives the product:

• Speed. Crypto settlements do not hit banking delays and cross-border limits — money arrives quickly.
• Predictability. The payment lifecycle is clear: invoice created, paid, confirmed, balance credited. Fewer disputes.
• Global reach. For an audience around the world, crypto top-up is often more convenient and accessible than local payment methods.
• Reuse. The platform contains no payment processing of its own — it connects to the shared gateway as a merchant, saving development and reducing risk.

09The Tasks entity: short jobs

Not every piece of work is a large project with a detailed brief. Often a client needs a short one-off task: fix some markup, translate a page, gather data, do a quick design. Forcing a full project for that is unnecessary friction for both client and freelancer. That is why ProFreelance gained a dedicated entity — Tasks.

Tasks live alongside projects but are set up more simply and quickly. It is a separate entity type with its own lifecycle, its own feed and its own card. A client posts a short task with a minimum of fields, freelancers see it in a separate stream and take it on without unfolding the heavy approval process of a large project.

What this format gives:

• Low friction. Posting a task is simpler and faster than setting up a project — the barrier for small work drops sharply.
• More turnover. Short jobs that previously did not "reach" a full project now stay on the platform instead of leaking into private arrangements.
• A clear stream for freelancers. Specialists who like quick jobs get a separate feed and do not drown in large projects.
• The same guarantees. Despite the simplified setup, tasks rely on the same trust mechanics — proposals, deals, ratings — as projects.

It matters that Tasks is not a separate subsystem in a vacuum but an add-on over the shared core. It reuses users, roles, proposal mechanics and trust, adding only its own lighter lifecycle. This, again, is the project's philosophy: extend capabilities without duplicating what already works.

10Profiles, proposals and secure deals

The heart of any labour marketplace is people and the trust between them. ProFreelance reuses the platform's proven mechanics: two-role profiles, proposals, secure deals, ratings, reviews and messaging. This is the foundation the platform exists for, and we carefully preserved it through the redesign.

How it works by role:

• Clients post projects and tasks, describe the job and budget, receive proposals, choose a freelancer and run the deal to a result.
• Freelancers fill in a profile, show experience and skills, submit proposals on projects and tasks, deliver the work and accumulate reputation through ratings and reviews.

The connecting mechanics that make the platform work:

• Proposals. A freelancer responds to a project or task; the client sees the candidates and chooses.
• Secure deals. The obligations and settlements of both parties are protected until the work is finished — this lowers risk for both client and freelancer.
• Ratings and reviews. Reputation accumulates from real deals and helps new users choose partners.
• Messaging. The parties communicate inside the platform rather than leaking into third-party messengers where arrangements get lost.

Crucially, this whole layer was not rewritten for the new brand but inherited from a proven core. The redesign touched how these mechanics look and feel, but not the trust logic itself — it is proven on a live platform and carried over without risk.

11Design and interface redesign

To make ProFreelance feel like an independent product rather than a clone under a different logo, we built a refreshed theme and a redesign of the key screens. The design task here is twofold: on one hand, to distinguish the brand from the base platform; on the other, not to break the familiar, proven flows that marketplace users already understand.

What the redesign touched:

• Catalogue and feeds. Lists of projects, tasks and freelancers were reimagined visually — cleaner, more modern, with a clear hierarchy.
• Profiles. Cards for freelancers and clients with an emphasis on reputation, experience and clear points of action.
• Project and task cards. The screens where the decision to respond is made were built so that the essence is visible at once.
• Onboarding. Sign-in and the first steps are built around social login and minimal friction.

The tone of the interface is calm and functional. A labour marketplace sells trust and convenience, so we avoided visual noise and bet on readability, clear navigation and predictability. The clearer it is to a person what is happening and what to do next, the higher the chance they will see the flow through — post a project, submit a proposal, finish a deal.

Separately, we made sure the redesign did not contradict the shared platform at the behaviour level. Under the new visual layer run the same proven mechanics, and a user familiar with similar platforms does not feel lost — they see a fresh wrapper around logic that behaves as expected.

12Shared ecosystem services

ProFreelance is valuable not only on its own but as part of an ecosystem of projects built on a shared foundation. This changes the economics of development: what is written once works for several products at once, and each new launch costs less than the previous one.

What is shared across the ecosystem's projects:

• The payment layer. The Payora crypto gateway serves balance top-up in ProFreelance and in other projects. Each product connects as a separate merchant, but to the same refined service.
• The domain core. The shared marketplace model (users, projects, proposals, deals, ratings) is reused across brands rather than rewritten for each.
• Infrastructure approaches. The PHP stack, hosting behind Cloudflare, and the patterns of deployment and operation are inherited and applied uniformly.

The practical benefit of this approach is direct: every new product starts not from zero but from a proven base. Payments already work — it is enough to set up the project as a merchant. The domain logic is already refined — it is enough to add the brand and unique features. The infrastructure is already understood — it is enough to deploy another instance.

13Technology stack and infrastructure

ProFreelance runs on the same technology family as the base platform — that is part of the reuse strategy. A single stack means shared competencies in maintenance and the ability to carry improvements between projects without retraining.

• Backend — PHP: the marketplace domain core, the logic of projects, tasks, proposals, deals and ratings, reused from the proven base.
• Onboarding — social login on top of the shared user model, matching a social account to a platform record.
• Payments — integration with the external Payora crypto gateway for balance top-up; the platform acts as a merchant of the shared service.
• Brand add-ons — a refreshed theme, a redesign of key screens and the Tasks entity as a separate entity type.
• Infrastructure — hosting behind Cloudflare (DNS, TLS, perimeter protection, static caching) on the own domain profreelance.biz.

The deliberate choice not to multiply unnecessary technologies pays off in operations: the team works with a clear stack, and shared services and patterns let several ecosystem projects be maintained as one whole rather than a set of disjointed systems.

14How we worked

We ran the project in sequential stages, each producing a tangible result rather than just discussions. Because reuse of the shared core was the foundation, the focus of effort shifted from writing base logic to brand, onboarding, payments and new formats.

• Research and framing. We mapped what is reused from the shared core and what is built anew for the brand; we fixed the audience, geography and the differences from the base platform.
• The brand layer. We designed the refreshed theme and the redesign of key screens so the product feels independent without breaking proven flows.
• Onboarding. We implemented social login on top of the shared user model and built the first steps around minimal friction.
• Payments. We connected balance top-up through the Payora crypto gateway as a shared ecosystem service, with crediting on payment confirmation.
• The Tasks entity. We added the short-task format alongside projects — with its own lifecycle, feed and card.
• Launch. We deployed the product on its own domain behind Cloudflare and assembled everything into a coherent, standalone marketplace.

This order let us bring the product to launch quickly: instead of months on re-writing the core, we invested effort where the difference is created — in brand, ease of entry, speed of money and new ways of working.

15The result

The outcome is not a clone of an existing platform but a standalone marketplace under a separate brand and audience, assembled on a proven core and the ecosystem's shared services. The speed and cost of launch turned out fundamentally lower than ground-up development, while the final product feels fresh and independent.

• The second marketplace launched faster and cheaper thanks to reuse of the shared core rather than re-development.
• The barrier to entry was lowered by social login: registration and the first step take a couple of clicks, with no long forms.
• Settlements were sped up by crypto top-up via Payora — a shared payment service serving several projects at once.
• The formats of work were widened by the Tasks entity: short jobs live alongside projects and keep small turnover on the platform.
• Secure deals, ratings and reviews were preserved — the foundation of trust was carried over without risk.

16Takeaways

ProFreelance is an example of how smart platform reuse turns an expensive, long launch into a manageable project. The most valuable thing here is not that we "made one more marketplace", but how: we took a refined core, wrapped it in a fresh brand, removed friction at entry with social login, sped up money through a shared crypto gateway and added a convenient short-task format — without rewriting what already works.

This approach scales. Having invested once in a solid core and shared services, the owner gets not a single site but a platform for a family of products: new brands and markets connect to a proven foundation and shared services, and each subsequent launch costs less than the previous one.

For us this was a project at the intersection of product strategy, architecture reuse and shared-service integration — exactly the kind of task where it matters not only to write the code but to set up the ecosystem so it works for the business for a long time. If you need a marketplace, a second product on a shared core, or an integration of payments and onboarding — we know how to bring such things to launch.