It's great to see folks building frameworks on top of frameworks. I've started to look into full stack starter-kit frameworks that goes beyond the admin panel and here's what's out there these days.
I'm hoping enough people converge around any one of these products where we end up with something as high quality as Rails. If the community agrees on how users, authorization, subscriptions, etc. should be modeled, it opens up the door for a set of APIs and plugins that will make creating SaaS products even easier.
My thinking on the economics of this is the Opencore stuff will be a race to the bottom in terms of pricing towards free or a nominal fee (I guess $250/year is that). What will end up costing money is tech support. I do see an ecosystem of third-party services that integrate with SaaS kits emerging, such as rapid ways to deploy, analytics services, etc.
There is now also mine in alpha https://businessclasskit.com/ focused on Rails defaults (Active Storage, Minitest, ...) with Paddle (important for Europeans to skip on dealing with EU taxes).
The more the merrier! I haven't tried it yet but I'm stoked there's movement around it. I love the "Rails defaults" convention. I do the same with Avo.
One problem I had with Paddle is that they haven't accepted me in their program. It would be cool if you'd be able to create some kind of partnership and fasttrack that process somehow.
Yes, it's nice to see the ecosystem go green again. I love Rails and I want it to flourish.
I think bullettrain.co is open core as well. They haven't announce the pricing for the subscriptions packages yet, but I can't wait to see what they come out with.
Regarding "settled libraries", I am all for that. I'd rather have conventions all over and know that devise is on every app, but the truth is that each app is different and has different requirements. That's why Avo is deisgned to work with multiple libaries.
Good luck with monolith and let me know if I can help. I think having Avo in monolith and other similar projects would contribute on that "settled libraries" convention.
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.
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!
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 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.
@adrianthedev I gave it an hour and here are my thoughts.
Generators for resources should be smarter and look a models attributes and type_for_attribute and add all the fields for me. Things like enums should be easier than needed to also specify them as select options.
Thank you for trying it. I mean it! That's all I want :)
> Generators for resources should be smarter and look a models attributes and type_for_attribute and add all the fields for me. Things like enums should be easier than needed to also specify them as select options.
> The suggested generators for namespaced models ```bin/rails generate avo:resource Cms::Page``` dont seam to work
I agree. The generators could be smarter. Maybe even generate a resource when you generate a model. There's a really old PR started a while back.
https://github.com/avo-hq/avo/pull/182
We actually do have them. Date and DateTime with a wonderful date picker (flatpickr). Not sure how you landed on that page (it's for version 1.0). The correct link below.
https://docs.avohq.io/2.0/fields.html
> All attributes should also be default sortable.
TBH, I avoided that by default. I'm not sure you'd like the user to sort by anything from the start, but maybe that's just a thing of preference.
> Also using the models schema should give you default filtering. Strings should be loose, numbers/enums should be exact, datetime should be ranged.
Yes. I agree that an advanced filtering system is helpful and needed. The current filtering system is powerful too. You can make complex queries (query by multiple columns) from one toggle/dropdown, instead of adding multiple filters to get sthe same result.
Thank you for this thorough review. Being a solo developer I have a lot on my plate. I'm talking development and others (marketing, sales, copywriting, etc.). When doing development I have to choose what's important and what can wait. That's why the generators are not that smart. I have a GitHub discussion started around the advanced filtering, but there's not that much ctivity around it. I'd love to bring it in soon.
https://github.com/avo-hq/avo/discussions/739
Until that point I'm focusing on bringing features that help the users and fix real problems for them. That was and is my main concern going forward.
I'm sorry you think it underdelivers. I respect your comment, and I'd love to talk to you and see what you think really is missing. Except for the filters, all the other concerns are not really user-centered.
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:
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.
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.
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.
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.
So a bit of insight from a dinosaur, I'm one of those guys who is a diehard ActiveAdmin user. I've come and gone through the other admin interfaces and nothing is as fast as ActiveAdmin when it comes to the basics.
Important note is ActiveAdmin is for internal/staff only.
Benefits
- It doesn't need to be pretty. It simply needs to function.
- Layout actually should be allowed to be information dense. Less whitespace (i.e. not bootstrap).
- DSL of ActiveAdmin is TERRIBLE, but once you learn the DSL, spinning up a page to edit an object is insanely fast because of it.
- Changes to objects are typically one liners.
- Escape hatches make everything else possible, but it's not intuitive at all.
Difficulties of ActiveAdmin
- Adding Wizards, step-by-step, pages is pretty annoying
- Polymorphic relationships aren't intuitive.
- Learning how to carry the page's context to use arb takes some time.
- Customizing f.input is annoying and doesn't make sense.
- Doesn't play well with bootstrap nor modals.
In the end the difficulties are worth the problems because the time benefit is so high. It's measured in how much time our engineers spend working inside of ActiveAdmin. It's very low compared to other areas.
In the past, I've been stuck fighting React, or doing too much boiler plate.
Thank you for this thorough description! I'll keep an eye out for the shortcomings so they don't creep into Avo.
I'd love it if you'd try Avo for a project (not just for 30 minutes) and compare the two. I think having an experienced developer on a real project would yield a real comparison.
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)
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.
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?
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 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!
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.
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.
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.
For something like this, I bet a chunk of your target market for "Pro" level is people running ActiveAdmin. The beauty (and nightmare) of ActiveAdmin is it just looks at your tables and gives you an admin UI. If you have a mostly API based app, this can be great to give internal people some power tools so they leave the engineers alone.
Would love to see demos with real world complexity level of things instead of the typical Blog or Todo list trackers. To give that some scope for a complex Rails application lets use counts of objects, something like 100 models and 80 active admin pages, scatter in some 50-100 jobs/workers and like 50-100 service objects.
What does Avo provide for a menu-ing or UI customization to deal with that level of complexity?
I would say that the Community version (free) covers most of what Active Admin does. The search is paid with Avo (and included in AA).
The Pro users are those who need to build upon Avo. They need custom content (fields, resource tools, custom pages), and they need to make it look the same as the rest of the app. Avo provides view components that help with that. This way you create a seamless UI for your users.
I think of Avo as more than just and admin panel framework (although power tool sounds great), but the place where you build your app. It becomes the app your users see.
Regarding API based apps, yeah, that's something I'd loke to support soon. Offer HTTP adapters where you coudl hook in your Stripe/Shopify/Intercom/Custom API endpoints.
Regarding complexity, I tried to cram as much as I could (whenever I push out a new feature, I add it) to the demo site[0].
One of the biggest apps I've seen has about 41 resources, 431 fields, and quite some complexity because it's a multi tenancy app that serves three marketplace platforms. There's a lot of complex scoping applied to the data to match the accounts and views.
But, yeah, I'd love to see an app that size. I think the project is still young (about two years. version 2.0 three months old) and these kinds of projects tend to get built out with time. I can't imagine there are a lot of teams with an app that size you mentioned that are in a hurry to rip out everything they have to replace it with Avo (or any other package or app) in such a short time. Even our customers above are slowly switching from their homegrown admin panel to Avo.
Right now, the UI customization wasn't our main concern. I do want it to look amazing so I work a lot (alongside the designer) to keep it looking excellent. This being Rails, you can always override the partials and view components to add your own and tweak Avo's. The first iteration of UI customization will be to enable the developer to change the colors of the UI.
Regarding general customization, you can already plug in Avo on multiple levels. One can add new fields, sections on resource pages, totally new custom pages, etc.
Multi-tenancy brings a lot of complexity and multiple integrations with various API's also brings that. One of the large barriers for an app that's UI is internal use only is convincing others that we need to spend time on moving away from Active Admin. Its hard to justify.
Down the road if you get into wanting to address internal admin panels in these situations, one idea might be to write a mapper/importer to take active admin DSL code and convert it to similar-ish Avo code. Basic index/show and filter/search pages are like 80% of the use cases and minimizing the amount of time to convert might help you win customers.
Also don't take my comments about UI customization as a critique on the UI, Avo looks awesome. Its just that some organizations (possibly larger orgs) have UI standards defined and making it look like other internal apps is a must have.
The Active Admin to Avo converter sounds like a good idea, and I'll wait until I hear about this request from more users. I use my time where the users need me to use it.
Oh, yeah. No offense taken. Thank you for the compliment!
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
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.
> 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.
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.
> "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"
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.
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.
> 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
Yes, they do intersect in some areas as you can build CRUD UIs with both. Avo takes it further to give it a nicely designed UI, all the "missing" features like extending the interface, adding custom content, supporting all associations thoroughly and more.
I think of it like the next iteration of these kinds of tools.
Yeah, I've used Administrate a bunch. All those things are possible in Administrate as it generates controllers that can be customized, so anything it doesn't do out of the box can be added easily. It's also easy to define custom input types and content types.
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.
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 haven't used motor admin extensively so I couldn't speak about it's features very precise. It seems to me that motor admin is like a giving a power tool to your end-users. It's empowering the citizen-developer. They can make their own admin panel. You might end up with a good product, but it also can go the other way and build something not that good.
With Avo, you, the developer, draw the lines on what the user can and can't do. This way you make sure you give them the best experience.
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.
Any similar back office projects written in python? I'd like to reuse some existing data access code and I'm currently looking at using django. So I'd love to hear if others have a better suggestion.
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.
The barrier that I'm trying to break and push through is that the result is not a hidden away admin panel where only a small number of core team members go to update some record. The result is a beautiful consumer-ready interface that you give to your user.
Avo is your app. Not a part of your app. Avo is the UI your users see when they go and interact with it.
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.
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!
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).
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.
I found the video to be dishonest. "Watch Adrian build a booking app in less than an hour" is the title but if you actually watch any part it's clear that it's at best going at 2x the speed. Probably more like 10x honestly.
The real-time building of the app was an hour and 10 minutes. I posted a screenshot with the recording below. That recording contains also some setup on my part, it's not just actual coding on the app.
The 10x speed-ups were actually data-entry which definitely nobody wants to see in real-time or would benefit from.
The 2x-3x speed-ups were for the generators and slow typing speeds.
I know the tendency is to exaggerate things, but I'm not for that. I like honesty because it's not complicated. When one lies they have to keep that in memory for the next time :P
So yeah, the video is sped up, but the message is correct.
If it is about the video on the homepage of the product, I just check it as it is a video with a total length of 15 minutes.
It includes also an explanation of the problem he tries to solve. I really don't find it dishonest.
I am not sure what speed is the code writing presented (could be 2x like you say) but really for me, it feels like knowing how to use Avo one could write that code in under 1 hour.
Me, together with my brother, built basetool, which should have been Avo but for TypeScript (framework agnostic). You give it a database URL and it will build the admin panel for you.
Today was the day that I decided to sunset it, but you could try to use it with docker or compile it from source.
why dont you put it up on codecanyon as a theme sale ? you can still keep it open source...but this is quite good a tool. maybe you will discover the niche ?
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.
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.
As a disclaimer, I've done PHP (WP, Laravel, custom), Javascript (Node, JS, TS, back-end, front-end, full-stack) and Ruby, so I'm speaking from my experience.
* https://bullettrain.co - Opensource, $0/year
* https://jumpstartrails.com - Opencore, $249/year
* https://www.bootrails.com - Closed source, ~$83/year
I've even started to piece on together for my own projects at https://github.com/rocketshipio/monolith, which will be open source, $0, and MIT licensed.
Some of the libraries I'm noticing that seem "settled" include:
* Devise for authentication
* Pundit for authorization
I started to piece on together for my own projects at https://github.com/rocketshipio/monolith, which will be open source, $0, and MIT licensed.
I'm hoping enough people converge around any one of these products where we end up with something as high quality as Rails. If the community agrees on how users, authorization, subscriptions, etc. should be modeled, it opens up the door for a set of APIs and plugins that will make creating SaaS products even easier.
My thinking on the economics of this is the Opencore stuff will be a race to the bottom in terms of pricing towards free or a nominal fee (I guess $250/year is that). What will end up costing money is tech support. I do see an ecosystem of third-party services that integrate with SaaS kits emerging, such as rapid ways to deploy, analytics services, etc.