A Hyperlocal Marketplace and Barter Trading Platform

Delivered remotely for a business based in Adelaide, Australia. Names withheld by agreement.

Project Overview

Industry: Consumer classifieds and the local resale economy.

Type of solution: A consumer marketplace platform: a REST API with a documented interface and administrative back office, plus separate native Android and iOS applications.

Business context: Local resale runs on general-purpose classifieds and social marketplace features, and those tools make a narrow assumption — that a listing has a price and a buyer pays it. In practice a great deal of neighbourhood activity does not fit that shape. People trade one item for another. They give things away. They hold weekend sale events. They hire locally for small jobs. Each of these has an audience that overlaps almost entirely with the classifieds audience, yet each sits on a different platform, and the barter case has essentially no software support anywhere. The commercial constraint is equally specific: when money changes hands in person between two neighbours, the platform cannot take a share of it. Revenue has to come from listing visibility instead — which only works if the platform is dense enough locally that visibility is worth paying for.

General users: Buyers, sellers and traders — usually the same person in different sessions — plus sale event hosts, local employers, job applicants, and platform administrators.

General purpose: To make everything happening commercially within a few miles of the user discoverable in one application, and to give barter, giveaway and sale-event activity the same structured treatment that classifieds platforms reserve for priced sales.

The Business Challenge

Barter has no software model. A swap is not a price. It is an item — with its own photographs, its own description and its own perceived value — offered against another item. Existing platforms force this into a free-text conversation, which means it cannot be tracked, compared, accepted or declined as a structured action.

Distance is the relevance signal, and it is usually handled badly. In local resale, an item three miles away and an identical item three hundred miles away are not remotely comparable. Discovery has to be genuinely distance-driven, at a radius the user chooses, across every kind of content the platform carries.

Trust has to be earned somewhere. Two strangers agree to meet and exchange goods and cash in person. That handover is the actual risk in the product, and it happens entirely outside the software unless the software deliberately reaches into it.

Adjacent local activity is fragmented. Sale events, free giveaways and small local hiring all share the same neighbourhood audience as classifieds, and all live on separate platforms. Bringing them together is the density argument for the whole product.

The platform cannot touch the transaction. Payment between buyer and seller happens in person. That rules out commission entirely, so the business model has to rest on paid listing visibility — which brings its own requirements: entitlements that expire, renewal prompts before they do, and billing that satisfies both mobile app stores.

Two stores, two rulebooks. Paid placement had to be transacted through each platform's own billing system, with the resulting entitlements reconciled to one server-side model regardless of which store the purchase came through.

Everything happens on a phone, natively. Users photograph an item in a garage and list it there and then. The mobile applications are the product, and each needed first-class access to its platform's camera, maps, billing and sign-in.

Our Approach

Model the swap as an offer, not a message. We built a single offer entity that carries either a cash amount or an offered item — with its own images and description — against a listing, sharing one set of transitions: make, counter, accept, reject, retract. A trade is therefore just as trackable, comparable and actionable as a bid, and the negotiation history reads the same either way.

Make distance a query parameter, not a category. Proximity filtering was built directly into the listing, free-item, sale-event and job queries, combined with radius selection, postal-code entry, category, keyword and listing-type filters that all apply simultaneously.

Move negotiation into a conversation automatically. When an offer is accepted, the platform provisions a conversation between the two parties without anyone having to start one — so the moment a deal is agreed, the logistics conversation already exists.

Scope conversations to the listing. Threads are keyed to the item as well as the two participants, so two people negotiating two different things get two clean histories rather than one confused one.

Design for the handover. Inside the conversation, the platform suggests nearby public venues as a meeting point and shares the chosen one back into the thread as a map. Combined with peer ratings carried on every user's profile, this puts trust and safety in the two places where they actually matter — before you agree, and when you arrange to meet.

Build the verticals on shared foundations. Sale events and job listings reuse the same geolocation, imagery, taxonomy, expiry and notification machinery as marketplace listings, so four verticals did not cost four times one vertical.

Use code generation where the domain is uniform, and write by hand where it is not. A large administrative and API surface was scaffolded from table definitions — generating admin screens, endpoints, access permissions and API documentation together — while listings, offers, messaging, sale events and payments were built out by hand on top of it. This is what allowed a broad product to be delivered and maintained by a small team across three codebases.

Build both clients natively. Android and iOS were developed as separate native applications so that each store's billing, sign-in providers, mapping SDK and camera stack were integrated directly rather than through an abstraction layer.

The Solution

Three listing modes on one marketplace. A listing can be offered for a price, offered for trade, or given away free — with the same creation flow, the same imagery, the same discovery and the same offer mechanics behind each.

Structured swap offers. An offer to trade carries the offered item's own photographs and description. The recipient sees what is being offered, not a paragraph describing it, and can counter, accept or decline exactly as they would a cash bid.

Distance-driven discovery. Every browse surface is proximity-first, with user-selected radius, postal-code targeting, category filtering, keyword search, free-only and featured-only views, and saved favourites.

Featured placement. Sellers can promote a listing into featured positions in the feed for a limited period, purchased through their platform's app store and tracked as a server-side entitlement with its own expiry.

Listing-scoped messaging. Conversations are tied to the item under negotiation, with paginated history, image attachments, read receipts, unread counts and canned quick replies for the questions everyone asks.

Safe handover suggestions. Within a conversation, the platform proposes nearby public venues as a meeting place and shares the selection back into the thread as a map image.

Peer reputation. Ratings with comments are collected after a transaction, aggregated onto the user profile, and shown alongside their listings and offers.

Community sale events. Neighbourhood and estate sale events are created with imagery, location and multiple date and time slots, then discovered on an interactive map with marker callouts or as a proximity-sorted list.

Local jobs board. Employers post roles with requirements, compensation and location; applicants apply with an introduction and upload a résumé and cover letter; employers review applicants in-app. Job posts are paid placements with their own duration and expiry.

Lifecycle automation. A scheduled routine expires listings, featured placements and job posts on their dates, and sends reminder notifications before an expiry so nothing lapses silently.

Push notifications with deep navigation. Offers received and answered, accepted deals, rating prompts, application alerts and expiry warnings all arrive as push notifications that open the exact screen concerned, including from a cold start.

Shareable links that open the app. Listings, sale events and job posts each have a share link backed by verified universal links and app links, opening the application when it is installed and a server-rendered page when it is not.

Administrative platform. Full management of listings, offers, users, sale events, jobs, applications, taxonomies, pricing tiers, content pages, FAQs and settings, governed by fine-grained named permissions assigned through groups.

Key Features

A single offer model spanning cash and barter One offer entity, one status machine, two kinds of consideration — a price or an item. Swap offers carry their own imagery and description, making a trade as structured and reviewable as a bid.

Proximity-first discovery across every vertical Radius and postal-code filtering applied consistently to marketplace listings, free items, sale events and job posts, combined with category, keyword and listing-type filters in a single query.

Automatic conversation provisioning on acceptance Accepting an offer creates the thread between the two parties immediately, removing the gap between agreeing a deal and arranging it.

Listing-scoped conversations Threads are keyed to the item as well as the participants, so parallel negotiations between the same two people stay cleanly separated.

Safe handover venue suggestion A nearby public-venue picker inside the conversation, with the agreed location shared back into the thread as a map — trust and safety designed into the moment it matters.

Peer reputation carried across transactions Post-transaction ratings aggregated onto the user profile and surfaced wherever that user appears.

Community sale events on a map Multi-slot sale events with imagery and location, browsable as an interactive map with custom callouts or as a proximity-sorted list.

Local jobs board with in-app applications Job posts with requirements and compensation, applications with résumé and cover-letter upload, and an employer-side applicant review flow.

Store-compliant paid placement with automated expiry Promoted listings and paid job posts purchased through each platform's own billing system, reconciled to server-side entitlements with independent expiry clocks and pre-expiry reminder notifications.

Generated administration and API documentation Admin screens, endpoints, access permissions and API documentation generated together from table definitions, keeping a broad platform consistent and documented as it grew.

Technical Architecture

Mobile clients. Two independent native applications. The Android client is a Java application with a bottom-navigation shell hosting the marketplace, free items, sale events, jobs and posting flows, with mapping, location, camera, gallery and billing integrated through the platform's own SDKs. The iOS client is a Swift application organised as a slide-menu shell with a custom tab bar, structured as a view-presenter-service layering with typed decodable models per endpoint. Both consume the same REST contract and both handle push routing, universal-link routing and store billing natively.

API layer. A modular PHP REST API where every domain concept is a self-contained module carrying its own mobile API controller and model alongside its administrative controller, model and views. Authentication combines a per-user session token with a per-client API key header, and every endpoint is gated by a named permission assigned through group membership.

Administrative platform. A full back office over the same modules, covering catalogue and taxonomy management, listing and offer administration, user and permission management, content pages, and pricing tiers.

Code-generation layer. A metadata-driven builder generates admin screens, API controllers, models, validation, access permissions and API documentation from stored table definitions — the mechanism that allowed a broad multi-vertical platform to be delivered and kept consistent by a small team.

Geospatial layer. Distance is computed in the database against user-supplied coordinates and applied as a filter and sort across every proximity-aware content type.

Scheduled operations layer. A maintenance routine handles listing, featured-placement and job-post expiry, and dispatches reminder notifications ahead of each.

Media layer. Multi-image upload with server-side thumbnail generation and separate thumbnail delivery paths, partitioned by content type, with upload directories hardened against script execution.

Messaging and notification layer. Conversations and messages persisted through the API, with push notifications used as the delivery signal and carrying typed payloads that drive deep navigation in both clients.

Delivery pipeline. Continuous integration triggering scripted deployment to cloud infrastructure, with environment-specific configuration and secrets linked at deploy time rather than held in the application tree.

Flow: Native Android and iOS clients → Token-and-key-authenticated REST API → Modular domain services → Relational database with in-query proximity filtering → Scheduled expiry and reminder processing → Push notifications and verified deep links → Store billing reconciled to server-side entitlements

Technology Stack

Technical Challenges & Solutions

Security & Reliability

Layered API authentication. Requests carry both a per-user session token and a per-client API key, so client identity and user identity are established independently.

Fine-grained authorisation. Every endpoint and every administrative screen is gated by a named permission, assigned through group membership rather than hard-coded role checks — meaning administrative access can be scoped precisely without code changes.

Account protection. Email verification and password reset flows, with login attempt throttling on the authentication tier.

Hardened media handling. Uploads are partitioned by content type, restricted by file type, thumbnailed server-side, and served from directories configured to refuse script execution.

Verified deep linking. Universal links and app links are backed by published domain-verification files, so only the genuine applications can claim the platform's share links.

Trust and safety by design. Peer reputation is carried across transactions and surfaced at the point of decision, and the meeting-point suggestion steers handovers toward public venues.

Administrative oversight. Listings, offers, users, applications and content are all manageable from the back office, giving the platform a moderation path over user-generated content.

Web tier protections. Cross-site request forgery protection on the administrative interface, and environment-specific configuration supplied at deployment time rather than carried in the application.

Reliable delivery. Continuous integration driving scripted, repeatable deployments with a retained release history, so a bad release can be rolled back rather than repaired in place.

Scalability & Performance

Thumbnail-first media delivery. Every uploaded image is thumbnailed server-side and served from a separate path, so feeds — the highest-traffic surface in the product — never fetch full-resolution photographs.

Paginated and filtered everywhere. Listing, offer, message and notification endpoints are all paginated with server-side filtering, keeping result sets bounded regardless of how much content a user has accumulated.

Client-side image caching. Both native clients cache imagery locally, so scrolling back through a feed does not re-fetch what the device already holds — significant in a product where every listing carries multiple photographs.

Scheduled batch lifecycle processing. Expiry and reminder work runs on a schedule rather than being evaluated inside user requests, so commercial state maintenance never sits in a response path.

Stateless application tier. Token-based authentication and externalised media keep application instances free of local session state, so capacity can be added horizontally.

Push rather than poll. Time-sensitive events — an offer received, an offer accepted, a placement about to expire — are delivered by push notification rather than by clients polling for changes.

Native clients. Building both applications natively keeps list rendering, image decoding and map interaction on each platform's own optimised path, which matters in a feed-scrolling product.

Business Outcomes

• Barter became a structured transaction, with trades made, countered, accepted and declined through the same mechanics as cash offers rather than negotiated in free text.
• Discovery genuinely reflects proximity, with radius and postal-code filtering applied consistently across marketplace listings, free items, sale events and job posts.
• Negotiation and logistics happen in one continuous flow, because accepting an offer opens the conversation automatically and that conversation stays tied to the item concerned.
• The handover — the riskiest part of local resale — is supported rather than ignored, through peer reputation at the decision point and public-venue suggestions at the arrangement point.
• Four kinds of local activity live in one application, giving the platform a broader reason to be opened than a single-purpose classifieds app.
• Revenue works without touching the transaction, through paid placement transacted via each app store, reconciled server-side, and protected by automated expiry and renewal reminders.
• Nothing lapses silently, because scheduled processing warns users before a listing or placement expires rather than removing it without notice.
• A broad platform stayed maintainable, because the uniform majority of it was generated from definitions while engineering effort concentrated on the parts that were genuinely bespoke.

Why it worked

Consumer marketplaces are deceptively hard, and the difficulty is rarely technical. It is that the product has to be worth opening. A classifieds app competes with platforms that already have the audience, and it wins only by doing something those platforms structurally cannot — which means the differentiator has to be identified correctly and then modelled properly, not bolted on as a filter.

Our team builds for that. We took barter seriously enough to make it a first-class transaction rather than a checkbox, because an offered item with its own photographs is a fundamentally different object from a number and modelling it as a number would have made the feature useless. We treated the in-person handover as part of the product, because that is where the user's actual anxiety lives and where software can help. We made distance a property of every query rather than a category on a menu. And we scoped conversations to items rather than to people, because that small decision is the difference between a usable negotiation history and a confusing one.

We were also pragmatic about breadth. A four-vertical consumer platform maintained across three codebases by a small team is only viable if the uniform parts are generated and the engineering effort is spent where the domain is genuinely specific — and knowing which is which is a judgement call, not a framework choice.

Our teams work across PHP and modular API design, native Android and native iOS development, geospatial search, real-world messaging and notification design, app-store billing integration, and the trust-and-safety problems that any platform introducing strangers to each other eventually has to solve.

Final Summary

A great deal of neighbourhood commerce is invisible to the software built to serve it. Classifieds platforms understand a price and a buyer. They do not understand a trade, and they treat giveaways, weekend sale events and small local hiring as somebody else's category — even though it is the same audience, the same few miles, and often the same person.

Our team built a platform that takes all of it seriously. Listings can be sold, traded or given away, and a swap offer carries the offered item's own photographs and description so a trade can be made, countered, accepted or declined with exactly the mechanics of a cash bid. Discovery is proximity-first across marketplace listings, free items, community sale events and local job posts alike, with radius and postal-code filtering composing alongside category and keyword search. Accepting an offer opens the conversation automatically, and that conversation stays tied to the item it concerns.

Around that sit the things a platform introducing strangers to each other actually needs: peer reputation carried across transactions and shown at the point of decision, a public-venue suggestion inside the conversation so the handover is arranged somewhere sensible, push notifications that land users on the right screen for every negotiation and lifecycle event, and share links that open the app when it is installed. Revenue comes from paid listing placement transacted through each app store and reconciled to server-side entitlements, with automated expiry and reminders so nothing lapses without warning.

Delivered as two native mobile applications over a modular PHP API and administrative platform, with the uniform majority of a broad surface generated from definitions and engineering effort concentrated where the domain genuinely demanded it — the trade-off that let a small team ship and maintain four verticals at once.