Learn how startup founders tackle painful tech challenges, from microservices to security, with insights from Frontegg CEO Sagi Rodin.
Awesome. Hello, everybody. So I think we have quite a lot of participants here. So thanks a lot for joining. I see a lot of founders and CEOs, and I see CTOs and I also see people from Frontegg, which is always great to see friendly faces.
So I think that we’re good to start. And let’s start a bit about me so you understand who am I. So my name is Sagi. I’m coming from a background of pretty much 20 years of software development. So I’ve been developing mostly web since I was about 15 years old.
And I moved pretty quickly to managing R&D teams in different constellations. Had opportunity to work in several startups and to manage the development over there. It was always in the world of SaaS, even before it was called like that, but also had the opportunity to do some consumer-based applications and some other interesting stuff.
And before founding Frontegg, which we will get to later, I served as director of cloud and SaaS products within Check Point. If there’s anybody here who hadn’t heard about Check Point, so it’s the largest Israeli company overall, and, of course, a huge technological hub.
They invented the firewall. And so I joined Check Point in 2015 and served in different roles. And in the last role, I had the opportunity to manage the SaaS platform over there.
So actually, I created a SaaS platform over there and then get to manage it. In the top, there were about 60 employees working in my area under my supervision. And we had the chance to release several SaaS products within that platform. So fast forward to 2019.
By the end of 2019, we founded Frontegg together with Aviad, who’s also in the audience here. And you will get the chance also to have some discussion with him about really deep technical stuff. But in Frontegg, basically, we created a platform that enables self-service within SaaS products, which basically some call us SaaS for Saas.
Some say that we’re like Stripe but for enterprise capabilities for SaaS products. But this is what we do. So we launched our product six months ago, and since then, having quite a lot of business enabling SaaS where critical infrastructure.
And we will see soon that some of the topics that we will cover come from my experience and Aviad’s experience and the whole team as to what are big challenges, what are the big stones that we have to cover once we are creating a product, launching a product from the beginning? I’m also a father of three as of a few days ago.
So I had my baby girl born last Friday. So that’s exciting as well. And I also love cooking. And as you can see behind me, I also play the piano. So that’s a bit about me. Now a bit about this talk.
So we’re going to cover some technical challenges, and we will talk about cloud application, about SaaS applications. And I wish it would be more of a discussion. So I will cover some topics. Some of them are very deep technical topics. Some of them relate more to customer experience and to product development.
But, you know, you can just raise your hand and get on the stage and ask your questions and maybe share a bit about what are your challenges. So actually in the last part, we have a dedicated time for that when I wish we could discuss a bit about the challenges that you have within your organization, creating your first versions of product or even later versions that maybe we can even learn from your experience on what were your challenges.
So without further ado, let’s jump to the discussion. Unless anybody has any question, you can comment or as mentioned you can get to me. Cool. So let’s start with it. Innovating is hard, right?
When you get into an organization that already has an infrastructure that already has a product, you kind of say, “Okay, somebody else have set the big stone. Somebody has handled all the infrastructure, and now all I have to do is come and develop on top of it.”
But when creating something from scratch, you know, that’s difficult. You need to make the decisions. Nobody will make them for you. And once you are launching a startup, a company along with this decision, you have a lot of responsibilities, right, because your decisions affect not only potential customers but they will also affect your employees, right?
You’re hiring employees, and they’re affecting your family. So I think that making these crucial decisions has a lot of difficulty, a lot of challenge, a lot of stress around that. And when you are a startup, whether you are bootstrapped or whether you are funded, in early stages, there’s also a lot of pressure to get the first business and to develop your first version of the product because your investors are looking at you and everybody else are looking at you, and there’s a lot of tension around that as well.
So we have to deliver, and we have to do it fast, but we also have a lot of responsibility of doing it right because otherwise bad things will happen. So when talking to developers, from researchers, what we see is that 75% of developers, they say that they’re constantly debugging stuff.
And this happens a lot in the early days when still didn’t have the chance to do stabilization screens. Everything is built on top of each other. Everything feels very patchy. So there’s a lot of debugging going on. Also, developers say that 60% of the time they’re worried about security. And here we’re asking CTOs, you know, the ones that are really responsible of the hard decisions what they are worried about and they’re saying, “We’re worried about security because what will happen if something will…you know, somebody will burst into our environment and start to play with our users and start to do some really nasty stuff?”
So that’s really… You know, when we ask CTOs why they don’t sleep at night, that’s what they tell us. And a new thing that we’re starting to hear is that a lot of them complain about dealing with non-core aspect of building their product.
And, you know, non-core might include some features that are non-core, management features authentication, for example, onboarding guide and billing and stuff like that. But non-core may also involve stuff like going through your logs on the backend, dealing with compliance, and so on and so forth.
So when we ask the real decision-makers what makes them not sleep at night, this is the type of things that we hear. Now, what does a CTO founder or technical founder, what they really want? So they want to build an amazing product, right? We’re in the age of product-led roles so everything is about how good and how smooth and comfortable and how great is the experience within your product.
We want to build a great team. You know, it’s hard to hire people. We all know. A startup also has the limitation of the budget. So we want to create a great team, and we want to move fast. And, of course, we want to sell and become billionaires. I don’t know.
I guess I’m kidding. Maybe, maybe not, but at the end of the day, we want success. Right? So I think that this is true for all founders. I think that on most of the organization, on the type of organizations that we see, and I would guess without even looking at the websites of the companies, of your companies, I guess that, you know, most of you coming from a really technical, heavy, technology-oriented startups, this is what we’re dealing with.
And most of the team is R&D, especially in the beginning. We’re dealing with engineers, we’re dealing with DevOps engineers, we’re dealing with quality assurance people. So we want to create a great team, want to move fast, build a foundation that will allow us to move fast and to make a great product out of it, release it, have it be self-served so, you know, people can just sign up and grow the usage on their own, right?
We don’t want any operations on our hand. So this is kind of what the CEO or the technical founder wants. Now, it sounds pretty legit, right? This is what we want. What is the problem of getting there? Right?
So we have several things that have to do with, you know, why CTOs lose sleep overnight, right? So we want to deliver the product in a wise manner, right? We want to make stronger architectural decisions, build a strong foundation that will last not only for the POC stage but, you know, hopefully, when we grow.
We want to be secure, right? So how do we address this application security in a startup? Do we invest even in security, or do we maybe leave it for a later stage? And as mentioned, we want to deliver fast. So how do we produce this velocity by creating the foundations, the engineering processes around that?
What kind of methods can we embrace that will allow us to move faster than our competition, faster than others? And these I think are the main challenges of actually getting to solve the problems or challenges that I described earlier.
So on the research that was made, you know, they were asked, startup founders, of what are their main challenges. We can see that a lot of that was around funding, and some of that was around building the business model and hiring.
But the main part of it was around building the functioning product, right? And sometimes it seems maybe a bit surprised, right, because we get to this… We go through this journey because we think that we’re able to innovate with the most amazing product we have in our minds.
We did the sketches and everything, but when it gets to reality, it’s really hard for us to build a great product. And then the frustration starts because, you know, if the product is the backbone to the whole business, especially in the age of product-led growth, then I guess we’re in trouble if that doesn’t work well, right, because then we cannot talk about funding.
We cannot hire great people because we don’t have the funding. Customers will not come or we will be stuck in the design partner stage, and that’s a big problem. So there is some kind of chasm happening in how we take an idea in our mind and turn it into an actual product. So we try to gather, and these are the things that I will cover in this presentation with most of the things here is some of the top questions that a CTO should ask when going into building the foundation, the technical foundation of a SaaS application.
So we’re going to cover microservices. What are microservices? Should we even think of microservices? Because, you know, microservices, the hype started around five, six years ago. But, you know, some say that you don’t have to build with microservices. Maybe it’s just a hype.
So why jump on it? Do we go cloud agnostic, or do we use all of, what, AWS, Google Cloud, Azure, everything that they have to offer us as a matter of service? Do we build cloud-native? Should we go multi-tenant? Should we focus on security? How much should we focus on security?
And what are the areas that are more important than others when handling the aspect of security within our startup? And last, but not least, should we build or should we buy? When there’s an opportunity to buy a third-party solution, should we buy it or should we put our people in work, because that’s why we’re paying them for, and maybe they should just build everything in-house?
So we will try to cover these questions. Now, some of these are very deep technological aspects, very deep technological questions around them, and we will cover only some of them.
But I would love to hear from you, what is your opinion on that, and whether you are utilizing these aspects within your organization. So I’ll start with a story. About four years ago in my previous company, we wanted to shift, sorry, to a microservice model, or multitenancy, sorry, that’s a mistaking title, to a microservice model.
And we went to this workshop in London, which was quite great. And we learned the 101 on what are microservices and whether we should embrace them. So a bit about what are microservices.
For whoever here developed in the ’90s, there was an approach that was called service-oriented architecture, SOA, and it was quite popular. And at the end of the day, it meant arranging your application in different entities and each entity would be compiled to a different module, and the entities would talk and communicate between each other by queues or by REST APIs and so on and so forth.
So we won’t have all of the applications spitting out under the same code base, but we would separate that. And that would add a lot of advantages to the app that we’ll create. So basically, microservices is the continuation of that, just like in clothes when we have different fashions from the ’70s reappearing again.
Basically, it’s the same manner. Five, six years ago, we saw a great hype around microservices and whether they should be used or embraced within our architecture. So we’re talking about a structural style, an architectural structural style, which means arranging the app as a collection of services that are loosely coupled.
So each and one of those services can run on its own physical environment, but also it can run on the same physical environment and be shared with the other microservices. But the idea is that it’s taking care of its own region, of its own entity, of its own topic if we would like to name it within the whole infrastructure.
So usually we’d have a client, as you can see here, and we have an API gateway that receives all the requests from the client. The client could be a mobile application, it could be a web application. And this API gateway basically receives all the requests.
And then through discovery, we can always point and proxy the request to the relevant microservice. So if we’re doing a request that has to do with users, we will proxy to our users’ microservice. If we’re doing a request that has to do with billing, we will point that to the billing microservice. And in general, it looks and means…like, it can show a lot of sense, right?
We see a lot of sense in that. So what are the process in response of that? So the first big advantage is that we don’t have a single service that if it’s failing, the whole application starts work, right?
Even API gateway today that we see here will be replicated. So it won’t be the single point of failure anymore. But the service itself, for example, if the billing is not working because of a bug that the developer deployed or because we have some internal issue there, it means that only the billing is not working but users can still log in.
They can go through the reports, they can generate dashboards, and so on and so forth. So no single point of failure, which is important in the world of monolith. If, you know, the app is not deployed well or we have a crucial bug there, it can just make the whole thing to crash and we won’t have any contract.
So that’s the first great thing about that. The second thing is the improved deployment. We can deploy… We don’t have to deploy this whole application, which could be a tedious process also on the testing side, right? We have to make this cover all the testing before we deploy the app. We can deploy only the specific, the relevant microservice, which is also great. We’re talking about faster deployment, so we can proceed much faster, right?
We started with a discussion on how we can create an infrastructure that would allow us to move fast. This is one of the things. And scalability. Scalability is also a very important aspect because, as you can imagine, maybe the notification service that receives a lot of push notification needs to handle a lot of scale, a lot of requests in a minute.
You know, when we’re talking about that, it has much more scale to handle than the authentication service that only gets logins from users once every few seconds. So we’re talking about different scales, which means that we can use autoscale that’s covered by the cloud vendors or in our Kubernetes environment, and say that, okay, the heavy load services, it would be replicated, and we can make them much more scalable.
They need to handle a lot more load than the other microservices. So that separation actually allows us to handle these kind of cases. And we’re talking about no technology or vendor locking, why no technology or vendor locking? Because basically, each microservices serves as a unit of its own, which means that this microservice can also be written in its own language, in its own framework.
It can use a different database. And it is great because then, you know, we can have developers that have different capabilities, different experience. One develops in Python, the other develops in Node.js, and there’s no problem. Each and one will be responsible for their own microservice.
So that’s also great. And if we want to switch that, switching the technology on that is much simpler. So if we wrote only one microservice in Node.js and we want to switch it to go, it’s much easier than having to switch the whole environment.
We can do that on a gradual basis. And, you know, it’s much more convenient to work that way. Now, what are the tough stuff? So it all sounds really great. So first, it’s very hard to predict, and especially for a startup that is constantly changing the nature of the business, the business model, you know, the users.
We pivot…we do a lot of stuff, you know, that are written in the book of lean startups. So we need a lot of predictability on that, right? So it’s very hard to predict the design, the optimized separation to have the right to correct microservice infrastructure, correct separation for microservices.
So the second thing is the communication between the microservices becoming much difficult. You know, if you’re building a monolith, at the end of the day, everything is under one code base, under one process. And we can call a function. It’s being called. We can see the full trace, although it’s really easy, right? But with microservices, you suddenly need to handle stuff like async calls, which is always a tough thing to handle.
And usually, the communication is solved either by using queues like Kafka or RabbitMQ. But also we can use, of course, REST APIs or GraphQL as well for communicating between the microservices. And the other thing that kind of I touched on the last point is tracing.
If you want some of the solutions, we can get that to a more technical discussion with Aviad, my co-founder and CEO of Frontegg later. And he can tell about the best practices of doing traceability in a microservice-based environment. And testing is also harder, right? Because if you’re doing testing that’s only relevant for the microservice, it’s fairly easy.
But what happens? We need to do a test that is cross-microservices. It becomes a bit more challenging. So after about seven years, I would say, of dealing with these questions on the architectural side, our philosophy today for startups is to embrace microservices.
So at the bottom line, you know, we are opinionated. We’re saying what we think. Of course, there are places to argue there. You can say that, you know, it’s not the wise decision, but we’re saying embrace microservices. We’re saying embrace microservices and do that wise, you don’t exaggerate. So at the beginning, you don’t need to do really thin splitting and slicing of the microservices.
You can have several microservices. It’s always easier to split to more services than to reunite services together. So here we’re saying don’t exaggerate. Do that wisely, do that gradually. The third thing is that, you know, mix technologies, but don’t overmix. So one of the advantages we said about microservice is the ability to use different technologies.
So, you know, that being said, you don’t need to overmix technologies. You do need to have some kind of strategy within your organization about one or two technologies that you’re embracing because the communication within your R&D organization will be much better if people can share their knowledge on the technologies that are being used within your startups.
So do mix technologies. Don’t overmix technologies. And it’s very important. We see a lot of cases. So our customers are technological customers, amazing, innovative companies around the globe. And we see a lot of technologies.
We get asked to write a lot of SDKs because we’re a developer-facing solution. And we see a lot of mix within organizations that, especially at the early days, causes a lot of stress and uncertainty within startups. So stick to popular technologies, stick to stable technologies that are well-documented. And even within your organization, pick one or two top of these technologies.
Don’t overmix that. And the first thing is embrace third parties as another microservice. I think that one of the great things in choosing a microservice architecture is the ability to embrace third-party solutions.
And then these solutions will act just as another microservice within your environment. So that’s kind of a managed microservice approach. So, for example, if you are doing billing with Stripe, you can treat Stripe as one of the microservice within your environment. Has its own APIs, you can communicate from other microservices, and it works well.
So I think that it kind of blends well within the paradigm of the microservices approach. So anyone would like to ask a question about this topic before we move on? Okay.
So let’s continue. How much focus should we put on security? So, you know, the security companies are always scaring us that we should handle security, security, security, otherwise, you know, the whole world will explode and bad things will happen if we don’t buy their product, right?
So this is kind of the approach of selling security. But we’re in the early days and, you know, most of the security products they sell to enterprise companies. So I think that we still have much more choice. Maybe we will be less appealing to hackers and attackers, you know, to actually try to hack our infrastructure.
So we have a bit of a slack there. Now, what are the topics that we should even discuss or have in mind? And these are just five of the topics around security because there are a lot more. But the first topic, assuming that we’re building a product that is web-based or mobile-based which is basically the same thing.
There’s the old aspect of web security, right? So there’s the OWASP Top 10 that I’m sure most of you are familiar with. So there are, you know, standards that we have to embrace when building a product, a web product so it can be secure and tolerant. The second thing is infrastructure security.
We have a cloud. You know, people can hack into the cloud. There’s always attacks over there. So we should protect our cloud environment. This is the infrastructure phase. Compliance. We have to deal with compliance because, you know, our customers use our products and they will ask us to be compliant and have certain certifications.
You’ve probably heard of SOC 2, maybe some of you, SOC 2, HIPAA, ISO 27001, GDPR, CCPA. A lot of these logos that we all like to put on our websites, we have to deal with that because, you know, that’s even the business enabler for us.
There’s the access control part, right? So we have employees, they have laptops, they can access the different code bases and repositories that we have. We have to handle who can access what, what type of multifactor authentication do we embrace or do we not? And this is one of the topics.
And product security. Product security is something that is often overlooked. Product security means what are the security capabilities that we’re enabling within our product for our end users, right? So I’ll give you a small example. Are you enabling SSO authentication?
Are you enabling multifactor authentication? Do you provide audit logs for your end users? So all of these are product features that have to do with security, and why we call it product security features is because at the end of the day, the one that will be evaluating your product is not only your buyer, it is also the IT administrator within the organization that will check and see whether you meet certain standards that they require for the products that they use.
And if you’re not meeting them, even if you have an amazing product, sometimes it will not be enough for them to purchase and use your product. And that’s pretty shameful but, you know, it happens, right? We speak to IT managers who…CISOs and CIOs, and they often tell us, “We pick the inferior product just because it tick more boxes in our questionnaire.
So, you know, that happens. Now, let’s see. What is our philosophy on our security? So first of all, it should be moderate. We’re not saying go all in on security. As a startup, we can’t allow.
We don’t have the personnel for that. We don’t have the knowledge, we don’t have the time. We have to focus on our core. The right thing is to focus. So, you know, we should handle relevant compliance certifications because it’s enabling our business. But this is something that we should focus on. We should protect critical assets, so protecting our users, protecting our cloud infrastructure.
These are important assets that we have, protecting our code, of course, because, you know, this is our business, so this should be protected even from the early stages. We shouldn’t reinvent the wheel, right? There are standards almost for everything. There are third-party companies that have solved most of the capabilities.
And whenever we can embrace that, whenever we can use that, we should just go for it all in. So that’s very important not to reinvent the wheel, especially not at the beginning, especially if you’re not a security product yourself, right? And the fourth thing is, you know, again, when looking at your business, do whatever enables your business.
So if your customers, if you’re selling to larger companies, enterprise companies, and they require some sort of posture from the product that they use some kind of security standard, you should invest into these capabilities, right? So customer-facing stuff like compliance certification, like security-oriented features within your product, this is one thing.
On the other hand, protect the critical assets behind the scenes. Even if it’s not customer-facing, you know, you have responsibility helping the users or your customers. You’re keeping logs for your customers. You’re even sometimes keeping these critical business information for your customers. So that should be protected in a good manner.
The third question we will cover is, should we be cloud-agnostic? Or how cloud-agnostic or cloud-native, on the other hand, should we be? So what is cloud agnostic? Cloud-agnostic platforms, those are environments that could operate on any public cloud vendor or private cloud vendor provider.
And, you know, this would cause minimal disruption to moving between one cloud provider to other cloud provider, or even having an installation on your own environment, or even having an installation on the prem of your customers, right?
Sounds weird everything is moving to cloud, but again, there are a lot of requests from customers to install solutions from their environments. It happens. So when you’re cloud-agnostic, you’re much more flexible in the ability to install your solution on different environments. So on the one positive side, right, there’s no vendor locking.
So we’re more tolerant to price increase. For example, if you’re heavily vested in AWS, it means that if tomorrow they will just push their prices high, it means that it will be very hard for you not to pay.
You’ll need to observe that cost. So vendor locking is one thing. The second thing is customization. Sometimes we want a certain feature that the cloud vendor, they don’t have that. We want to configure something on the very core of the database level. And if we’re using a managed database, just can’t do that because they don’t allow us to configure that on a shared database.
So that’s good. Customization and stability part is very important for some products. If it’s important for your product, then it’s a very important thing that you need to cover. It’s a very important aspect, and you should consider whether you want to be invested heavily into one cloud vendor.
The ability to deploy on-prem, right? So when you’re building with a cloud-native, then it means that you won’t have, or it will be very difficult for you to deploy your product on-prem, on your customer’s environment, if they should ask for it as opposed to building cloud-agnostic, which means that you can deploy on-prem.
You have the full capability of putting everything on your Kubernetes or standards like Docker and just install everything on your customer’s cloud. So deploying on-prem, being fully configurated, ability for full configuration, and the ability for, you know, be quite tolerant to price increase.
This is a great pro of using a cloud-agnostic approach. Now, on the other hand, it’s expensive to build. So, you know, especially at the beginning, it’s very hard to create an environment that will be scale-enabled because it can handle scale, it can handle security.
So we want to utilize as much as possible the prebuilt configuration services that we have from the cloud vendors. So that’s the first thing. Now, the second thing, you know, it’s harder to scale when you’re scaling above a certain point.
You need to have a very tight operation. A lot of ops, DevOps, on your side, so they can handle and create an infrastructure that lasts to high scales. Usually, within cloud providers, you would get that for free, you would get autoscale, and it’s very, very convenient.
And the other con is not utilizing cloud features. So there are a lot of cool features that are built within AWS or Google Cloud or Azure that, you know, you can just use whenever they are released. And here, if you’re building cloud-agnostic, you won’t be able to utilize these great capabilities. So a lot of pros and cons to any choice.
Our philosophy here is to be moderate as well. So we’re not saying be completely cloud-agnostic, and we’re not saying be completely cloud-native in the way that everything is cloud. I’m using serverless, I’m using everything. Choose wisely according to your customer needs, right? So, for example, if your customers require an on-prem installation, then you don’t have a choice.
You have to build your product cloud-agnostic. This is actually something that we do at Frontegg. So we build a foundation that allows us to actually take our product and install it on our customers’ environments and even of their customers’ environment.
And this enables a lot of business for us. So for us, it wasn’t so much of a choice. We had to be cloud-agnostic. But it really depends on your business. Some businesses, they don’t have this restriction. So the second thing is embrace cloud because migrations are rare. If you’re thinking, “Listen, I’m going to move every year between Azure, hop to AWS, and then try Google Cloud later, and maybe the IBM Cloud looks pretty promising so I’ll try that as well,” well, it’s not going to happen.
You’re not going to move between cloud. It almost doesn’t happen. And even if when it does happen, it’s not a reason not to go cloud-native or to keep yourself cloud-agnostic totally.
Generally speaking, the cloud has a lot to offer us. The public providers have a lot to offer, and we need to embrace that in order to move fast. And the third thing is understand what you’re doing. So, you know, today we see a lot of developers that don’t understand why queries fail or why queries are not efficient or, you know, some developers that deal with databases, backend developers that don’t understand the concept of indexing databases.
And I believe that, you know, maybe I’m a bit old-school about that, but I believe that this is not a good approach. So developers should understand what they’re doing and not say, “Okay, somebody else will handle it. And that’s fine. Somebody else will handle the scale. Somebody else will handle the testing, and somebody else will handle the deployments and the automation around that.”
So we believe in an approach that means taking a feature end to end, taking the development piece end to end, which means from the point that the developer needs to participate in the design, needs to participate in how the feature is going to be documented, how the product is going to look at the end of the day, how the monitoring is going to look.
So we believe in this high feature ownership responsibility so developers will understand the big picture behind what they’re building. So cloud-agnostic goes into that because sometimes it’s convenient to say, okay, it’s on the AWS, it’s not on us. The security is on AWS, it’s not on us. They say on their website that they’re securing the data at rest and in transfer.
That’s okay. That’s what we do. We need to understand this stuff, especially if we’re the decision-makers, if we’re the CTOs, or the architect of the product that we’re building. And the last question that we will cover here is build versus buy. So build versus buy is a huge question.
There are a lot of non-core capabilities within your product that you will need to provide your users. So the question that we’re asking here is whether you build these capabilities or you utilize third-party solutions. What we see today is that there’s a lot of standards established in the last few years around how product should look like, how the experience within product should look like.
And since there’s a standard, basically we have a lot of startups that emerged during the last three years that kind of said, “Okay, if there’s a standard, I will create a product piece that you can just embrace and embed within your own application. I will take care of that part of your app.”
So there are a lot of solutions for different product capabilities that solve that. And, you know, we basically founded Frontegg because we believe in this approach. We believe that there’s a standard and everybody’s doing the same. You know, maybe people shouldn’t reinvent the wheel
So let’s cover a few of the options to actually utilize and embrace some of the third-party solutions for different product challenges, different product capabilities you will need to provide for your users.
So on the authentication side and user onboarding, you know, almost nobody writes authentication on their own today. Even if they do, they do it only as the kind of first version solution or first release. And then they’re switching to something that can last and can be much more secure. So we have Cognito, AWS, which is recommended, of course, Auth0, and Okta, which will become probably a single organization soon.
We have Firebase, which is a Google product, and Frontegg also provides authentication. So a lot of great solutions to deal with what we call a login box. Basically, providing a login and signup experience for your users. Usually, these features will include system multifactor authentication, some security controls, detection of hijacking accounts, and stuff like that.
So that’s something that is happening. And what we see basically as the pro here is that, you know, you don’t have to handle the scale. You don’t have to handle the security behind that. You can just let somebody else handle that for you.
And that would be just like another microservice that is handled by somebody else. The second thing that we’re also utilizing at Frontegg is external documentation. So we’re using a solution for external documentation. We have great solutions here, like ReadMe, like GitBook, Archbee, Swimm. So this solution allow us to present the technical documentation of how to utilize our product, including some of these solutions.
Also, provide API documentation. So these are great solutions. And usually, you don’t have to reinvent the wheel and build your own customer documentation. The third thing is billing. So here, it’s not even an option, right? We won’t be able to build a payment gateway, probably. It’s really difficult and probably won’t happen.
So it’s a business on its own. So, of course, everybody are familiar with Stripe, with Paddle, Balance, which is a cool startup around these areas. BlueSnap. So all of these are great solutions for providing billing within your app. Onboarding.
So we’re talking again about the age of product-led growth, which means that the onboarding experience of the users should be very smooth and seamless. They should understand what they’re doing within the app. And for that, there are companies like WalkMe, which usually is more applicable for a larger solution, larger organizations.
But we have Appcues, we have Pendo, and we have Intro.js. So a lot of great solutions for onboarding, the guidelines that you see with the application that you use. Self-service customer administration.
So at the end of the day, you will have your main application, but any app today also has an administration funnel, administration console for the end user. So on that console, they can usually add more users, they can control their security settings of the workspace level.
They can set up their SSO. They can see their audit logs, generate reports, usually sign up to notifications, and stuff like that. So building that administration console is something that you will have to do to enable true self-service within your app. And this is another thing that today is already solvable by other vendors.
We have WorkOS as well that’s providing that around SSO and audit logs. So great solutions that can solve these product challenges. And a new area that emerged few years ago, which is search within your app that is covered by products like AlgorIA and Swiftype, and enable true searching of entities within your applications for your end users.
So all of the capabilities that you can see here are customer-facing capabilities that can just reach your product level from zero to five, let’s say, without you having to invest so much into these integrations, into building these capabilities. So, of course, you know, our philosophy here is buy and integrate.
And, you know, from all the calculations that we see today, and we have made a lot of them, even if you are paying for these products, it’s usually much more efficient to embrace and pay for this solution rather than building in-house. Just so we understand the numbers behind that, we’re talking about the cost of a single developer.
Today we’re talking about somewhere, depending on where you’re hiring, but somewhere between $6,000 and $15,000. It can be a bit less, a bit more, but these are the numbers. So most of these solution you would be for a year much less than that. So that means that even if they were able to save you several weeks of work from your developer, it’s already cost-efficient, and then only building the solution.
Then you need to scale it. You need to handle the security behind it. You need to add more capabilities and features to each one of those solutions. So at the end of the day, it’s much more efficient to embrace them. So avoid reinventing the wheel of non-core features. Conduct a good POC.
There are a lot of different alternatives as you saw in the previous slides for each and one of those solutions. Conduct a good POC before jumping to production with these solutions, because, let’s face it, these are very sticky solutions. They go in within your product, they’re customer-facing. You don’t want to switch them after they don’t work well.
So check these solutions, perform POCs, let your customers, even some customers play with these solutions before you go full scale and utilizing them in production, and pick flexible and customizable solutions. So even if these solutions are usually kind of pre-configured, pre-designed, some of them are more customizable and flexible, and some of them are less.
So flexibility and customization can go on the backend and on the front end part. Usually, on the front end side, because it’s customer-facing, we have products that are CSS-customizable, which means that you can adapt them to any brand that they would fit well within your product.
But not all of them are like that. So it’s important to also check that factor as well. So, summary on these four questions that we ask, microservices, cloud-agnostic, security, and build versus buy. On the microservices side, as we said, embrace microservices for flexibility, but don’t overcomplicate it.
On the cloud-agnostic, we said, build according to your business need, but don’t overlook into one cloud vendor. On the security side, we said only focus on what’s the most important for your business, the things, the security-oriented capabilities that will enable business like compliance, like security-related features, and embrace third-party solutions.
So don’t reinvent the wheel. Do we build or buy? We say embrace non-core product capabilities from third-party vendors. But conduct a good research before integrating these solutions to your own product. So this is a bit on the topics. I would finish with one thing that says, and this is something that we believe is a philosophy within our startup, within Frontegg, that you should focus on what’s core and what’s important for your business and keep things simple.
Or as Steve Jobs said, “Focus and simplicity….once you get there you can move mountains.” So I’m available. Any question that you might have around heavy tech stuff or product-related stuff or, you know, just any question. And even if you’d just like to hop on a virtual coffee, I’m here. And for me, it was a pleasure talking to you.
So hope to see you soon in the next talks.
The Complete Guide to SaaS Multi-Tenant Architecture
