I'm Adrian, an indie developer and creator of Avo. For more than ten years, I built countless admin panels and back-offices for all types of apps. After a while, you start to notice patterns and extract functionality away to make the job easier. I took those patterns and applied them to Avo.
Now, in just an hour, a developer can build production-ready applications that with traditional coding techniques take a few days, if not weeks.
Avo is suited to agencies that build a lot of products for their clients and need to move fast and have a beautiful and robust UI, indie developers trying to test out their ideas fast, technical teams in companies of all sizes that need to build internal tools based on Ruby, and start-ups.
Avo runs on top of Ruby on Rails, which is a powerhouse of a framework and uses the most modern tech stack (Hotwire, TailwindCSS, esbuild).
Avo has three main parts that you can choose from:
1. The CRUD UI
2. The Dashboards UI
3. The custom content
The CRUD UI is not something generated that takes maintenance in the long run. Instead, it's a familiar Ruby DSL that's easy to extend with Rails code if you need to break away from it.
It features about 30 fields with more advanced ones like (one-liner) file uploads, WYSIWYG, and key-value fields.
The Dashboards are a light layer on top of chartkick where one can query the data from the DB or an endpoint and quickly show the data in metrics, charts, or custom partials.
The Custom Content part is the secret sauce of Avo. It enables the developer to extend it even further using regular Rails code. You get access to partials, controller, action, params, and anything else you need to bring your own logic into the UI on every level (field, resource, tool).
Avo has a free Community version that features the powerful CRUD UI, and a paid Pro version for those who need more power and custom content. We also provide technical support for enterprise-like customers.
I know that Rails devs will immediately think of Active Admin, administrate, and other similar projects, and I want to mention that Avo is not them. It's built on a modern stack, and its mission is to become the back-office app and not just an "obscure admin panel that only the core team visits". I don't want to seem harsh, but I challenge non-believers to give Avo an hour of their time to see how it's different.
TBH, I believe Avo is the secret weapon in any developer's toolbox.
They are orthogonal tools. They blend together nicely. I use both on our infrastructure.
Jumpstart is an amazing starter kit (starter kit doesn't do it justice) that gives you accounts, billing, notifications, etc. and Avo takes it over and gives you the ability to build your admin panel/back-office fast AF. It's like you replace rails_admin from Jumpstart.
I've spoken with Chris Oliver and started work on adding Avo to Jumpstart and to have it as an alternative to rails_admin.
I was on the fence if I should add those in, but I'm kind of glad I did.
I feel a little bit like Taylor Otwell in the old days when he was telling people about Laravel, or Evan You back in the day when you'd search for "JS framework" and you'd only get React and Angular.
They were on the verge of something new and useful, but nobody believed. I think developers, in general, are pretty inflexible when it comes to new things (only my oppinion), that's why I wanted to add those.
It's obvious that Avo is not the silver bullet for any app and has caveats in some scenarios. All tools do (Rails, Laravel, NextJS, django, spring, you fill in the rest), but for most apps it really does give you superpowers. You build apps 10x faster and the maintenance work is second to none. And in the end, you get a beautiful app ready to present to your customers or team.
When I was skimming your homepage I was thinking “I really wish this was built on Hotwire” and then I saw that it was. That architecture choice makes me think your bold claims might actually pan out, :).
The fact that the ways to customize/escape are “vanilla rails” and avo is deployed within my app as an engine, make this very very interesting.
As compared to:
* something like retool which is deployed (ie hosted) as an additional layer which calls an api my app exposes. Great for huge organizations, but overkill for a small team (similar to SPA vs Hotwire tradeoff)
* activeadmin where escaping the standard path is extremely hard. Not to mention it’s built on gems which are no longer in favor (inherited resources, etc)
* administrate which I really enjoyed, but felt like the support/roadmap was more of a side project vs an “open core/commercial offering”
Thank you for the kind analysis! I see you understand the product very well from the start! Yes, it's built with the knowledge of past projects you mentioned above and is deisgned to be very easily "escaped from". I know that "escaped from" might sound like you're trapped, but the experience is not that. Avo works with you to build the app you want.
Looking forward to see what you're going to build, and get in touch with me on Discord or Twitter.
Yes brother! I remember the days when I was building "an internal admin for the agency". Something to have for all apps and customers.
We'd build it for customer 1, and then for customer 2 we'd add some features and change some. Same for customer 3, 4, 5, 6, 7. After a few years we ended up with 10 different apps that should be the same. No documentation, sometimes the developer that worked on the app is no longer with the company, a real mess.
This way, it would be like using Rails. Documentation, release, maintenance, the whole shebang!
They are tools that work together nicely. I use both on our infrastructure websites (https://avohq.io).
Jumpstart is an amazing starter app that gives you accounts, billing, notifications, and others, and with Avo you can take over and build your admin panel/back-office fast!
I've spoken with Chris Oliver and started work on adding Avo to Jumpstart and to have it as an alternative to rails_admin.
Yeah, Avo is a great alternative to the free admin we ship with (Administrate). And Jumpstart Pro customers get 20% off their first year of Avo. Thanks for sharing that discount Adrian!
I haven't done large project migrations but I spoke with customers that have and they said it's not that difficult. Most sat down and "did it over a weekend".
Some did migrations from their own custom admin panels "over a weekend". It's kind of crazy how easy it is to get started.
This looks so good... I've been always using Node, Deno or .NET Core for backend infrastructure, but Avo makes me wanna learn Ruby and RoR and make the jump for client-related work. Congrats!
Thank you for the compliment. Yes, I agree the pricing is quite low.
I launched this pricing scheme in March and since then I added a ton of features that, IMHO, have increased Avo's productivity 2x. I haven't updated the pricing yet, but I'll probably do it soon.
I also spoke with other indie developers and they agree that the pricing is quite low.
The pricing may be 'low', but you may help foster a larger 'avo' ecosystem if more people are using it (AKA, keeping the price lower). What was/is attractive about Nova and Filament in the PHP world is that both have moderate ecosystems of packages (free and paid) which extend out the base admin system in niche ways. "avo" might be really good on its own - coupled with dozens of custom add-ons that demonstrate a community of people building their own solutions on top would propel this even farther (imo).
We've been using Avo on my latest side project (https://aoe4world.com) and it has been great experience and Avo saved us a lot of time that we would otherwise spend on building admin interface. Highly recommended it.
Looks incredible. Seems like it is really tailored to small -medium sized apps or devs doing client work. How do you deal with objections around scaling out and lock in?
I am loving the renaissance of “boring” tech stacks.
It's Rails code under the hood. We do a little bit meta-programming but try to keep things as basic as possible exactly for this reason so we don't get in the way of the parent app.
We mitigated the "tiny stupid" mistakes like n+1 with dedicated includes option. The front-end is powered by Hotwire so a very small JS bundle.
We have a few customers that are running medium-to-large applications with Avo and they are quite happy with the results. I do admit they have started to do a bit of "magic" to support their use cases, but we're in contact with them and actively extracting things to make the developer experience better and support more use-cases. One example is the tabs and panels features that we're preparing to release next.
Looks awesome. I'm a bit jealous Rails has this resource coming from the Django world (although I know django admin also great but has its limitations)
I believe it's better than having nothing. I think there's a lot to be done in this space and having someone or a team working on it full time is the way to go.
Absolutely. I know there are some projects kind of like this, but right now they are lost in my bookmarks folder somewhere... I recall a couple of good admin dropin replacements, I think one or two even have a paid-model which I dig cause I'm more than willing to pay for django-specific code that will save me development time. Likewise, I know there's some good projects trying to do something similar to Avo, but again I've lost them in bookmarks and my google-fu isn't working to retrieve them.
If you can, buy their product or sponsor the project. The amount of work it goes into maintaining this kinds of products is quite high. Spread the love!
This is really cool and I like the Tony Iommi take too. Did you pick the name because Iommi's accident and instrument align similarly with Django Reinhardt's?
It is true...I personally regret choosing Django for a project, just because I was more familiar with Python. Libraries are hard to find, and best practices are hard to uncover.
Rails to this day can't be beat, and I don't even ruby that much.
Hey! Minor bit of feedback on the homepage UI; I saw the pricing calculator and the big number wasn't obviously my savings (I assumed it was the cost). I'd make sure that for anyone scanning, it's clear the large $$ amount is savings vs the actual cost!
(Also, while I do think it's important you come off as cheap, I wouldn't lead with "saving money" as the main reason to use your product. It looks like you've built something really interesting, and you don't want early customers to only use you because they think you're the cheapest option!)
I had quite a tough time promoting the product and the homepage calculator was one push to highlight one quality of Avo ($ savings). But I agree, that's shouldn't be the biggest selling point.
I'll make sure to position the product differently.
For what it's worth, I do like that it builds as you scroll down! It shows how much goes into building an app. I wonder if switching the focus to just the dev time, or even have some sort of chart of all the other tools that slowly merges into Avo?
EDIT: Or a cute "Dev todo list" that gets crossed off (https://roughnotation.com/) as you scroll down, and Avo takes care of things for you?
Those roughnotation.com animations look so cool! I don't know how much time was spent on building those, but you don't want to know how much time I spent on building that calculator :grinning face with sweat:
There are a few free packages (Active Admin, administrate, rails admin) built a few years ago that can help you build a CRUD UI, but the conversations I had with developers is that they are a bit annoyed with them.
I built Avo as a modern alternative learning from the past products and improving on them.
Why do you say that? Start-ups by definition need to move fast and test out hypothesis. With a tool like Avo you could prototype something, get it out to your customers and get feedback fast.
The secodn use-case is internal tooling. When I worked at a start-up we had a lot of "shady" internal tools built fast, crappy and unreliable (because it's just an internal tool) and we always had issues working with them.
I build a lot of internal tooling using Avo and the process is quite painless.
Sorry about that. I'll try to make that clearer. We have an FAQ item on teh bottom of the page.
The pricing is per project (per app). You pay $250, and you get one year of updates and then use it forever.
The license is a Perpetual Fallback License. When you stop paying for a subscription, you will still be able to keep and use the latest version of Avo at the point in time when the subscription ended but you will loose the ability to update to a newer version.
Regarding locking and doing transactions, it does not support that, but that's a very good idea and not that difficult to add in the near-future. Ideally to let the developer specify what kind of locking strategies to use.
The "one year of updates" thing is kind of confusing. What if an app has a longer lifetime than that? Can you no longer get updates to Avo? What about bugs and security updates?
I think you're over-complicating the pricing. Why not just say it's $250 per project per year? You can still keep the fallback option and explain it in your FAQ. It would be more immediately understandable this way imo.
I tried that and the question that popped up was "what if I don't pay anymore? will I not be able to use it then?". It kind of turned people away, and that's why I change the copy.
If an app has a longer lifetime than a year, and I hope it does, then you'd have to resume the subscription to get the updates (bugs and security). It's the way the perpetual-fallback license works. There are plenty of products (table plus, jumpstart rails) and large companies (jetbrains) that practice this model. I wish there was an easier way of shipping those updates without a subscription.
I think it’s a mistake to optimize for people whose focus is what happens if they stop paying you. They’re unlikely to pay in the first place and are more likely to be difficult customers even if they do.
Customers who get value out of your product will want to pay and keep paying and be sure they’re not going to miss important updates if they forget to renew in a year. These are the customers to focus on imo.
People are happy to pay subscriptions for software they get continuing value from. There’s no need to reinvent the wheel on this.
I mostly agree with you, but that's on more "traditional" SaaS products. When it's a service. This is more of a product.
There are developers and agencies that buy Avo, build something for a customer and then transfer the license to them. The customer might not even know that the agency bought something. They might not want to pay something ongoing.
Yes, one could make the case that "hey, you pay hosting ongoing after the project is delivered, why not pay the admin framework?" and that's fair, but I just don't know if we're at that point yet. I'd love it if Avo would bring us closer to that point.
I see your point, but I think it’s just a framing issue. It’s great to have an option for people who are concerned about this, but not at the expense of confusing customers who just want to pay you and keep paying you for your thing, and also killing your year 2 retention by making it opt-in instead of a normal subscription.
Looking at jumpstart rails, they seem to be doing exactly what I’m suggesting. It’s a simple per project per year price, but then in their FAQ they explain that you stop getting updates if you stop paying.
On the agencies point, yeah I think it’s normal for agencies to sign a client up for a bunch of services they need to build the project. You’ll just be one more on the list.
Well... Avo's pricing is exacty like Jumpstart's (except the $750 for unlimited). So pay $250, get Avo (or Jumpstart) with a year of updates. When you stop paying, you keep what you have until that point and no more updates. Isn't that the same? Am I missing something?
Also, you do make a point regarding agencies "sign a client up for a bunch of services". I'll try and experiment with that. Thanks for the nudge!
Right, that’s exactly my point! Jumpstart has basically the same pricing/licensing but doesn’t frame it in a confusing way.
At first glance, it’s just a yearly subscription per project. Simple and standard. Everyone understands it.
If I’m concerned about what happens if I stop paying for jumpstart, I can find that information, but it’s not emphasized at the top like it is on your pricing page. And the yearly subscription is the default, not something I have to opt into again every year.
Most customers are just going to sign up for a yearly subscription and never look back. It’s better for the customer and for jumpstart.
This is the approach JetBrains takes with their IDE suite and it's the best of both worlds in my opinion. It takes most of the risk out of the decision-making process. To date I've kept my subscription active, but I probably wouldn't have signed up if I didn't have a fallback option.
Maybe this is an esoteric case, but I have a project from a previously operating business (TechStars Boston 2010). Every now and then I think I'd like to take a nice stroll down memory lane. And then I remember I have one component that was an annual SaaS that I no longer have an expensive license for, so the thing won't boot. And I don't have the wherewithal to invest the time to replace it. It's extremely unlikely I'll ever adopt something similar in future projects, personal or otherwise.
I get "continuing value" from all sorts of things I'd never want a subscription for. If you're confident in your product's ability to innovate and continue to add value, you shouldn't worry about attrition. Providing a fallback option makes it clear to me that you have that confidence and that makes a huge difference during a purchase decision.
Just to be clear, I’m not arguing that he should remove the fallback option, just that a subscription should be the default. I agree the fallback is a good thing that reduces lock-in/shutdown risk. But that benefit can still be offered alongside a yearly subscription.
Looks cool - looking forward to trying it out. One thing I feel is missing from rails today is a great text editor. ActiveText feels old compared to editors like TipTap.
Any plans or recommendations on standardizing on a new rich text editor for Avo?
I feel your pain. I see the talk in the community around text editors and I monitor it closely.
TBH, I haven't built anything like that before and I'm not sure if my efforts would be spent in the best way if I tried to. I added Trix to Avo because it played well out-of-the box with Rails.
I'll be watching the text editors race and will add the winners to Avo.
I suspect it won't be for long. The concept of the programmable/standard 'resource wrapper' around the models in a framework like laravel or rails provides a decent separation for adding on standard behavior without actually having to touch any of your existing code. If you're the first in the rails world to do this, you won't be the last.
Look at filamentphp as well for some inspiration/ideas.
Yeah, the guys at bullettrain do a good job! I think of them as being in the same category as Jumpstart. They give you the tools to build the SaaS part of your app, Avo takes it from there and enables you to move very fast with the rest of your app.
I am excited to see more of these Frameworks on top of Frameworks happening. Folks interested in this may also want to check out Bullet Train [0]. They are also a Rails Framework/Framework. I believe they started out with a pricing model that was more expensive than this but have pivoted to open source.
I appreciate Bullet Train’s opinionated idea that APIs and webhooks should be part of any project and they have built it in. Anyhow, it’s worth checking out, in addition to Avo.
Yeah, I mentioned bullettrain somewhere in a comment below. It's an amazing SaaS starter kit.
As far as I know, they have some things as open source and some not. Not sure if they published the pricing for the subscription packages though. A lot of people are wondering what that's going to cost.
I used Avo with Jumpstart and they go together wonderfull. Probably with bullettrain too.
Looking into it a bit more, it seems more aimed at building admin panels than whole apps. I guess it competes against tools like https://activeadmin.info/?
Great comment! It does intersect a bit with Active Admin, but it's meant to do so much more.
Avo is not meant to be an "obscure admin panel" where only the core team members go to do some CRUD operations. It's meant to be the interface on which you build your back-office. Something that you'd love to give to your users from day one. Something that will make you, the developer, look like a superhero, all with little to no sweat.
This is a serious question: Do any of you folks get paid good money to start projects? In my career I have "started" projects for maybe 2-5% of my time. All of the real effort goes in to massaging the app to actually solve unique business problems, about 80-90% on edge cases.
Bold and cynical claim: Making and selling apps like this is akin to building a social media brand about building social media brands. The problem this solves is only experienced by serial creators who like starting projects, not making useful stuff. I personally know 2 people who are like that attempted to start this exact same concept for a company, and that was like 6 years ago, and it was Rails too.
I've been working on four projects in the last 12 months. I helped starting one of them in 2017 (Elixir / Phoenix.) I inherited a RoR one in 2012 and two Django ones in 2016 and 2019.
Given the long life of projects that make money one doesn't start many of them but being able to show something in a short time is important. It helps to focus on features and not to get lost in architectural yak shaving.
> Making and selling apps like this is akin to building a social media brand about building social media brands
So much this.
I really can't understand all the excitement above, unless you're starting a new proof of concept daily (but then, the price looks ridiculous) and you're ready for the "buy now - pay later" way of development. If "move fast break things" is still the thing in 2022, then it makes more sense to just draft an MVP in html/js with something like Firestore as a backend?
"draft an MVP in html/js with something like Firestore as a backend"... so much here. It sounds easy, but is it? I remember the days when I would get stuck on a webpacker config issue instead of working on the real meat of my app.
I speak weekly with developers that tell me "oh, you made an admin panel. I could build that in a few hours. we don't need it." and they never do. They really can't. It's a tough thing to make something quick, reliable, and that gives you no headaches in the short and long run.
And, I guess the excitement is not just for building MVPs, but in general for how much things have evolved and that we have alternatives to copy and pasting forms and fields around.
I'm not going to say that everyone should use Avo. I believe that each developer vibes with some technologies. That's why we use ruby, PHP, JS, VSCode, vim, chrome, firefox, linux or macs. Because we understand them, think in that way, and push out great work with them. So yeah, if Firestore is your thing you should use it. I'm not pointing any fingers.
> "oh, you made an admin panel. I could build that in a few hours. we don't need it." and they never do.
I was never saying making anything with any technology is easy.
Developing with plain Rails and a minimum of gems is linearly difficult while developing with a set of DSL/generators like Avo can lead to a complexity spike from 1 to 11 in no time. And the worst thing — at a random stage of development.
From the business perspective of view, I really like it: it's a perfect example of a micro-project and I wish you the most of luck.
> "Developing with plain Rails and a minimum of gems is linearly difficult while developing with a set of DSL/generators like Avo can lead to a complexity spike from 1 to 11 in no time. And the worst thing — at a random stage of development"
I wholeheartedly agree with this post. I have used/tried every admin panel creator gem under the sun. Or other 'quickstart' products out there such as Jumpstart. Other than that there has been several efforts to make admin panels for rapid app creation that come with some CSS flavor. And always end up hitting the same ceiling, that one feature that cannot be created due to DLS limitations or whatever, and then its all back to square one just that now you have to hack the shit out of the app to make things work.
Never going down the road of using tools like OP's one, I rather spend more time writing boilerplate, which in the end is what's saving here.
It does look like a nicely crafted project and I wish OP luck with it.
I believe that no tool is perfect. Not even Rails. We reach for other gems and sometimes do things not "the Rails way" and we get the job done.
And there's a fallacy there. We don't go saying "Rails doesn't do everything I need it to do, so I'd rather spend more time to write my framework from scratch". But we're (and I'm including myself too) very quick to say things like that about certain tools just because "it's never been done before", "Nobody uses an off-the-shelf package to build their app on", "I'll hit a ceiling with it...", and so on.
Yes, Avo isn't perfect, and yes, Avo isn't right for any kind of project. There are some that are more suited and some that aren't. Sometimes you might hit a "ceiling" with Avo, but I baked in a ton of "escape hatches" (add own content on multiple levels, override views, override controllers, multiple ways of interacting with the data, Stimulus JS). Using these "escape hatches" (I gotta stop using that term), will help you get the job done.
This message is not fingepointing towards you or anyone else, and I respect everyone's way of doing things, but we should take some time and reflect on that. We don't go and build linuxes, nginxes, pumas, railses and other pieces of tooling everytime beacause we might get stuck at one point. We make it work. Same should apply with pieces of software like Avo.
A very pertinent question. If you're asking if Avo "pays the bills", it doesn't. I hope it will some day. Damn, I hope I earn money in some other way and donate Avo to Ruby central, becomes free so it becomes the default way of building Rails apps.
Until that time, I am pretty stocked that other developers want (and pay) to use something I've created.
Yeah, it takes a lot to build the messaging around a product. This current message "Build apps 10x faster" is probably the 10th or 20th iteration. I had to speak with a lot of users and try to figure out how it helps them in their daily dev life.
Building the product is the easy thing (for a developer), doing the marketing, steering it into the right direction, figuring out what the best features are, sales, funnels, etc. Those are the difficult things. They are difficult for me because I don't have a following.
Regarding your "Bold and cynical claim", I respect your opinion. I wouldn't go to say that everyone just want to build a following and launch useless product to achieve that.
Oh, I see what you mean. What kind of "gigs" they get. "Starters" or "continuers" (maintenance).
Gotcha! Personally I started a lot of projects. Probably more than 50%. And the money were good, but not as good as doing maintenance for a big company with a big product.
> Do any of you folks get paid good money to start projects?
I would argue with this thesis. There is a whole market of templates: themeforest, wrapbootstrap, template monster, creative-tim, flatlogic (my company) and others.
Templates are solely used to start the project, so I would say that the market is large
One of our biggest supporters Equipe Technique are building a Shopify like platform ontop of Avo. It's not their admin, but the actual user interface, so go for it! Dream big!
Not sure what documentation should I write about that. Just build it like I do in the videos or from the docs site and the result is the actual website . Done!
Yes you can. Our site uses Jumpstart (lovely app) and we use Avo everyday with it.
Avo was designed to be unopinionated. I know that might sound off. Avo has a DSL, it must be opinionated, and it is with that DSL, but with the rest, we'd like to allow the developer to use what they want.
BYOB.
Bring your own authentication. You might not want to use devise, but something else. Avo enables you to add your own auth layer.
Bring your own search. Avo plays well with ransack, but you can hook into it and do your thing with algolia or something else.
Bring your own layer of multi tenancy. Scope things out as much as you need it. We have a customer that runs three platforms in one app using Avo. Believe me when I say they were able to scope out their data "to the bone".
So yeah. Avo plays amazingly well with existing apps. It was designed that way.
When one says "admin panel", the general belief is that it's an obscure space where only the core team comes to check on some stats, or update some records. Avo is more about building a real app with it. It's meant to be what the user sees when they interact with your app. You actually build your app with Avo. Avo becomes the app.
When I talk to Rails developers and mention the words "admin panel", they automatically think about Active Admin, or administrate, which were great alternatives in the past, but nothing compared to Avo (apologies, sounds like I'm bragging, but I'm really not exaggerating). That's the reason I don't communicate that.
I have a "Rails admin themed" page[0] where I speak more about the benefits as a Rails admin.
congrats on launching, what's the landscape now and who are your competitors? it could be nice if you had a comparison page as a way to sell it further.
I'd say that the classic direct competition are Active Admin, Administrate, rails admin. They are the OG admin panel builders in the Rails world. They focus a lot on building just classic CRUD admin panels.
I focused on making Avo a whole app development platform. It's not that hidden place where just a few team members go to update some records, but the actual UI that you give to your users.
I'll make sure to create an "alternatives" page with competitors.
My only suggestion would be to perhaps try out a beefer instance for heroku or perhaps it is http/1.1 limitation of heroku and a switching to one of the disruptors like render.com would help performance?
It also may completely be because I am in the UK. Clicking around just feels slow 700-800ms+ response times, assuming its hosted in US.
Also another quick fix might be sending the request on mouse down. I know unpoly (side competitor to Hotwire) does this https://unpoly.com/a-up-instant
adrianthedev: THANK YOU for implementing a one-time fee. It actually make using this realistic for us.
Quick question: Do you have support for front-end frameworks (i.e. React)? I did try to crawl the docs to find out.
We have a Rails monolith, but we're unique in that we have a highly interactive educational app with a boat load of javascript. Our mantra has been: use React only if we absolutely have to. I realize we're unique in this regard.
Totally cool if not; just thought I'd ask. Great work on the project!
Avo is built using Hotwire (Turbo and StimulusJS) so no fancy framework (React, vue, svelte) under the hood. We love Stimulus and goes very well with Rails development.
That beign said, Avo supports adding your own custom content (erb templates) and your own asset pipeline (webpacker, sprockets, or something else), so in theory you could inject React or Vue sprinkles here and there.
169 comments
[ 3.1 ms ] story [ 271 ms ] threadI'm Adrian, an indie developer and creator of Avo. For more than ten years, I built countless admin panels and back-offices for all types of apps. After a while, you start to notice patterns and extract functionality away to make the job easier. I took those patterns and applied them to Avo. Now, in just an hour, a developer can build production-ready applications that with traditional coding techniques take a few days, if not weeks.
Avo is suited to agencies that build a lot of products for their clients and need to move fast and have a beautiful and robust UI, indie developers trying to test out their ideas fast, technical teams in companies of all sizes that need to build internal tools based on Ruby, and start-ups.
Avo runs on top of Ruby on Rails, which is a powerhouse of a framework and uses the most modern tech stack (Hotwire, TailwindCSS, esbuild).
Avo has three main parts that you can choose from:
1. The CRUD UI
2. The Dashboards UI
3. The custom content
The CRUD UI is not something generated that takes maintenance in the long run. Instead, it's a familiar Ruby DSL that's easy to extend with Rails code if you need to break away from it. It features about 30 fields with more advanced ones like (one-liner) file uploads, WYSIWYG, and key-value fields.
The Dashboards are a light layer on top of chartkick where one can query the data from the DB or an endpoint and quickly show the data in metrics, charts, or custom partials.
The Custom Content part is the secret sauce of Avo. It enables the developer to extend it even further using regular Rails code. You get access to partials, controller, action, params, and anything else you need to bring your own logic into the UI on every level (field, resource, tool).
Avo has a free Community version that features the powerful CRUD UI, and a paid Pro version for those who need more power and custom content. We also provide technical support for enterprise-like customers.
I know that Rails devs will immediately think of Active Admin, administrate, and other similar projects, and I want to mention that Avo is not them. It's built on a modern stack, and its mission is to become the back-office app and not just an "obscure admin panel that only the core team visits". I don't want to seem harsh, but I challenge non-believers to give Avo an hour of their time to see how it's different.
TBH, I believe Avo is the secret weapon in any developer's toolbox.
I'm here to answer all of your questions.
Thank you
https://docs.avohq.io/2.0/recipes/multilingual-content.html
Besides, EEEY-vo is more fun to say than UH-vo.
Jumpstart is an amazing starter kit (starter kit doesn't do it justice) that gives you accounts, billing, notifications, etc. and Avo takes it over and gives you the ability to build your admin panel/back-office fast AF. It's like you replace rails_admin from Jumpstart.
I've spoken with Chris Oliver and started work on adding Avo to Jumpstart and to have it as an alternative to rails_admin.
TBH, I believe Avo is the secret weapon in any developer's toolbox.”
Earnestly, I wish you well. These are rather bold claims.
I feel a little bit like Taylor Otwell in the old days when he was telling people about Laravel, or Evan You back in the day when you'd search for "JS framework" and you'd only get React and Angular.
They were on the verge of something new and useful, but nobody believed. I think developers, in general, are pretty inflexible when it comes to new things (only my oppinion), that's why I wanted to add those.
It's obvious that Avo is not the silver bullet for any app and has caveats in some scenarios. All tools do (Rails, Laravel, NextJS, django, spring, you fill in the rest), but for most apps it really does give you superpowers. You build apps 10x faster and the maintenance work is second to none. And in the end, you get a beautiful app ready to present to your customers or team.
Thank you for the encouragement! I need it :)
The fact that the ways to customize/escape are “vanilla rails” and avo is deployed within my app as an engine, make this very very interesting.
As compared to:
* something like retool which is deployed (ie hosted) as an additional layer which calls an api my app exposes. Great for huge organizations, but overkill for a small team (similar to SPA vs Hotwire tradeoff)
* activeadmin where escaping the standard path is extremely hard. Not to mention it’s built on gems which are no longer in favor (inherited resources, etc)
* administrate which I really enjoyed, but felt like the support/roadmap was more of a side project vs an “open core/commercial offering”
Looking forward to see what you're going to build, and get in touch with me on Discord or Twitter.
https://avo.cool/chat
https://twitter.com/adrianthedev
I've worked in the industry for a while and admin pages / reports usually being at least 50% of the effort. Sometimes, it's more like 90%.
So, there's a lot of potential impact there.
We'd build it for customer 1, and then for customer 2 we'd add some features and change some. Same for customer 3, 4, 5, 6, 7. After a few years we ended up with 10 different apps that should be the same. No documentation, sometimes the developer that worked on the app is no longer with the company, a real mess.
This way, it would be like using Rails. Documentation, release, maintenance, the whole shebang!
Thanks for sharing!
[0] https://twitter.com/avo_hq [1] https://avo.cool/chat [2] https://github.com/avo-hq/avo [3] https://twitter.com/adrianthedev
They are tools that work together nicely. I use both on our infrastructure websites (https://avohq.io). Jumpstart is an amazing starter app that gives you accounts, billing, notifications, and others, and with Avo you can take over and build your admin panel/back-office fast!
I've spoken with Chris Oliver and started work on adding Avo to Jumpstart and to have it as an alternative to rails_admin.
I'm humbled to have built something that could ship with Jumpstart. Thank you for the kind words!
Some did migrations from their own custom admin panels "over a weekend". It's kind of crazy how easy it is to get started.
I'd love talk to you if you ever want to try it out.
I launched this pricing scheme in March and since then I added a ton of features that, IMHO, have increased Avo's productivity 2x. I haven't updated the pricing yet, but I'll probably do it soon.
I also spoke with other indie developers and they agree that the pricing is quite low.
Thank you for the feedback!
Yeah, that's my vision too. To create the plugin system and enable developers to hook into that ecosystem and earn money.
I am loving the renaissance of “boring” tech stacks.
We mitigated the "tiny stupid" mistakes like n+1 with dedicated includes option. The front-end is powered by Hotwire so a very small JS bundle.
We have a few customers that are running medium-to-large applications with Avo and they are quite happy with the results. I do admit they have started to do a bit of "magic" to support their use cases, but we're in contact with them and actively extracting things to make the developer experience better and support more use-cases. One example is the tabs and panels features that we're preparing to release next.
Yup. Boring is good. It just works!
Disclaimer: I'm one of the authors of iommi.
Thank you for developing this! I'll let you know how it goes and try to contribute where I can
Rails to this day can't be beat, and I don't even ruby that much.
(Also, while I do think it's important you come off as cheap, I wouldn't lead with "saving money" as the main reason to use your product. It looks like you've built something really interesting, and you don't want early customers to only use you because they think you're the cheapest option!)
Overall, this looks really great... good luck!
I had quite a tough time promoting the product and the homepage calculator was one push to highlight one quality of Avo ($ savings). But I agree, that's shouldn't be the biggest selling point.
I'll make sure to position the product differently.
Thank you!
EDIT: Or a cute "Dev todo list" that gets crossed off (https://roughnotation.com/) as you scroll down, and Avo takes care of things for you?
I built Avo as a modern alternative learning from the past products and improving on them.
The secodn use-case is internal tooling. When I worked at a start-up we had a lot of "shady" internal tools built fast, crappy and unreliable (because it's just an internal tool) and we always had issues working with them.
I build a lot of internal tooling using Avo and the process is quite painless.
Each project has it's own requirements and budget.
Thank you for your message!
Also at what is the frameworks strategie on locking doing transactions in the database.
The pricing is per project (per app). You pay $250, and you get one year of updates and then use it forever.
The license is a Perpetual Fallback License. When you stop paying for a subscription, you will still be able to keep and use the latest version of Avo at the point in time when the subscription ended but you will loose the ability to update to a newer version.
Regarding locking and doing transactions, it does not support that, but that's a very good idea and not that difficult to add in the near-future. Ideally to let the developer specify what kind of locking strategies to use.
I added this topic to keep track of. https://github.com/avo-hq/avo/discussions/982
I think you're over-complicating the pricing. Why not just say it's $250 per project per year? You can still keep the fallback option and explain it in your FAQ. It would be more immediately understandable this way imo.
If an app has a longer lifetime than a year, and I hope it does, then you'd have to resume the subscription to get the updates (bugs and security). It's the way the perpetual-fallback license works. There are plenty of products (table plus, jumpstart rails) and large companies (jetbrains) that practice this model. I wish there was an easier way of shipping those updates without a subscription.
Customers who get value out of your product will want to pay and keep paying and be sure they’re not going to miss important updates if they forget to renew in a year. These are the customers to focus on imo.
People are happy to pay subscriptions for software they get continuing value from. There’s no need to reinvent the wheel on this.
There are developers and agencies that buy Avo, build something for a customer and then transfer the license to them. The customer might not even know that the agency bought something. They might not want to pay something ongoing.
Yes, one could make the case that "hey, you pay hosting ongoing after the project is delivered, why not pay the admin framework?" and that's fair, but I just don't know if we're at that point yet. I'd love it if Avo would bring us closer to that point.
Looking at jumpstart rails, they seem to be doing exactly what I’m suggesting. It’s a simple per project per year price, but then in their FAQ they explain that you stop getting updates if you stop paying.
On the agencies point, yeah I think it’s normal for agencies to sign a client up for a bunch of services they need to build the project. You’ll just be one more on the list.
Also, you do make a point regarding agencies "sign a client up for a bunch of services". I'll try and experiment with that. Thanks for the nudge!
At first glance, it’s just a yearly subscription per project. Simple and standard. Everyone understands it.
If I’m concerned about what happens if I stop paying for jumpstart, I can find that information, but it’s not emphasized at the top like it is on your pricing page. And the yearly subscription is the default, not something I have to opt into again every year.
Most customers are just going to sign up for a yearly subscription and never look back. It’s better for the customer and for jumpstart.
"It’s better for the customer and for jumpstart." It's true.
Maybe this is an esoteric case, but I have a project from a previously operating business (TechStars Boston 2010). Every now and then I think I'd like to take a nice stroll down memory lane. And then I remember I have one component that was an annual SaaS that I no longer have an expensive license for, so the thing won't boot. And I don't have the wherewithal to invest the time to replace it. It's extremely unlikely I'll ever adopt something similar in future projects, personal or otherwise.
I get "continuing value" from all sorts of things I'd never want a subscription for. If you're confident in your product's ability to innovate and continue to add value, you shouldn't worry about attrition. Providing a fallback option makes it clear to me that you have that confidence and that makes a huge difference during a purchase decision.
Any plans or recommendations on standardizing on a new rich text editor for Avo?
TBH, I haven't built anything like that before and I'm not sure if my efforts would be spent in the best way if I tried to. I added Trix to Avo because it played well out-of-the box with Rails.
I'll be watching the text editors race and will add the winners to Avo.
My train of thought was "Rails helps you build apps fast! If we had something like Nova it would make it 10x faster!".
I belive the pair (Rails and Avo) is one of a kind in the frameworks world.
Look at filamentphp as well for some inspiration/ideas.
I'm aware that Avo (like Nova) is not suitable for any type of app. It's for "most apps" where you use common things like CRUD, dashboards, and cards.
Speaking of competition, it's only going to make the ecosystem better, so I'm all up for it.
Unfortunately not all of us are on ruby...but everyone is on js. Would totally love something like this on React/Next.
This is such an interesting statement.
It reminds me of Bullettrain: https://bullettrain.co/
I appreciate Bullet Train’s opinionated idea that APIs and webhooks should be part of any project and they have built it in. Anyhow, it’s worth checking out, in addition to Avo.
[0] https://bullettrain.co/
As far as I know, they have some things as open source and some not. Not sure if they published the pricing for the subscription packages though. A lot of people are wondering what that's going to cost.
I used Avo with Jumpstart and they go together wonderfull. Probably with bullettrain too.
Also, I think you could make some sort of adapter between the two. Pundit is mostly a Ruby class.
Looking into it a bit more, it seems more aimed at building admin panels than whole apps. I guess it competes against tools like https://activeadmin.info/?
Avo is not meant to be an "obscure admin panel" where only the core team members go to do some CRUD operations. It's meant to be the interface on which you build your back-office. Something that you'd love to give to your users from day one. Something that will make you, the developer, look like a superhero, all with little to no sweat.
Bold and cynical claim: Making and selling apps like this is akin to building a social media brand about building social media brands. The problem this solves is only experienced by serial creators who like starting projects, not making useful stuff. I personally know 2 people who are like that attempted to start this exact same concept for a company, and that was like 6 years ago, and it was Rails too.
Given the long life of projects that make money one doesn't start many of them but being able to show something in a short time is important. It helps to focus on features and not to get lost in architectural yak shaving.
"Listen to your customers and push out the features they need, not the features you think they need."
So much this.
I really can't understand all the excitement above, unless you're starting a new proof of concept daily (but then, the price looks ridiculous) and you're ready for the "buy now - pay later" way of development. If "move fast break things" is still the thing in 2022, then it makes more sense to just draft an MVP in html/js with something like Firestore as a backend?
I speak weekly with developers that tell me "oh, you made an admin panel. I could build that in a few hours. we don't need it." and they never do. They really can't. It's a tough thing to make something quick, reliable, and that gives you no headaches in the short and long run.
And, I guess the excitement is not just for building MVPs, but in general for how much things have evolved and that we have alternatives to copy and pasting forms and fields around.
I'm not going to say that everyone should use Avo. I believe that each developer vibes with some technologies. That's why we use ruby, PHP, JS, VSCode, vim, chrome, firefox, linux or macs. Because we understand them, think in that way, and push out great work with them. So yeah, if Firestore is your thing you should use it. I'm not pointing any fingers.
I was never saying making anything with any technology is easy.
Developing with plain Rails and a minimum of gems is linearly difficult while developing with a set of DSL/generators like Avo can lead to a complexity spike from 1 to 11 in no time. And the worst thing — at a random stage of development.
From the business perspective of view, I really like it: it's a perfect example of a micro-project and I wish you the most of luck.
I agree 100% with your statement! Really!
Thank you!
Never going down the road of using tools like OP's one, I rather spend more time writing boilerplate, which in the end is what's saving here.
It does look like a nicely crafted project and I wish OP luck with it.
And there's a fallacy there. We don't go saying "Rails doesn't do everything I need it to do, so I'd rather spend more time to write my framework from scratch". But we're (and I'm including myself too) very quick to say things like that about certain tools just because "it's never been done before", "Nobody uses an off-the-shelf package to build their app on", "I'll hit a ceiling with it...", and so on.
Yes, Avo isn't perfect, and yes, Avo isn't right for any kind of project. There are some that are more suited and some that aren't. Sometimes you might hit a "ceiling" with Avo, but I baked in a ton of "escape hatches" (add own content on multiple levels, override views, override controllers, multiple ways of interacting with the data, Stimulus JS). Using these "escape hatches" (I gotta stop using that term), will help you get the job done.
This message is not fingepointing towards you or anyone else, and I respect everyone's way of doing things, but we should take some time and reflect on that. We don't go and build linuxes, nginxes, pumas, railses and other pieces of tooling everytime beacause we might get stuck at one point. We make it work. Same should apply with pieces of software like Avo.
Thank you for the message!
Until that time, I am pretty stocked that other developers want (and pay) to use something I've created.
Yeah, it takes a lot to build the messaging around a product. This current message "Build apps 10x faster" is probably the 10th or 20th iteration. I had to speak with a lot of users and try to figure out how it helps them in their daily dev life.
Building the product is the easy thing (for a developer), doing the marketing, steering it into the right direction, figuring out what the best features are, sales, funnels, etc. Those are the difficult things. They are difficult for me because I don't have a following.
Regarding your "Bold and cynical claim", I respect your opinion. I wouldn't go to say that everyone just want to build a following and launch useless product to achieve that.
I was in general asking the community about how often they get paid to start apps vs. continue them.
Gotcha! Personally I started a lot of projects. Probably more than 50%. And the money were good, but not as good as doing maintenance for a big company with a big product.
I would argue with this thesis. There is a whole market of templates: themeforest, wrapbootstrap, template monster, creative-tim, flatlogic (my company) and others.
Templates are solely used to start the project, so I would say that the market is large
Avo was designed to be unopinionated. I know that might sound off. Avo has a DSL, it must be opinionated, and it is with that DSL, but with the rest, we'd like to allow the developer to use what they want.
BYOB.
Bring your own authentication. You might not want to use devise, but something else. Avo enables you to add your own auth layer.
Bring your own search. Avo plays well with ransack, but you can hook into it and do your thing with algolia or something else.
Bring your own layer of multi tenancy. Scope things out as much as you need it. We have a customer that runs three platforms in one app using Avo. Believe me when I say they were able to scope out their data "to the bone".
So yeah. Avo plays amazingly well with existing apps. It was designed that way.
When I talk to Rails developers and mention the words "admin panel", they automatically think about Active Admin, or administrate, which were great alternatives in the past, but nothing compared to Avo (apologies, sounds like I'm bragging, but I'm really not exaggerating). That's the reason I don't communicate that.
I have a "Rails admin themed" page[0] where I speak more about the benefits as a Rails admin.
https://avohq.io/rails-admin
I focused on making Avo a whole app development platform. It's not that hidden place where just a few team members go to update some records, but the actual UI that you give to your users.
I'll make sure to create an "alternatives" page with competitors.
My only suggestion would be to perhaps try out a beefer instance for heroku or perhaps it is http/1.1 limitation of heroku and a switching to one of the disruptors like render.com would help performance?
It also may completely be because I am in the UK. Clicking around just feels slow 700-800ms+ response times, assuming its hosted in US.
Also another quick fix might be sending the request on mouse down. I know unpoly (side competitor to Hotwire) does this https://unpoly.com/a-up-instant
Yes, it's hosted in the US.
Thank you for that and unploy. I'll have a look.
Quick question: Do you have support for front-end frameworks (i.e. React)? I did try to crawl the docs to find out.
We have a Rails monolith, but we're unique in that we have a highly interactive educational app with a boat load of javascript. Our mantra has been: use React only if we absolutely have to. I realize we're unique in this regard.
Totally cool if not; just thought I'd ask. Great work on the project!
Avo is built using Hotwire (Turbo and StimulusJS) so no fancy framework (React, vue, svelte) under the hood. We love Stimulus and goes very well with Rails development.
That beign said, Avo supports adding your own custom content (erb templates) and your own asset pipeline (webpacker, sprockets, or something else), so in theory you could inject React or Vue sprinkles here and there.