Contact details are a product, not an afterthought
Most marketplace themes treat visibility as one switch: a page is public or it is not. Freeio's vendor description splits the freelancer profile into two independent decisions — who can view the freelancer page, and who can view the freelancer's contact information — and gives each its own menu of audiences. The second list is where the theme takes a position. One of its options is described as allowing all users to view a freelancer while only employers who purchased a Contact Package can see the contact info.
That is a monetisation model written into the permission layer. If your business plan involves charging employers for access to freelancers rather than for posting jobs, this is the feature that justifies the theme. If you intend to run an open directory where anyone can approach anyone, the same control is simply something you leave wide open.
The restriction matrix: three objects, separate switches
The vendor's feature list groups the visibility settings under three headings — Restrict Job, Restrict Freelancer and Restrict Employer — and the options are not identical across them, which is the detail worth reading carefully.
Job pages can be set to All (Users, Guests), All Register Users, Register Freelancers, or Always Hidden. That last option means a job listing can exist without being reachable from the front end at all, which suits invite-only or client-specific postings.
Freelancer pages add a package-based option on top of the usual public and registered-user audiences: registered employers who bought a CV Package can view freelancers. Contact info carries the Contact Package gate described above.
Employer profiles are governed too, with their own option to restrict viewing to freelancers who are applicants — the employer becomes visible to a freelancer through the working relationship rather than by default. The vendor's wording for the applicant-only options reads slightly awkwardly, describing freelancers as viewing "their own applicants employers," so treat the exact behaviour as something to confirm in your own setup rather than assume from the label. Every one of these settings is off-by-default territory: you decide the combination, and a marketplace launch usually needs all three groups configured before users arrive.
Where the money sits between proposal and payout
Freeio's description of the transaction flow is the most specific part of the listing. A task is posted, freelancers submit proposals, the employer accepts one and pays. The admin receives the payment, but the vendor states the amount is shown in the freelancer's wallet under pending payments after the admin's commission is deducted. When the employer approves the completed project, that amount moves from pending balance to available balance.
Read plainly, that is a staged release model: the freelancer sees the money early but cannot draw it until the work is signed off. It shapes how you write your marketplace terms, because the theme's own accounting assumes the employer holds the approval trigger.
The changelog shows the money layer kept expanding rather than staying a single flat commission. Version 1.0.3 added a disputes system and commission tiers. Version 1.2.4 in November 2023 added a Service Package, alongside changes to payout time and the proposals form. Contact, CV and Service packages therefore describe three different paid-access or paid-selling paths, not one product type.
The vendor description does not say how a dispute affects a pending balance, and it does not name a payment gateway. Both questions belong to your own testing.
Four things people create from the front end
The listing names front-end creation for projects, services and jobs, and a resume layer for freelancers. Projects are the proposal-based path: the employer posts, freelancers bid. Services are a separate selling path, closer to fixed-scope gigs, and the Service Package addition suggests the vendor treats them as a purchasable unit in their own right. Jobs sit alongside as conventional postings.
A Fields Manager is listed among the features, which matters for a niche marketplace: the fields you add to projects and services are what make your listings specific to a trade, and the changes them without touching theme files, at least by the vendor's account.
Service video arrived in version 1.3.4, a small addition that shifts services toward visual demonstrations. Older changelog entries also record service tags, freelancer socials and a service history — incremental evidence that the service object received more attention over the release timeline than the job object.
Search is assembled from shortcodes, per content type
Freeio does not present one global search block. The vendor lists Listing List, Listing Search, Listing Advanced Search and Listing Simple Search shortcodes, plus Resume List and Resume Advanced Search. The split between simple and advanced variants for the same content type is the practical part: a hero search with one keyword field and a category dropdown serves a homepage, while an advanced form with filters belongs on the results page.
Sorting is described as available across job listings, services, projects and resumes, and the vendor claims multiple ways of showcasing each. Where you place those shortcodes determines how much of the marketplace is reachable, which ties back to the visibility settings — a job set to hidden will not surface in a listing shortcode in any useful way.
Three map providers are declared: Google Maps, Here maps and Mapbox. That choice usually comes down to the API terms and cost that fit your region, not to the theme itself.
Page building and the declared compatibility list
Elementor and Elementor Pro appear in the compatibility attributes observed on 4 November 2026, and the changelog records Elementor builder element updates in 1.3.0 and an Elementor update in 1.3.12. Gutenberg Optimized is marked Yes in the same attributes. Both statements describe declarations attached to the listing, not a record of editing the theme in either builder.
The vendor advertises one-click demo import, boxed and grid-size layout options, and typography controls. Version 1.2.0 added ten more home pages and two extra detail-page variants each for freelancers, projects and services, so the choice of layout is genuinely broad.
The same attribute snapshot lists WooCommerce 5.x through 10.x and the changelog's most frequent single line is "Updated WooCommerce," which tells you the theme is maintained in step with that plugin. Note what the attributes do not settle: whether the marketplace's own transactions run through WooCommerce, or whether WooCommerce is present for other products. The vendor's wallet description refers to admin-received payments and commission, not to a checkout flow, so test the payment path you intend to use. WPML is listed for multilingual sites, and translation-ready is claimed in the feature list.
Files are listed as PHP, HTML, CSS and Sass. The declared WordPress range runs from 6.2.x to 7.0.x in that observation. None of this is a substitute for running the theme against your PHP version and plugin set.
The decision behind the settings
Freeio asks you to answer two questions before you build anything: should a freelancer's contact details be free or paid, and should earnings wait for employer approval? The theme supports both answers, but the second one makes an explicit assumption about who adjudicates finished work, and the disputes system added in 1.0.3 carries that assumption further than a simple release button would. If your marketplace releases funds on a timer, or lets freelancers approve their own deliverables, you are configuring against the grain rather than with it.
Questions & answers
Can I make freelancer contact details visible only to paying employers?
Yes, according to the vendor's feature list. The contact-info setting includes an option where all users can view a freelancer profile but only employers who purchased a Contact Package can see the contact details. It is a separate setting from who can view the freelancer page itself.
When does a freelancer actually receive payment?
The vendor describes an accepted proposal's payment as landing in the freelancer's wallet as pending balance, after admin commission is deducted, and moving to available balance only once the employer approves the completed project.
Do project and service listings use the same flow?
Not exactly. Projects follow a proposal-and-bid path, while services are a separate front-end posting type, and the changelog records a Service Package addition in version 1.2.4 alongside service tags, a service video and service history. Treat them as two selling paths rather than one.
