Dashbird's Lessons Learned from Launching a SaaS Application

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 into 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)

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 come out and support is ready to answer any questions.

Dmitrijs (Software Architect)

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 develeopment 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)

Jelena (Softwaare 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)

Reigo (Softwaare 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)

Alex (Softwaare 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)

Toomas (Softwaare 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. Nevetheless, 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.

Go check out Dashbird’s newly launched features now for free, no credit card required.

A collection of lessons learned at Dashbird after working with 4,000+ customers and 300,000+ Lambda functions

Write for us!

We're looking for developers to share their experience with serverless.

Emails and pull requests welcome!

Start using Dashbird for free!

Failure detection, analytics and visibility for serverless applications in under 5 minutes.

Request Demo