Minimum Viable Product (MVP)

Summarized using AI

Build a business on Open Source and Ruby

Adrian Marin • April 26, 2014 • Sofia, Bulgaria

In the talk "Build a business on Open Source and Ruby," Adrian Marin, a self-taught engineer and entrepreneur, shares his journey of developing Avo, an advanced content management system and admin panel framework designed specifically for Ruby on Rails. Initially started as a side project during the COVID-19 pandemic in 2020, Avo has since gained significant traction with over 200 paying customers and a team of three. The talk emphasizes the challenges faced when building a business targeted at developers and the learnings accumulated along the way.

Key Points:
- Personal Introduction: Adrian Marin introduces himself, discussing his background as a self-taught engineer and his passion for product development, design, marketing, and sales.
- Avo's Evolution: Avo started as Project Avocado in response to the limitations of existing admin panel frameworks for Rails. Adrian aimed to create a polished tool to enhance developer productivity.
- Initial Challenges: Despite building a seemingly useful product, Adrian faced significant skepticism from potential users, who were accustomed to free alternatives. This lack of immediate interest tested his resolve.
- Community Engagement: Successful promotion came from community involvement, including participation in conferences and podcasts to raise awareness of Avo.
- Product Development: Adrian shares the importance of adapting his product based on user feedback, particularly after the introduction of Hotwire, which he quickly integrated into Avo.
- Resilience and Support: Acknowledging struggles and the critical support from his spouse and other community members, Adrian emphasizes the need for persistence.
- Financial Milestones: Over time, Avo reached various revenue milestones, eventually achieving a level of profitability allowing him the freedom to make independent development decisions.
- Lessons Learned: Adrian outlines key business takeaways that include starting with a minimum viable product, actively listening to customer feedback, early monetization, and refining marketing efforts to promote the product better.
- Future Outlook: The journey is ongoing, with Adrian encouraging others to engage and share experiences within their communities to foster growth and support.

In conclusion, Adrian's experience underscores that the path to building a successful business in software involves executing ideas, learning from the market, and maintaining a strong connection with the user community. The session inspires developers to overcome hesitation and focus on shipping valuable products to their intended audiences.

Build a business on Open Source and Ruby
Adrian Marin • April 26, 2014 • Sofia, Bulgaria

Adrian Marin is a self-thought engineer and entrepreneur running Avo. Avo started as a side project, and now is a lively project with about 150 paying customers, and more than 400 apps running it in production.

Building a business is not easy. Selling to developers is even harder. Adrian chose the difficult path to do both and he's been lucky enough to survive it.

Balkan Ruby 2024

00:00:00.160 Thank you. Hey everyone! Cool, I wanted to say something in Bulgarian, but I apologize I'm not that well-versed. Bulgaria is very close to me, and not just geographically, but also close to my heart because my family and I vacation and visit quite a lot. So being here and speaking to you guys is quite special. Thank you. The original title of the talk was 'How to Build a Business on Rails or Ruby on Open Source', but there is no recipe for that, so I'll just tell you how I built a business on Ruby and open source.
00:00:27.000 My name is Adrian. I am a self-taught engineer, which means I didn't go to Computer Science school; I learned it along the way. I am product-oriented, which means that I don't just like to do development, but I also enjoy a bit of design, marketing, and sales. I like to check what other people do and integrate all that work into my products to provide the most value to my customers and users. You can find me as Adrian the dev everywhere, on Twitter, GitHub, and pretty much everywhere else. Avo has been my main business and job for the past three and a half years.
00:01:01.000 In my spare time, I do a tiny podcast with my friend Yaro. You're probably working on the podcast and we're not very professional or anything, but we have great guests and sometimes we're funny. Last year, I organized my own conference called Friendly RB, which will take place in September. So, just about right when you know this Balkan Ruby social juice runs out, you can pop across the border to Bucharest. We're very friendly; a lot of cool people come, and we do nice, friendly activities. We have four announced speakers: Rosa Gutierrez from 37 Signals, Nabila Yup from Factori, Steven Markheim the site guy, and Tom Rossy from BuzzSprout.
00:01:36.000 As a special treat for you guys, I'm going to announce the next speaker, who will be Nate Hopkins, the author of Stimulus Reflex and other Turbo libraries. Yes, I'm very excited to host him. The call for papers is open. One of our goals is to bring new talent to the stage to speak. So if you think you have something to teach your peers, definitely apply for the call for papers. If you're very well-versed, we definitely want you as well.
00:02:30.000 For those of you who don't know what Avo is, it's an advanced content management system, admin panel framework, and internal tool builder for Ruby on Rails. It helps developers build Rails apps and graphical user interfaces very fast, faster than traditional methods. I'm going to speak a little bit about the story of Avo because it makes sense in the grand scheme of things, and then we're going to talk about a few tips and tricks and what we did right or wrong along the way. One question I get a lot is: how did I get to build Avo?
00:03:03.000 For those English-speaking folks out there, it's pronounced Avo, like avocado, not 'A-O.' It was initially called Project Avocado, but I couldn't find any usernames or domain names, so I just used Avo. So how did it start? It's not a novel idea; I come from PHP and Laravel. Back in the day, I used Laravel Nova, which is an admin panel framework for Laravel. We were able to deploy our internal tools very quickly, allowing me to focus on the more unique aspects of the business, rather than the mundane tasks.
00:04:31.040 I thought to myself, 'If we had something like that polished inside Rails, because Rails already helps you build apps super fast, this would make it the best framework out there.' I did some research and found a couple of alternatives like Active Admin, Rails Admin, Administrate, Trestle, and others, but each of them had their disadvantages. Now, this is a disclaimer: me talking about those disadvantages is not bashing them; they were around before Avo, before Nova. They set the groundwork and I'm grateful for that. But they were built with different contexts, different technologies, and probably different goals in mind.
00:05:57.640 Some of them felt a little unmaintained or unpolished, and the developer experience was not great. So I got started. I didn't aim to build a business; frankly, I'm a developer and I just wanted to see if I could build it. I started in the spring of 2020, probably around the time everyone remembers for COVID.
00:06:17.040 I built Avo as a side project. I worked throughout the spring and summer, and in August I had a gem file and started telling people about it, saying: 'Just look at this conversation; it's super easy to use, just follow the docs.' I was so naive, just that guy that built something cool and wondered why everyone wouldn't want to use it. The next two months shifted from me telling people about my product to begging people to use my product. Most people I talked to would say things like, 'Nobody is paying for anything like this. This is not going to work,' or 'We have Active Admin, and that's free. Why would we pay for your tool?'
00:07:30.200 Or simply say, 'Oh, this is like PHP my admin.' I was frustrated. Nobody understood my tool; this is not something you build like a half-assed ugly admin panel. This is a tool where you can bring your whole team to work productively. It should work well, look nice, support advanced use cases, and be ready to deploy to your consumers from day one. I kept working. I hung on to every bit of promotion I could without being spammy or sleazy. For example, Planet Ruby did an advent calendar in December where each day they would highlight one gem, and day 15 was for Avo.
00:09:10.720 Jason Charles once said on his podcast, 'I don't have anything to talk about,' and when I told him about Avo, he gave it a shout out on the podcast. Whenever somebody asked about who’s building something cool with Ruby, I'd be there promoting Avo. I reached out to like 10 or 15 podcast producers asking them to have me on their shows. Jason Swift was one of the first big Ruby podcasters that had me on, and I'll forever be thankful for that.
00:09:57.360 This is my call to action to you: if you're someone with influence in the community and you see someone building something cool and passionate about it, help them out. Give them a shout out and tell people about their product; they'll forever thank you for it. Somewhere around the end of 2020, DHH released Hotwire. It was a cool way of building user interfaces with Rails. I was a bit hesitant about changing my Vue.js single-page application back to this new thing. But just a week after Hotwire was released, someone on Twitter came to me and said, 'I’ll never use your tool because it doesn’t use Hotwire. Hotwire is the best, and you should use it!'
00:11:14.720 And guess what I said to myself? 'I’ll show that stranger who didn’t pay $99 for my tool that I can rewrite it all.' And I did just that. I was able to become one of the first medium-sized products that used Hotwire less than three months after its release. A few months went by, and we got our first customer. In the first year, I almost abandoned the project, as I was chasing the VC dream. That didn't work out for me, but during that year, people started picking it up, using it, and paying for it. They started requesting features, and I thought, 'Wait a minute, if they want it, if they use it, maybe there’s something here.' So I started working more on it.
00:12:54.320 By the end of 2021, I made $4,000. Wait a minute, it was just enough to pay for my taxes and my accountant. So I worked a little, released version two with more features, and introduced a subscription model. The next two years set the tone for releases every two weeks, and I aimed to bring substantial improvements with each release. I still wanted Avo to get more traction in the community, but those years were pretty tough. I was always wondering if I was doing the right thing. I could get a job and make so much money; am I wasting my time? Am I hurting my family in the process? It was very challenging.
00:13:54.720 They say that the second most important decision in your life is choosing your co-founder. The most important decision is choosing your life partner. My wife was very supportive of me, and I thank her every day for pushing me to keep going, as she saw the value in my work. I also had some calls with Mike Perham, who said the same thing: 'Just keep going; provide value and utilize your strengths.' He pointed out that living in Eastern Europe, with a lower cost of living, gives me a longer runway than anyone else from the States. So I did just that; I worked on a reduced income and used my savings until the product took off.
00:15:22.480 I had a few conversations with Nick, who told me, 'Never sell, brother; just do it. Just continue.' Sometimes I wanted to quit; I just wanted to give up. But then I had a sale, which led to another sale, and then I had the best month, followed by another best month. When you're building a product and a business, it's not just about watching some chart grow; very few people see the growth and patterns clearly. We started gathering fans and evangelists, reaching out and telling us how amazing it was and how much value it was bringing them. This encouraged us to keep going.
00:16:46.680 This is how I met Paul; he was working at a company that was using Avo. We started speaking and he shared features he would like to have or tweaks he made, and as we became friends, I learned he was also from Romania. At some point, Paul expressed wanting to find a second job to improve his income, but I couldn’t think of hiring anyone as I was struggling myself. However, I offered him a chance to work with me part-time. My biggest customer was paying me about $500 per month to be on his Slack channel and write some Avo code for him. I took most of that money and gave it to Paul. That's how Paul became the first Avo employee.
00:18:03.760 It's not a glorious story; it's a story of struggle and resilience. I did what I had to do to get my product going. By the end of 2022, we made $24,000, which was kind of like the ramen profitability level we were aiming for. It was a salary but still okay, as I had my product and freedom to make development decisions. We were actively involved in our Discord and GitHub repo for support. Then in 2023, we launched Avo 3, improving the API to support more use cases. That's when Paul became a full-time employee, taking even more work off my hands, so I could focus on sales, marketing, and thinking about the future.
00:19:53.720 By the end of 2023, we made $64,000, enough to cover two modest salaries. But we were making an impact; we were delivering value and building a business. Last year, I went on a conference tour, attending and speaking at various conferences. This led me to host my own conference in Bucharest. This tour wasn't just for promoting my product; it was to connect and understand my community since these are the people who will buy or recommend my product. I thank my wife and my community, but there's one unsung hero in this journey, and that's Rails. Avo wouldn't have worked if Rails didn't have its conventions. That's how Avo knows how to communicate with the database and the controllers.
00:21:57.280 Today, we are a team of three, with Gabriel being the junior Ruby developer we hired. We now have a respectable monthly recurring revenue and about 200 paying customers, along with a clear path forward. We've seen people build Shopify alternatives, fintech solutions, inventory and security apps, and entire healthcare CRMs using Avo. The market has shown us that Rails and Ruby have the maturity to handle something like this. This is the story of Avo and how we came to be. In preparation for this talk, I asked people what they wanted to know from our story. Common questions were about getting started and transitioning from part-time to full-time involvement.
00:23:24.000 So let's take it one step at a time and see what we did right or wrong. First of all, you need to have an idea. Instead of thinking about having an idea, focus on identifying a problem that a segment of users face. Ideally, that problem should be painful. Think of your solution as a painkiller or vitamin. People would pay anything to alleviate their pains, but they might skimp on vitamins, and it’s the same with software. Start talking to potential customers about the problem. Friends and family don't count; they’ll usually provide bad feedback since they don't have the same problem. You need to search for those who do.
00:25:12.080 Once you have an idea, you should build the MVP — the simplest thing you could create. It might even have plenty of manual processes, but that MVP should give you the best idea if you should continue with your product. Start small; no fancy automation or designs needed. Just put it out there, and your customers will tell you what features they need. Did we do this right? Not really; I built it hoping they would come. So you should find your users. My biggest mistake was just building it, thinking customers would come for it, but they didn’t.
00:26:20.000 If you’ve done research on the problem, you should have some idea where those users are. It may be challenging to reach them, but you should at least have an idea. There's a famous tweet from Daniel Vassallo that resonates with many developers; we often get bogged down with dark mode, favicons, and other minor things, which you can postpone after launching. What's crucial is bringing users to your product so you can figure things out. Now that you have some users, you have to listen to them. They’ll communicate what’s missing or what’s unnecessary, helping you iterate on your product.
00:27:45.000 The best indicator of whether your product solves a problem is money. Paying customers are the only true validation that your product addresses a painful issue. So, begin charging as early as possible, and once your product proves its value, increase the prices accordingly. This can be daunting and might feel like you’re losing customers, but it’s a necessary leap of faith. Did we do this right? Yes! We charged from day one and continuously iterated on our pricing. Make a reasonable roadmap and try to stick with it.
00:28:42.360 I started knowing what Avo should be in two to three years, and we kind of reached that goal. However, getting there was different than I anticipated. We observed how big companies set their roadmaps for six months or three years and attempted to do the same, yet that strategy might not work for you. Set goals and strive to follow them; this is immensely beneficial, even if you are flexible. If you planned to build feature A, B, and C, but a customer urgently needs feature C, go ahead and build it!
00:29:54.000 Serving your customers and adding value is the most crucial thing. Our friends at UserList have a great quote: 'Better done than perfect.' When people ask me how to get started, especially developers, I say, 'Do rails new and deploy the first day.' It can be just a blank page, but you need to start writing code and deploying immediately. By the time you know it, you’ll have something valuable to show others, and you’ll receive quick feedback. So, don’t build something in the dark; that perfect project you're working on may never launch.
00:31:21.680 Did we execute this correctly? Recently, we set a Q1 milestone but realized we couldn't deliver because our customers required something else. I think we’re doing okay. Show up, and show you care. When we receive a GitHub issue or someone experiences a problem, we respond quickly. Acknowledging their concerns builds trust. Sometimes, developers might not want to engage with robots, so showcasing your personality can help. Showing your face, how you talk, and how you smile makes a difference.
00:32:41.820 Now, I did it the hard way; I quit my job and began working on this full-time. You might work on something part-time, and at some point, it may sustain you full-time. When you make that transition, inform your customers and potential customers. They want to know that the most significant thing you do professionally is this. It builds more trust.
00:34:02.000 Branding is essential. As developers, we sometimes throw a Bootstrap theme on our product and call it done. But having a proper logo, colors, and a solid way of communicating about your product shows you care. Invest in a designer, or spend a small amount to get a logo done right. Once you have stickers and merchandise, everything becomes more real.
00:35:20.760 Marketing is crucial as well. I know developers often see it as dirty, but customers need to find out about your product, and the only way to do that is to tell them. You should create a funnel: customers searching for solutions analyze them, then buy your solution. This funnel should be replicable and scalable, so if you put more money in, you'll attract more customers. Did we do this right? No, we struggled with marketing and simply didn't enjoy it.
00:36:58.880 But you’ll have to embrace it at some point as that’s key to growth. When I see someone building something cool online, I reach out to them for a chat. It’s interesting to hear about their motivations and driving forces.
00:38:47.080 These interactions often make it easier to build trust and connections. Eventually, delivering product value and showing up is crucial. If I had not spoken with Mike Perham, Nick, and others in the community, I might have given up. Building relationships helps to get you through tough times. So once you’re established, make an effort to help others. Share your experiences by speaking at meetups and conferences, or starting a blog. Be honest about your successes and failures; cultivating that trust will reflect positively on your business.
00:40:31.760 As a founder, you’re going to juggle many responsibilities. This is not a standard 9-to-5 job where you shut off after hours. Marketing is challenging, as is sales and copywriting. You’ll have to navigate these tasks. The only way to build something significant is to show up daily and do the work.
00:41:35.120 As engineers, we often assume every decision should be purely rational. However, sometimes you must trust your gut feeling. It’s important not to compare ourselves too harshly to yesterday’s startups or their methods. Instead, observe and learn from what they did when they were in a position similar to yours.
00:42:40.320 One mistake was taking things personally. Sometimes someone on Discord would complain about our product: 'It doesn't do this or that!' I would feel defensive, thinking, 'How can they complain? They're paying so little!' However, I needed to read between the lines and acknowledge their feedback as valid points to improve upon.
00:43:55.440 Pricing is another challenging area. Many companies set flat rates, often per user per month, and may include an enterprise plan. We're still figuring out our pricing model. It's not fair that a company paying you a single fee receives the same service as an enterprise company that may gain thousands in value from it. This distinction can be challenging to discern purely through features. Thus, you should continuously iterate on your pricing.
00:45:57.600 If there’s one thing to take away from this talk, it's that you have the power and ability to build the product and business you desire; alternatively, you also possess the choice to not execute it. Execution is key. The opposite of execution is doubt, hesitation, delay, or failure to ship. Not executing is the biggest mistake you can make. So please, go out there and ship something people want. Thank you.
Explore all talks recorded at Balkan Ruby 2024
+5