Avo for education
Run students, cohorts, and courses from your Rails app
Students, enrollments, cohorts, and course content, managed by your team from a command center inside your Rails app, so admissions and student ops move without waiting on engineering.
250+ paying companies · 2.7M downloads of the avo gem
Cohort
name
starts_on
capacity
Enrollment
status
enrolled_on
Student
full_name
guardian
Enrollment is the join that carries the story: who joined which cohort, when, and whether they are active, deferred, or withdrawn.
the stakes
What running a school or learning product actually takes
The learning experience is the app students see. Behind it sits the app the school actually runs on: enrollments, cohorts, content, and payments. That second app decides how much of your engineers' time education ops consumes.
-
01
Enrollment ops never stops
Deferrals, transfers between cohorts, refunds, and corrections happen every day of the term. When each one is a console command, student-facing fixes queue behind an engineering backlog.
-
02
Course content outlives every deploy schedule
Lessons, syllabi, and materials change constantly, and instructors want to edit them without filing a ticket. Every course catalog needs the same content admin underneath, and building it fresh each time is time not spent on the course.
-
03
Student records deserve real access control
Grades, payment status, and personal details should not be visible to everyone with a login. Admissions, instructors, and finance each need a different slice, and that access model has to hold everywhere the data is reachable, not only on the screen.
-
04
The cohort view lives in spreadsheets
Who is enrolled, who deferred, who has not paid, who is falling behind: when the answer lives in exports and spreadsheets, it is stale by the time anyone reads it.
the Avo version
Your models are already the hard part. Build the rest on Avo.
With Avo mounted inside your Rails app, the models you already have, students, cohorts, enrollments, lessons, become the tool your team runs the school from. Admissions works enrollment queues, instructors edit content, finance sees payments, each behind the Pundit policies your app already uses, all on live data.
Enrollment verbs as one-click actions
Enroll, defer, transfer, refund: each becomes an action with a confirmation step that calls the same code path your product uses, so student ops resolves requests in minutes instead of tickets.
Course content editable by the people who teach it
Lessons, chapters, and materials, with rich text through Action Text and attachments through Active Storage, edited in place by instructors while your validations still run underneath. That is how BBC Maestro manages a rich course catalog.
The cohort roster, live, not exported
A cohort's enrollments render as linked records with filters for status, payment, and progress, so "who has not paid" or "who deferred" is a saved view, not a Friday spreadsheet ritual.
Access shaped to the org
Avo reads your Pundit policies, so instructors see their cohorts but not payments, admissions edits enrollments but not grades, and a field a role cannot see stays hidden in the UI, over MCP, and through the API alike.
The numbers the Monday meeting runs on
Enrollment counts, cohort fill rates, and revenue on dashboards built from your own queries, straight from the same database the product runs on.
An Enrollment resource with cohort queues and a deferral action:
class Avo::Resources::Enrollment < Avo::BaseResource
self.includes = [:student, :cohort]
def fields
field :status, as: :select, enum: ::Enrollment.statuses
field :enrolled_on, as: :date, readonly: true
field :payment_status, as: :badge, visible: -> { current_user.finance? }
field :student, as: :belongs_to, searchable: true
field :cohort, as: :belongs_to
end
def scopes
scope Avo::Scopes::AwaitingPayment
scope Avo::Scopes::DeferralRequested
end
def actions
action Avo::Actions::DeferEnrollment
end
end
the timeline
From first resource to the team running on it
Generate resources for Student, Cohort, and Enrollment and the team can look up any student, open their enrollments, and see each cohort's roster on live data.
Put it behind your existing authentication, add policies so instructors, admissions, and finance each see their slice, and ship the defer and transfer actions so enrollment ops leaves the console.
Instructors edit course content themselves, the awaiting-payment queue is a saved view someone owns, and the enrollment dashboard replaces the Friday spreadsheet.
case study · online course platform
“Avo just worked great. We were able to plug things together really easily... it's given us the flexibility we needed to build out a really rich product.”
start today
Stand up your school's 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.
Things education teams build with Avo
Avo by industry
Avo for your team
Frequently asked questions
- Can I run an edtech platform's admin on Ruby on Rails?
- Yes. Students, cohorts, enrollments, and lessons are ordinary Rails models with associations, and Avo turns them into the tool your team runs the school from, on top of your existing tables. BBC Maestro runs its course platform this way, and the Rails LMS admin page walks through courses, lesson order, learner progress, and certificates.
- Can instructors edit course content without engineering?
- Yes. Lessons and materials become resources with rich text and file fields, editable in place, and because Avo writes through your models, validations and callbacks still run. Content updates stop being deploys.
- How do we keep grades and payments away from the wrong eyes?
- Access is enforced with Pundit policies, the same ones your Rails app uses, per action and per field. Payment fields render only for finance, grades only for instructors and registrars, and the rules are Ruby you review in a PR. See the authorization docs.
- Can student ops handle deferrals and transfers themselves?
- Yes. Each becomes an Avo action with a confirmation step and any inputs you need, a reason, a target cohort, calling the same model methods your product uses. Ops resolves the request in minutes and every change is attributable.
- Where does student data live?
- In your database, inside your own infrastructure. Avo is a Rails engine mounted in your application, so student records never transit a third-party service, which matters when FERPA, GDPR, or a school district's data agreement applies to you. The compliance work remains yours, but the data path stays yours too.
- We already built a small admin. Why switch?
- Because it will keep growing. Every new model needs screens, every role needs permissions, and every term adds requests. With Avo the next resource is a short Ruby file your agent writes on a foundation that is already built, vetted by hundreds of customers, and keeps evolving underneath your code.