Show HN: Avo – Build Ruby on Rails apps faster
71–80 of 171 posts
Re: Show HN: Avo – Build Ruby on Rails apps faster
#72This 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 prob…
> 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…
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.
Re: Show HN: Avo – Build Ruby on Rails apps faster
#73Re: Show HN: Avo – Build Ruby on Rails apps faster
#74Very glad to see this, I’m currently building a SaaS with Rails and can totally use this for our admin panel.
Re: Show HN: Avo – Build Ruby on Rails apps faster
#75Earlier quoted context omitted.
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…
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.
Re: Show HN: Avo – Build Ruby on Rails apps faster
#76Re: Show HN: Avo – Build Ruby on Rails apps faster
#77This 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 prob…
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.
"Listen to your customers and push out the features they need, not the features you think they need."
Re: Show HN: Avo – Build Ruby on Rails apps faster
#78My 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
Re: Show HN: Avo – Build Ruby on Rails apps faster
#79Earlier quoted context omitted.
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…
But you dont say how much the subscription is.
Re: Show HN: Avo – Build Ruby on Rails apps faster
#80Earlier quoted context omitted.
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…
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…
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.