Build on Rails
Build the back office your Rails marketplace runs on
Buyers and sellers use the marketplace you build. Your team needs the other side: a queue of sellers waiting for approval, listings to moderate, disputes to settle, and payouts to check. With Avo, that back office runs inside your Rails app, on the sellers, listings, and orders already in your database.
250+ paying companies · 2.7M downloads of the avo gem
applied
pending review
The queue that decides how long a good seller waits, and the one that gets lost in a console.
approved
suspended
Each status is a scope your team opens by name, and each move between them is an action that asks for a reason and calls your own onboarding code.
starting from scratch
What building a marketplace back office from scratch actually costs
The storefront gets the design reviews. The marketplace survives on the screens behind it, and those are the ones a two-sided business keeps adding to long after launch.
-
01
Every seller needs a yes or a no
Applications pile up with documents, tax details, and a shop description someone has to read. Without a real queue, approvals happen in a console session or a spreadsheet, and the sellers who waited longest are the ones nobody remembers.
-
02
Moderation never runs out of listings
Counterfeits, prohibited items, stolen photos, prices with an extra zero. Trust and safety needs to find the bad listings fast, pull a batch of them at once, and leave a reason the seller can act on. A one-record-at-a-time edit form does not survive the first spam wave.
-
03
A dispute touches four records at once
The buyer, the seller, the order, and the payout all matter when something arrives broken. If support has to open three tools to see them side by side, every dispute takes an afternoon and the payout goes out before anyone decides.
-
04
Money screens need tighter rules
Support should see orders, finance should see payout accounts, and nobody outside finance should see a seller's bank details. Generate those rules screen by screen and one forgotten check is a leak of the data sellers trusted you with.
the Avo version
Your models are already the hard part. Build the rest on Avo.
A marketplace already has its hard part modeled: Seller, Listing, Order, Payout, Dispute. Describe a resource for each and Avo renders the queues, forms, and detail screens your team works from, on your real tables. Your storefront, checkout, and payment provider stay exactly as you built them; Avo is the back office your team runs them from. If you sell your own stock instead of hosting sellers, Avo for e-commerce covers that back office.
Moderate listings in batches, not one by one
Dynamic filters narrow listings by category, price, report count, or seller age without new code. Select every match and unpublish them in one confirmed action, with the reason saved on each listing.
Disputes with the whole story on one screen
A Dispute belongs to an order, and the order to a buyer and a seller, so the associations you wrote become linked panels. Add Collaboration and support keeps internal notes and every status change on the dispute itself instead of in a chat thread.
Payouts your team can read and hold
The payout records your payment integration writes show up with their status, amount, and seller. Filter to failed or held payouts, and run a Hold or Release action that calls your own payment code. Avo never moves money on its own; your integration does.
One permission layer for trust, support, and finance
With Authorization, Pundit policies decide which records each role loads and which fields it sees. Trust and safety moderates listings, support works disputes, and only finance sees payout accounts. The rule holds on every screen and every action.
The marketplace numbers, from your own database
Sellers waiting for review, listings reported this week, open disputes, and payout volume on dashboards built from your queries, so the operations meeting starts from the same data the marketplace runs on.
A Seller resource for the approval queue, the whole file:
class Avo::Resources::Seller < Avo::BaseResource
self.title = :shop_name
self.includes = [:owner]
self.search = {
query: -> { query.where("shop_name ILIKE :q OR email ILIKE :q", q: "%#{q}%") }
}
def fields
field :id, as: :id
field :shop_name, as: :text, required: true
field :email, as: :text
field :status, as: :badge, options: {
warning: :pending_review,
success: :approved,
danger: [:rejected, :suspended]
}
field :country, as: :country
field :submitted_at, as: :date_time, sortable: true
field :payout_account_id, as: :text, visible: -> { current_user.finance? }
field :owner, as: :belongs_to
field :listings, as: :has_many
field :orders, as: :has_many
field :payouts, as: :has_many
end
def actions
action Avo::Actions::ApproveSeller
action Avo::Actions::RejectSeller
action Avo::Actions::SuspendSeller
end
end
the timeline
From first resource to the team running on it
Install the gem and generate resources for Seller, Listing, and Order. Your team browses real shops and opens the listings and orders under each one.
Add the pending-review queue and the Approve and Reject actions. The oldest seller application stops waiting on whoever remembers to check the console.
Put it behind your existing login, write the policies for trust and safety, support, and finance, and ship it. Moderation and disputes move into production screens.
Payouts and disputes sit next to the orders they belong to, the moderation spreadsheet is retired, and the back office is a folder of resource files your agents extend as the marketplace grows.
Prefer to prompt?
Hand this to Claude Code, Cursor, or whatever agent you build with, and review what it ships like any other pull request.
Build a brand-new Ruby on Rails marketplace back office with Avo 4 (https://avohq.io, docs at https://docs.avohq.io/4.0/) as the operations UI. There is no app and no schema yet. The buyer and seller storefront is out of scope for this prompt: build the data model and the team-facing back office only.
1. Create the application with rails new using PostgreSQL. Add sign-in with Rails' built-in authentication generator (bin/rails generate authentication) so staff accounts are real users. Add the avo gem, bundle, run bin/rails generate avo:install, and mount Avo at /avo behind that authentication so only signed-in staff reach it.
2. Design the data model from first principles before writing a migration. A two-sided marketplace has to represent the sellers who apply and get approved, the listings they publish, the buyers who order, the orders and the money that flows from them to sellers, and the disputes that arise when something goes wrong. Decide which entities deserve tables, how a seller's application state and a listing's moderation state are best stored (enum on the record or a table with history), and how everything associates. Write the plan down, then generate migrations and models.
3. Generate an Avo resource per model with bin/rails generate avo:resource (https://docs.avohq.io/4.0/resources.html). Set self.title to what staff would recognize, such as a shop name or an order number, list associations in self.includes so the Index view does not query per row, and give self.search a query over the columns staff type. Match fields to columns: badge for statuses, date_time for timestamps, country for a seller's country, belongs_to and has_many so a seller, their listings, orders, payouts, and disputes render as linked screens.
4. Turn the marketplace verbs into Avo Actions: approve, reject, or suspend a seller with a required reason; unpublish a listing with a moderation note; hold or release a payout; resolve a dispute in the buyer's or the seller's favor. Put the real behavior in model methods or small service objects and have each action call them. Payout actions must call a payment service object that you stub for now, never change money columns directly.
5. Add scopes for the queues staff work every day, such as sellers pending review, reported listings, open disputes, and failed payouts (https://avohq.io/addons/scopes), and a dashboard with cards for applications waiting, listings reported this week, open disputes, and payout volume (https://docs.avohq.io/4.0/dashboards.html).
6. Authorize with Pundit policies for three roles: trust and safety (sellers and listings), support (orders and disputes), and finance (payouts and payout account fields). Hide payout account details from every role except finance at the field level, and gate each action by role (https://docs.avohq.io/4.0/authorization.html).
7. Seed realistic data: staff users in each role, sellers in every application state, listings with a few reported ones, orders across sellers, payouts in paid, held, and failed states, and two or three open disputes, so every queue and dashboard card has something to show.
8. Boot the app, sign in as trust and safety, open /avo, approve the oldest pending seller with your action, then sign in as support and confirm the payout account field is hidden on that seller.
start today
Stand up a marketplace back office this week
You pay per app, with unlimited users, so the whole team works from Avo without the bill scaling with headcount. When you hit an edge Avo doesn't cover, you drop to plain Rails instead of filing a feature request.
More things teams run from their Rails app
Avo by industry
Avo for your team
Frequently asked questions
- Can I build a marketplace with Ruby on Rails?
- Yes. A marketplace is sellers, listings, orders, payouts, and disputes, all of which are ordinary Active Record models with associations, and Rails handles the storefront, the checkout, and the background jobs around payments well. The part teams underestimate is the back office: approving sellers, moderating listings, and settling disputes. Avo builds that side on your models so your engineers stay on the buyer and seller experience.
- Does Avo build the storefront my buyers and sellers use?
- No. Avo is the back office for your team, not the customer-facing marketplace. Listing pages, search, checkout, seller onboarding, and the seller dashboard are your Rails app, built the way your product needs them. Avo mounts inside that same app and gives your operations, trust and safety, support, and finance people the screens to run it. Both read the same database, so there is nothing to sync.
- How do we approve or reject sellers?
- Model the application state on the Seller, list the pending ones in a scope, and turn Approve and Reject into Avo actions. An action can ask for a reason or a note before it runs and then calls your own onboarding code, so a rejected seller gets the same email whoever clicked the button. Run it on one seller or a selection.
- Can Avo handle payouts with Stripe Connect?
- Avo does not move money, and it should not. Your Stripe Connect integration, or whichever provider you use, creates payouts and writes them to your database. Avo shows those records next to the seller and the order, filters to failed or held ones, and runs actions such as Hold or Retry that call your own payment code. The integration stays the single place money moves.
- How do we keep finance data away from support?
- Write it once in a Pundit policy. With the Authorization add-on a policy scopes which records a role loads and which fields it sees, so support works orders and disputes while bank details and payout accounts render only for finance. The same rules gate actions, so a support agent cannot release a held payout.
- Can we see who approved a seller or pulled a listing?
- Yes. Actions run under the signed-in user, so your action code can record who did what. For a full trail of every change, with the old and new value and the person who made it, audit logging comes with Avo Enterprise. When a seller asks why their shop was suspended, the answer is on the record.
- Is Avo a good fit for an early-stage marketplace?
- Yes, because the back office grows with the marketplace. Start with a Seller and a Listing resource and an approval action in the first week, then add disputes, payouts, and dashboards when the volume calls for them. Avo Community is free and open source, and paid plans are priced per app with unlimited users, so adding moderators does not change the bill.