Send me a DM on Twitter :)

Hey Nonso Amadi,

Thanks for your questions.

1. Usually, systems don't start with a large scale. You slowly build them, going step-by-step. It's important to turn big decisions into tiny deployable pieces. Change -> Deploy -> Monitor -> Iterate. If you follow this rule of thumb, it's easy to rollback wrong decisions.

2. First, focus on open source projects that you use and well familiar with. Second, look for issues labeled with "good first issue". Usually, these issues will help you onboard and learn the codebase.

3. Be open-minded and constantly learn. DevOps engineers have a great responsibility and in many companies, they're the architecture leaders.

4. Unlike frontend engineers, DevOps engineers can't proudly show their projects. My advice is to write blogs and contribute to open source projects.

Ido Shamun Thank you very much for this. I really appreciate

Hi Girish Patil,

Glad to host you here. Two weeks is exactly the amount of time it took us to launch! We went down the quick and dirty path just to share it with the world. We didn't think about monetization, we didn't crystalize the idea. For a long time, I had a few Slack channels with tons of RSS feeds. At some point, we thought "wouldn't it be great to have a tool exactly for this?". We proceeded with building a prototype and launched it immediately. From there we navigated mainly by listening to our users. This is the only thing we cared about.

I myself a self-taught developer, I never worked in an enterprise before, and never faced a massive scale. I learn what I need on the go. I do many mistakes and fix them along the way. The most important thing is to keep learning, especially from other developers. Look at open source projects to see how they face scale challenges, read blogs about DevOps and architecture. Be curious, for example, have you ever wondered how the Twitter feed works? There is much information about it online and you can learn so much from it. As in everything, Google is your best friend 😉

And on a personal note, I'm available if you have any questions.

Hey Omotola Shogunle,

Thanks for dedicating your time 🙏

1. The best tip about scalability is don't over-engineer. It's super hard to scale an over-engineered system. Keep everything simple. The second tip is monitoring. You will never know it's time to scale if you don't monitor. Set up proper alerting and dashboards to understand when your system misbehaves. Start changing the architecture slowly when you see that it cannot serve your users well. Don't do premature decisions, they will not help you and might stall you. Message queues such as Redis, Google Pub/Sub, Kafka, Rabbit MQ are the best design pattern for handling scalability I think. Use them wisely and they will be your best friend.

2. Spread your word. Be active on Twitter, write blogs, make your repo accessible to others by documenting everything. The repo should be inviting and help new devs get on board and contribute. You have to embrace the Developers Relation domain

Thank you so much Ido Shamun

Hi Victoria Lo,

It's great to hear that you are a fan! I saw one of your articles on daily.dev recently, so awesome!

1. We decided to turn daily.dev into a startup, once we felt that we achieved "product-market-fit". Meaning that our product delivers value to our users (devs). We could literally feel the passion of our users and we could not let them down.
2. Once you understand you provide value to someone and have a decent amount of users this is the right time. Of course, it depends on your financial abilities. You can also go from a side-project to a part-time gig and then to a full-time startup.
3. The inspiration was the pain of discovering dev news through so many blogs and publications. I used to have many Slack channels with lots of RSS feeds. I divided them by frontend, backend, machine learning, etc.

Thanks so much for seeing my article and for the reply Ido Shamun! It's super helpful and your journey is inspiring :)

Thank you Victoria Lo!

Hey Mark,

Glad to have your here ☺️ You are most definitely right, monetization is super hard. Our main revenue stream is ads and it's going pretty neat. Our revenue is high enough to cover all the IT costs, marketing, community gigs, and some pocket money. It's not enough to make our livings, but it's ok for now. We've turned down an investment because we would like to navigate this product by ourselves at the moment.

We believe that once we achieve a critical mass of users we will be more attractive for advertisers and can convert more users to the premium subscriptions.

Thanks for the update and quick reply. I'll be sure to keep an eye on this thread. Looking for the same issue. Bumped into your thread. Thanks for creating it. Looking forward for solution. myprepaidcenter.com

Hey Apoorv Tyagi,

Thanks for the question. Right now we are only the founding team (3 members), the tech team is only me. But once we recruit devs I will look for the passion to learn. Devs with a passion to learn with the right guidance can do everything. You are definitely right that team is the most important piece in the puzzle.

Mainly Nodejs and Vue. Everything is hosted on Google Cloud and we use Postgres as a database. There is an architecture and stack chapter in our docs, feel free to check it out: github.com/dailydotdev/daily

Corey O'Donnell thanks for using daily.dev and being here 🤩

1. We decided to turn daily.dev into a startup, once we felt that we achieved "product-market-fit". Meaning that our product delivers value to our users (devs). We didn't get an initial investment (and actually turned one down), we currently live on our savings. This is a risk you have to take as a founder if you truly believe in your idea.

2. Growth for sure! It's a constant problem, you never solve it but we're doing our best to keep it going. We found out that writing blogs and community are the best ways to increase our reach. We're also seeing good results from YouTube ads.

3. I would like to say yes, but it's definitely a tricky one!

Hey Annie 🦄⚡,

Glad to have you here 🙏

1. I would probably learn more. I used to rush into building things without thinking. It was great because I learned tons of new things while building and I had projects to be proud of. But sometimes I could use a bit of planning and proper learning to do things the right way. There are some things that can take much more effort to change on the go if you don't get them right at the start. Today, I'm trying to balance between theoretical learning of best practices and hands-on experience.

2. I wouldn't do anything differently but my advice is team, team, and team! Make sure you trust your founders. Ideas tend to change along the way but the team is here to stay. If you can't trust them it will be very hard to move and progress.

Amazing, thank you for your answers Ido Shamun!! (And the other great ones you answered too!)

Howdy Chris Bongers,

Great to have you here 🤩

I thought about scalability from the first days of daily.dev but the architecture was different than now. My rule of thumb is to use managed solutions that don't require massive DevOps efforts or even to use third party services as a whole. For example, we use Superfeedr for subscribing to RSS feeds. I used Google Functions and App Engine (similar to Heroku) at the start. Now, most of the load is handled by Kubernetes which is more oriented to multiple services environment. Again I'm using managed Kubernetes, not my own 😉 Most of the architecture is documented in our GitHub (some of it is a bit outdated) github.com/dailydotdev/daily

Regarding the mobile app, it's not coming anytime soon but we do work on a PWA with mobile support. We're a team of 3 people and I'm the only developer. We're trying to move fast but we have so many things going on. Stay tuned for news 🗞

Ido Shamun Awesome Ido, lovely to see the architecture documented, interesting stuff!

There is a whole community of devs out there, perhaps a open source app hackaton 🔥

Thanks Chris Bongers. Hackathon is a good idea, not necessarily for the whole app buy maybe for some features. We'll have to think about it 😉