Show HN: Avo – Build Ruby on Rails apps faster
avohq.io
avohq.io
* 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.
You've given me some inspiration for my own starter-kit built on FastAPI (trying to capture the magic of Django): https://github.com/tmkontra/fastapi-fullstack-boilerplate
I hope to follow along with your progress and perhaps share ideas/compare notes! Cheers.
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.
Good luck!
https://www.producthunt.com/products/prelang#prelang
previously on HN: https://news.ycombinator.com/item?id=7985162
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'm here to answer all of your questions.
Thank you
Besides, EEEY-vo is more fun to say than UH-vo.
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.
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!
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.
Some did migrations from their own custom admin panels "over a weekend". It's kind of crazy how easy it is to get started.
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.
You also dont have any datetime field types. (edit it appears you do but the docs dont list them on the https://docs.avohq.io/1.0/field-options.html)
Also using the models schema should give you default filtering. Strings should be loose, numbers/enums should be exact, datetime should be ranged.
All attributes should also be default sortable.
The suggested generators for namespaced models ```bin/rails generate avo:resource Cms::Page``` dont seam to work.
It feels like its for admin/mgmt stuff but you say its also for normal users and i feel like it under delivers on both.
Hope this feedback helps.
> 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
> You also dont have any datetime field types. (edit it appears you do but the docs dont list them on the https://docs.avohq.io/1.0/field-options.html)
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.
https://calendly.com/adrianthedev
Thank you!
(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 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.
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 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/?
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.
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.
Rails to this day can't be beat, and I don't even ruby that much.
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
I'd love talk to you if you ever want to try it out.
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.
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.
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.
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?
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.
Avo is ready for customization complexity.
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.
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
Yes, it's hosted in the US.
Thank you for that and unploy. I'll have a look.
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.
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.
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!
I agree 100% with your statement! Really!
Thank you!
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.
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."
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
I think of it like the next iteration of these kinds of tools.
Have you built something using administrate?
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.
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.
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.
It reminds me of Bullettrain: https://bullettrain.co/
Disclaimer: I'm one of the authors.
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!
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.
Thank you for the message.
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.
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.
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.
https://share.cleanshot.com/hPUskT
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.
Unfortunately not all of us are on ruby...but everyone is on js. Would totally love something like this on React/Next.
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.
if people dont like something, they can of course refund
This is such an interesting statement.
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.
Also, I think you could make some sort of adapter between the two. Pundit is mostly a Ruby class.
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!
Let the doubters doubt...