ROLE
Frontend Product Engineer
Designed and implemented the two-sided workflow for matching, real-time conversation, agreement revisions and bilateral confirmation. Also implemented the supporting API, persistence and real-time delivery.
Freelance Marketplace
A freelance marketplace prototype with AI-assisted onboarding, swipe-based matching and versioned agreements
DELIVERY
From onboarding to agreement approval
Built onboarding, ranked matching, real-time chat and versioned agreements.
STATUS & PROOF
- Hackathon prototype
- Winner of two tracks:
TEAM
2-person project team
My teammate led product strategy, business positioning and GTM.
SELECTED TECHNOLOGY
Next.js · TypeScript · Express · PostgreSQL · Socket.IO · Gemini · ElevenLabs
How Lancerium Works
TRADITIONAL MARKETPLACES:
1 MANUAL ONBOARDING
Freelancers often have to recreate professional information that already exists in their CV or profiles on other platforms before they can start finding relevant work.
2 BROAD DISCOVERY
Broad filters and long result lists leave clients and freelancers manually evaluating which opportunities or candidates are actually a good fit.
3 PLATFORM-DEPENDENT TRUST
High fees, payout holds, locked-in reputation and manual dispute handling keep both money and trust controlled by the marketplace.
LANCERIUM:
1 AI-ASSISTED PROFILE ONBOARDING
Manual entry, AI-assisted CV import and an AI-guided voice interview all produce one editable freelancer profile.
2 TINDER-STYLE MATCHING
Deterministic ranking uses skills, budget and work history; LLM adds contextual fit before both sides review them through a swipe-based discovery flow.
3 ON-CHAIN WORK AGREEMENTS
Confirmed terms were designed to move into milestone-based USDC escrow, with transparent release and arbitration rules.
AI-Assisted Profile Onboarding
USER PROBLEM
Before searching for projects, users often have to re-enter information already available in their CV or profiles on other platforms.
PRODUCT DECISION
Offer three ways to build the same structured profile: manual entry, CV import, or an AI-guided voice interview.
TECHNICAL MECHANISM
CVs and interview answers are processed by AI into the same profile schema. Both AI-assisted paths then open the standard editor, where every field can be reviewed and corrected.
RESULT
Freelancers reach a usable profile with less manual setup while keeping control over the final information.
Three onboarding paths
Tinder-Style Matching
Swipe through ranked matches, then apply to the one you like
USER PROBLEM
Both freelancers and clients have to manually filter through many weak matches before finding opportunities or candidates worth pursuing.
PRODUCT DECISION
Replace long lists with a ranked swipe flow: rank matches first, then let users evaluate them one at a time.
TECHNICAL MECHANISM
A deterministic score first ranks matches using structured signals such as skills, budget and project fit. The LLM then reviews the top five using free-text context from project descriptions and profiles, capturing signals the structured score may miss before reranking them for the swipe flow.
RESULT
Both sides see the highest-ranked matches first and can accept or skip each option before moving into the application or conversation flow.
One Shared Deal State
USER PROBLEM
Messages and deal updates can become inconsistent between two participants if real-time events are missed, delayed or delivered more than once.
PRODUCT DECISION
Use one persisted deal record as the source of truth for both participants.
TECHNICAL MECHANISM
Save each update and assign it a server ID before broadcasting the saved record through Socket.IO. Both clients ignore repeated events with the same ID.
RESULT
Client and freelancer can refer to the same conversation history when agreeing on the scope and terms of the work.
Real-time messages stay synchronized for both sides
Revision-Bound Approval
Client and freelancer confirm the agreement before it locks
USER PROBLEM
If either party changes approved terms, the earlier confirmation must not count as acceptance of the updated agreement.
PRODUCT DECISION
Treat every agreement edit as a new revision and require both parties to approve that revision again.
TECHNICAL MECHANISM
Each edit creates a new revision and clears existing confirmations. The agreement can be finalized only when both parties have confirmed the current revision.
RESULT
If one party confirms and the other then edits the terms, both must confirm the new revision before the agreement can be finalized.
Outcome & Limitations
Launch video
RESULT
Proved the core marketplace workflow
Onboarding, ranked matching, real-time chat and versioned agreements worked end to end.
PROTOTYPE BOUNDARY
Settlement was not production-ready
On-chain settlement remained an experimental integration.