Lessons Learned in SaaS Development

We have been working on EDMdesigner since 2013. Development technologies and methodologies have evolved a lot during the past years. Some of them we adopted, some of them we did not, for various reasons.

One thing is for sure: compared to where we were at the beginning, we are a professional team now. We are continuously improving ourselves in many, many things related to software development.

We have reached a level where our experience might be interesting to others. That is why we decided to share a wide spectrum of the lessons we have learned in software development so far.

I'm sure that these articles will help fellow SaaS developers and CTOs in their work. If you are interested in the upcoming chapters of this series, please subscribe to our newsletter below.

The Story of EDMdesigner in a Nutshell

Before jumping into the details, let me tell you the story of our company — EDMdesigner — in a few sentences. It will help you to put everything in context.

The whole thing started at the beginning of 2013, when we dropped our third business idea, because we realized that it would not have a chance on the market.

We had gained experience in creating drag-and-drop interfaces already, so we wanted to use that knowledge. The problem was that the most obvious thing to do (a website editor) already existed. Well, there were plenty of them, so we decided not to go in that direction.

One day, my co-founder Roland called me and said:

"What about an email editor? Coders are suffering with email coding."

Wow! That sounded like a serious issue to solve, so we started to work on the solution. A little bit later, we found our third co-founder Greg, who helped us with email coding and CSS magic.

We raised funds from a local VC successfully and started to work on a stand-alone email editor tool. Despite the hard work, we could not attract enough end-users, but at least we had some paying customers.

After a while, some of the users who were testing our email editor started to ask if it would be possible to integrate it into their system. And it happened again... and again... After a while we decided to pivot to that direction.

EDMdesigner turned into a B2B integration business. Our main customers are Email Service Providers and marketing automation companies, who need a drag-and-drop email editor software component in their systems.

Today, we have customers from all over the world and millions of people read emails which were created with our email editor.

We won't stop here. We are working on the next generation of our software components which we are going to release later this year. It is going to be a set of components helping email companies, not only an email editor. Stay tuned!

Experience We Gained

As you might have guessed from the previous chapter, the most experience we have gained is related to developing highly customizable white-label software components for integration. It means that a publisher can use our software components as a part of their own product.

In the following sub-section I'm trying to focus on what we are really good at, the areas we still need to improve and those which we are working on already.

Code & Project Management

Image source: Backlogtool.com

One of the most fundamental things we learned is organizing our code base clearly. Using the appropriate abstraction is very important, but you have to be careful not to over-abstract. Using programming patterns and clear code structure can help you a lot to code effectively.

Also, it's very important to have a strict but flexible code management process. Proper tooling and versioning is the key. There are also many best practices in this area, which we will share in a later post.

Besides the topics above, project management is also crucial. Without appropriate project management, you probably will not release your software any time soon. Throughout the lifespan of our company, we have tried out some methodologies, but to be honest we still have room for improvement. Anyways, this story also might be useful for lot of teams like us.

DevOps & Infrastructure

Image source: Networkworld.com

We used to host our application, blog and everything else on AppFog, and we moved to Nodejitsu later. Honestly, we did not have enough control over our own system. That is why we moved to AWS EC2.

Later, we started to explore other opportunities in the AWS world. Now, we use EC2, Lambda, S3, CloudFront, Route53 and many more.

In the meanwhile, we have started to use docker, and we introduced CI (continuous integration) for all of our repositories. It sped up our software development and deployment processes radically.

Although our processes have been improved and our applications and APIs became very robust, we became too supplier-dependent. Our whole infrastructure works on AWS at the moment.

Remember the recent AWS service distruption?Various services in an entire AWS region went down. You guessed it, most of our stuff is in that region. Our customers bombarded us with emails demanding answers.

This event made us think seriously about fallbacks and robustness. At the moment, we are working on a multi-data-center and multi-infrastructure-provider solution, which will help us to sleep better at night.

We already have various fallback options, but we are reformulating our disaster recovery plans, to make sure that even if everything goes wrong, the service can continue to work with minimal downtime.

Server- & Client-Side APIs

Image source: XDA-developers.com

Since we sell software components, we gained lot of experience creating APIs both on the server and the client side. We made several mistakes from which we tried to learn and improve ourselves. There is still room for improvement, but we reached a level where our experience could be interesting for others.

Our first APIs evolved totally randomly. I could say that it was built in a startup style. We put the functionality in it as quickly as we could so we could make our clients happy. It helped us to survive, but after a while it became harder and harder to maintain our codebase.

Although these quick feature developments helped some of our clients, it came out that it was hard to integrate for lot of other teams. It is fundamental to create an API that is easy to understand and use.

At the beginning, everything had to be configured on the backend. For example if you wanted to change the color scheme of the editor, you had to make API calls. We thought that it's best if we create a dashboard where they can do the basic modifications without having to use our API. Well, it worked fine for them, but it became cumbersome for us.

Now, we are moving most of our APIs from the server side to the client side. When they initialize our plugins, they can do the configuration on the spot. These things were done through API calls or on our dashboard. It is much, much easier to test the new features and to integrate these software components if you do it on the client side.

Even if a plugin needs communication with the backend, we hide it. Our integration partners will not need to take care of it any more. I am very excited about these new plugins; hopefully we can release all of them in this autumn.

Summary

In this introductory article I highlighted some of the topics you will be able to read about in our SaaS development related article series. I know that I did not go into details; I just wanted to give you a picture about what to expect in the upcoming chapters.

These articles are going to cover everything we learned related to software development. Don't think only about coding. We are going to cover much more, for example versioning, workflows or project management. But of course, we are going to share insights about how to create white label software components, which are easy to integrate.

I hope you will enjoy these articles. If you don't want to miss the next one please subscribe to our newsletter.

Do you have any topics in mind which you would like us to write about? Tell us in a comment! We would love to hear about your ideas.