Dashbird’s Lessons Learned from Launching a SaaS Application

Taavi Rehemägi

May 11th, 2020

From the development and operations side, launching a new software application can be quite challenging. Deciding which tools to use, how to organize the task pipeline, managing collaboration among team members, monitoring performance and potential issues after launch, etc. It’s not easy to get it done right.

Dashbird recently went through all of this. Behind the scenes, our amazing development team worked really hard to overcome all challenges and deliver the best value to our users. We decided to organize and share those learnings in this article. We hope it will contribute with ideas for other development teams as well.

Below we share the perspectives from our team members, in no particular order:

Marek (CTO)

We used Feature Flags (a.k.a. Feature Toggles) to manage the development and deployment. This technique required some changes in development mindset and process but proved to be very useful in allowing us to safely deploy new features while having every developer on board with everything. First, we implemented an MVP and gathered feedback, which helped make sure we’re on the right track. Internal communication about exactly what is going to be launched and how features will work in detail is important. That brings more clarity to everyone when the news comes out and support is ready to answer any questions.

Dmitrijs (Software Architect)

We created a check-in plan for the pipeline of tasks, with a toggle to enable new features and disable old ones. We continued to use Jira to handle our development lifecycle. There was a bit of pressure with bug fixes closer to the launch, but nothing extraordinary. The responsibility of making big changes that would affect all customers was high. In future iterations, I would leave the last week to polish the new features and make sure they will deliver the best experience.

Jelena (Software Developer)

To prioritize our tasks, we looked at what would bring the most value to our users. These decisions were made together as a team. I also focused a lot of my time on testing and fixing everything as much as possible, instead of just developing new features leaving broken or unoptimized ones behind. Testing scalability capacity was also very important. We used our own monitoring system extensively for the new features. There was an increase in some metrics, but overall the system handled the load gracefully.

Reigo (Software Developer)

We considered what was really possible to deliver within the timeframe and checked the pace every two weeks to adjust our expectations. We found it was better not to make changes at the last minute or during the launch campaign (apart from bug fixing). Testing everything on the days prior to the launch was fundamental.

Alex (Software Developer)

Marek, our CTO, was maintaining a roadmap of features, which we had decided beforehand. One top priority was to fix existing bugs and make the system as stable as possible. There was a scalability problem in one internal service that is a central part of the system. Improving this service architecture was a priority and paid off well. For me, it didn’t feel like too much pressure. Although I had to put extra effort into my work, it was actually fun fixing different bugs etc. My advice would be to collaborate more and tackle problems together with colleagues. We had some changes from previous month still pending to be pushed into production. In the future, I would push anything pending first, then start working on a new launch version.

Toomas (Software Developer)

We planned our tasks on a weekly basis. Personally, I started the week by selecting the more difficult ones assigned to me. That is because those tasks are harder to estimate, so getting them done early would help identify any deviations from our plans. I was new to the team, so one thing I did was to get familiar with the system and the code already in place, which helped me work with more confidence on the new features. Although I haven’t felt any extraordinary pressure, I see the team accomplished a lot, because everyone was collaborative and motivated to get as much as possible done for the scheduled launch. We didn’t have any major issues after launching. Nevertheless, I would invest more time in testing in future releases.

Dashbird is the most widely adopted serverless monitoring platform, with over 600,000 cloud resources being tracked. It provides observability over several managed services, such as AWS Lambda, SQS, DynamoDB, API Gateway, ECS clusters and containers, and Kinesis streams.

Read our blog

Making serverless applications reliable and bug-free

In this guide, we’ll talk about common problems developers face with serverless applications on AWS and share some practical strategies to help you monitor and manage your applications more effectively.

ANNOUNCEMENT: new pricing and the end of free tier

Today we are announcing a new, updated pricing model and the end of free tier for Dashbird.

4 Tips for AWS Lambda Performance Optimization

In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

Get started free or learn more

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.