Avo for e-commerce
Run your store's back office from your Rails app
Orders, refunds, inventory, and the catalog, handled by your team from a command center inside your Rails app, so support acts in seconds and engineers stay on the storefront.
250+ paying companies · 2.7M downloads of the avo gem
placed
paid
fulfilling
The queue that gets checked every hour, and the one a generic admin makes slowest.
shipped
refunded
Each status is a saved query your team opens by name, so nobody rebuilds the same filter every morning to find what needs shipping.
01 · the stakes
What running a store actually asks of an admin
The storefront is the app your customers see. The store actually runs on the second app behind it, and that one decides how fast a refund happens, how stale the catalog gets, and how often engineers get pulled off the roadmap.
-
01
Support speed is customer experience
A refund, a resent confirmation, or a corrected address should take the support team seconds. When each one needs a developer and a console, the customer waits days and the ticket queue becomes an engineering queue.
-
02
The catalog changes faster than deploys
Prices, descriptions, images, and stock levels change daily. If merchandising can only edit through seeds, CSVs, or a developer, the catalog is always slightly wrong somewhere.
-
03
Busy seasons multiply everything
A sale week means order edits, refunds, and inventory fixes at ten times the usual volume, exactly when the team has no slack to build tooling. The admin either handles bulk work or becomes the bottleneck.
-
04
Not everyone should be able to edit a price
Support, merchandising, and finance all need in, but with different reach. A shared login where anyone can change a price or delete an order is how a busy Tuesday turns into an incident.
02 · the Avo version
Your models are already the hard part. Avo is the rest.
Avo mounts inside your Rails app and reads the models you already have: orders, products, customers, inventory. You get the second app, the one the store runs on, without building it: filtered order queues, safe bulk actions, a catalog non-engineers can edit, and permissions deciding who touches money versus merchandising.
Order ops in bulk, safely
Refund, cancel, or resend confirmations across every matching order with actions and true select-all, so a sale-week cleanup is one confirmed operation instead of an afternoon of row-by-row clicking.
Queues your team opens every morning
Unfulfilled orders, refund requests, out-of-stock products: scopes and dynamic filters turn each into a saved view, worked oldest-first, no SQL and no engineer in the loop.
A catalog non-engineers can keep current
Products, variants, images, and prices edited in place by merchandising, with your validations still enforced because it is your models underneath. The catalog stops waiting on deploys.
Permissions that match the org chart
Avo reads your Pundit policies, so support can refund but not reprice, merchandising can edit products but not orders, and finance sees everything. Down to the field, in Ruby you review.
The Monday numbers, from the same database
Revenue, order volume, refund rates, and low-stock alerts on dashboards built from your own queries, so the numbers in the meeting match the numbers in production.
An Order resource with saved queues and a bulk refund action:
class Avo::Resources::Order < Avo::BaseResource
self.includes = [:customer, :line_items]
self.search = { query: -> { query.ransack(number_cont: q).result } }
def fields
field :number, as: :text, readonly: true
field :status, as: :select, enum: ::Order.statuses
field :total, as: :number, readonly: true
field :customer, as: :belongs_to, searchable: true
field :line_items, as: :has_many
end
def scopes
scope Avo::Scopes::Unfulfilled
scope Avo::Scopes::RefundRequested
end
def actions
action Avo::Actions::RefundOrder
end
end
03 · the timeline
From first resource to the team running on it
Generate resources for Order, Product, and Customer and the whole team can see real orders, search customers, and open any record the storefront just created.
Put it behind your existing authentication, add the unfulfilled and refund-requested queues as scopes, and ship the refund action so support closes tickets without a console.
Merchandising owns the catalog, policies decide who can touch prices versus orders, and the dashboard shows revenue and refund rates from the same database the store runs on.
case study · multi-tenant rental operations
“Having Avo is like having this extra pair of hands. And I often think of it as just having in-house designer, a front end, and a full stack. So that's what's nice about it. Every time you use it, you save time.”
04 · start today
Give the store its back office this week
Avo is per app with unlimited users, so the whole team works from it 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.
Things e-commerce teams build with Avo
Avo by industry
Avo for your team
Frequently asked questions
- Can I build an e-commerce admin on Ruby on Rails?
- Yes. Whether you built the store on custom models or a framework like Solidus or Spree, your orders, products, and customers are Rails models, and Avo turns them into a working back office: queues, bulk actions, an editable catalog, and permissions, on top of your existing tables.
- Can support refund orders without a developer?
- Yes. A refund becomes an Avo action: a button with a confirmation step that calls the same code path your app uses, alone or across a bulk selection. Support acts in seconds, the change is attributable, and nobody opens a production console. See the actions docs.
- Can non-technical staff manage the product catalog?
- Yes. Products, variants, prices, and images are editable in place by merchandising, and because Avo writes through your models, your validations and callbacks still run. Nobody can save a product your app would consider invalid.
- Does it handle bulk operations on thousands of orders?
- Yes. Avo's select-all is a true select-all: an action runs against every record matching your filters, not just the visible page. Filter to the affected orders, run the action once, confirm, done.
- How do we keep support from editing prices?
- Access is enforced with Pundit policies, the same ones your Rails app uses, per action and per field. Support gets refunds but not price edits, merchandising gets products but not orders, and the rules are Ruby in your repo. See the authorization docs.
- Will it slow down when the order table gets big?
- Avo eager-loads the associations you declare, so index views stay fast on large tables, and you control pagination, search, and caching per resource. It is your database and your queries underneath, tunable like any other part of your Rails app.