IndustryMarketplace · On-Demand ServicesServicesMobile App · Web · SaaS

A freelancing marketplace that works when the job isn't remote.

Snapmar matches US customers with talent across three formats — gigs a professional lists, jobs a business posts, and requests a customer opens — with in-app wallets, realtime chat and location-aware work on one backend.

Start Your Project

Core Offering

Freelance Marketplace

Platforms

iOS + Android · Web

Market

United States

Engagement

2024

Project Results

Roles on one backend

Customer · Talent · Admin

Structural fact — roles built

Work formats, one lifecycle

Gigs · posted jobs · open requests

Structural fact — formats shipped

Payment rails, one wallet

Stripe + Intercash on the same ledger

Structural fact — integrations wired

Platforms, one codebase

iOS + Android from Flutter

Structural fact — platforms built

Registered talent, jobs posted and transaction volume are the client's numbers to share, and they are not on this page. What is on this page is what was built, and why it was built that way.

Snapmar freelancing marketplace — talent search, gig detail, offer checkout, chat and job management screens

The Context

Building a freelance marketplace app for work that doesn't happen over a webcam.

Snapmar is a US freelancing marketplace built on three formats rather than one: gigs a professional lists, jobs a business posts, and requests a customer opens for someone to answer. Customers and talent each get their own way in — mobile apps and web panels — with an admin dashboard running moderation, analytics and dispute handling across the whole thing.

The distinction that shaped the build is that Snapmar covers onsite work as well as remote. Upwork and Fiverr assume the work travels over the internet. A marketplace that also has to get a person to a physical address needs geolocation, live tracking and a trust model that survives two strangers meeting in the real world — a different product wearing similar clothing.

Snapmar web dashboard — job budgets, order status and gig order breakdowns

The Challenge

A marketplace has to be right for two people who want opposite things.

Every marketplace is really two products that have to agree. The customer wants the job done well and the money held until it is; the talent wants the work to be real and the payout to arrive. Both are looking at the same job, the same money and the same counterparty, from opposite sides — and a single record has to satisfy both readings of it.

Onsite work raises the stakes on all of it. When the deliverable is a file, a dispute is about quality. When someone has driven across a city to clean an office, a dispute is about whether a person showed up — which the platform has to be able to answer from its own records rather than from two conflicting accounts.

And none of it is one app. A marketplace ships as a set of products — the customer's, the talent's, the operator's — that must never disagree about the state of a job. Every one of them is a different reading of the same data, and the moment one of them is wrong, trust in the platform goes rather than trust in the feature.

Our Approach

One backend, one set of records, several ways in.

Every product Snapmar ships is a view onto the same data. That is the decision the rest of the build follows from: no product owns a copy of the truth, so no two products can disagree about a job, a balance or a message.

Three work formats, one job record.

Gigs, posted jobs and open requests are different entry points into the same lifecycle — offer, acceptance, delivery, payment. Modelling them as one record with three doors is what keeps the customer app, the talent app and the admin dashboard describing the same state.

A wallet, not a payment button.

Money moves in more than one direction in a marketplace: customers pay in, funds are held, talent is paid out, and commission comes off in between. That needs balances, transaction history and payouts as a system of record — which is why the wallet was scoped as its own workstream rather than as a checkout screen.

Two payment rails on one ledger.

Stripe and Intercash both sit behind the same wallet, so a balance means the same thing whichever rail moved the money. The provider is an implementation detail of a transaction, not a fork in the product.

Realtime where it changes a decision.

Socket.io carries chat and job alerts while the app is open, with push and email as the fallback path when it isn't. An event fires once on the server and reaches every product that needs it, rather than each client polling for its own copy.

Location as a first-class part of a job.

Onsite work needs geolocation, maps and navigation to an address, not a video-call link — so location sits on the job record itself and every product that touches that job can read it.

Moderation and roles before launch, not after the first incident.

Role-based access across customer, talent and admin, content moderation across listings and messages, and an admin dashboard the client's own team runs — reviewing, resolving disputes and acting without calling us.

What This Means in Practice

What this means in practice.

Gigs, posted jobs and open requests are one lifecycle with three entry points, so a new work format is a door onto existing machinery rather than a second system.

Every product reads the same job record, so the customer app, the talent app and the admin dashboard cannot disagree about the state of a job.

The wallet is a ledger rather than a checkout screen — balances, history and payouts exist as records, which is what makes disputes answerable.

Two payment rails sit behind one balance, so adding or changing a provider does not change what the product means by money.

Realtime runs on server-side events over Socket.io, so an update fires once and reaches every product that needs it instead of each client polling.

Location lives on the job, which is what lets the same marketplace carry onsite work and remote work without forking into two products.

Role-based access across customer, talent and admin was built with the platform, so moderation and dispute handling existed before the first incident rather than after it.

The client's own team runs moderation, disputes and analytics from the admin dashboard without developer involvement.

Building a marketplace where both sides have to trust the same record?

Get a Free Project Estimate

Built for Every Platform

Three roles. One marketplace underneath.

A marketplace is not one product — it is a set of products that have to agree with each other about the same job, the same money and the same two people. The app is where the market meets; the panel is where it is kept honest. Customer and talent web panels ship alongside both, in the same Angular codebase, and everything runs on a single Node.js backend.

iOS + Android · Flutter

Snapmar Mobile App

Three ways to start work — browse listed gigs, post a job, or open a request for someone to answer
Skill-based matching and recommendations on both sides of the market
Bidding and offers, with acceptance moving a job into a tracked lifecycle
In-app wallet with balances, transaction history and payouts
Stripe and Intercash behind the same wallet
Realtime chat and job alerts over Socket.io, with push and email fallback
Geolocation, maps and live tracking for onsite work
Talent profiles with portfolio and verification
Social logins, deep links and an in-app helpdesk

Mobile App Development

Snapmar mobile app — talent search, gig detail, offer checkout, chat and job management screens

Web · Angular

Snapmar Admin Panel

Moderation across listed gigs, posted jobs and open requests
Content moderation across listings and messages
User, role and permission management for customer and talent accounts
Dispute handling with the full transaction record behind it
Transaction and payout oversight across both payment rails
Analytics and reporting on jobs, orders and budgets
Subscription management
Run by the client's own team, without developer involvement

Web Development SaaS Development

Tech Stack

Every tool below is in the build — no résumé-ware.

Why This Is a Partnership

In their own words.

Tedhy Louis
CEO & Founder at Snapmar LLC

FAQ

Freelance Marketplace Development — Questions Founders Ask Us

Have a similar project? Talk to us

More than a single app, because a marketplace is never one product. Snapmar shipped as a customer app, a talent app, web panels and an admin dashboard on one backend — each with its own permissions, its own screens and its own edge cases. We scope marketplaces in phases and quote each phase fixed-price after a free scoping call, so you can launch one side of the market before committing to the whole thing.

Because money in a marketplace moves in more than one direction. Customers pay in, funds are held, talent gets paid out, and platform commission comes off in between — and the provider that handles card acceptance well is often not the one that handles payouts well, or the one that covers every user your market includes. Snapmar runs Stripe alongside Intercash behind a single wallet, so the balance means the same thing whichever rail moved the money.

You decide which side you're seeding and build for that side first. A marketplace with talent and no jobs fails identically to one with jobs and no talent, and the product decisions that follow — what the empty state says, who gets notified when a listing appears, which side you let browse without an account — are all downstream of that choice. It's a scoping conversation before it's a build one.

Yes. Snapmar includes an in-app wallet with balances, transaction history and payouts across two payment providers. Wallets are the part founders assume is a feature and then discover is a system — ledgers that reconcile, transactions that can't double-spend, refunds and disputes, and clear records for every party. We scope it as its own workstream with its own acceptance criteria.

Socket connections for live delivery while the app is open, push notifications for everything else, and server-side triggers so an event fires once and reaches every product that needs it. Snapmar runs Socket.io for in-session chat and job alerts, with push and email as the fallback path when the app is closed.

Yes, and it needs to exist before launch rather than after the first incident. Snapmar ships with content moderation across listings and messages, role-based access control across customer, talent and admin, and an admin dashboard where the client's own team reviews, resolves disputes and acts without calling us.

It can, but location has to be part of the job rather than a field bolted onto a profile. Snapmar carries geolocation, maps and live tracking on the job record itself, so the same platform handles a logo design and an office cleaning without forking into two products. The harder part is trust: when the deliverable is someone turning up at an address, the platform needs its own records of what happened rather than two conflicting accounts.

Building a two-sided marketplace?

We've already built the wallet, the realtime layer, the moderation tooling and the multi-role architecture underneath one.
See exactly how we'd scope yours.

Book a Free Consultation

More Platforms We've Shipped