Talking Tech with BaseKit – Sharing In-Depth Tech Insights

We are back with the fresh Talking Tech episode where we sat down with Simon Best, the CEO of BaseKit, a resell website builder software for micro businesses, to talk about this product from a technological perspective! As usual, the interview was led by our Head of Engineering, Nika Jorjoliani, and our Business Development Manager, Shermadin Osadze. It turned out to be quite an exciting chat, so enjoy the ride! 

Intro to BaseKit

Nika: Can you introduce us to BaseKit? What are the services you offer, and how did you start?

Simon: We create digital tools for small businesses. We started as a classic website builder, but now we do more than that. Currently, our suite includes a website builder, an e-commerce platform for selling physical products, and a booking platform for time-based services such as events, appointments, and classes. We also have a mini CRM that ties together all the inquiries from the website, orders, and bookings.

We’ve been around for 15 years, so we’re not a new company. We are definitely still trying to stay young at heart. We try to still be agile and have a startup mindset regarding how we do things and develop software. 

From the business model perspective, we’re a little different from other similar SaaS companies. We don’t sell our products directly to the users of our product. Our products are sold through partners, such as hosting companies, telcos, and other SaaS businesses. These partners take our products, white-label them, and then integrate them into their portfolio of products. For SaaS companies, this means tightly integrating our offerings as a functional bolt-on to what they sell. 

It’s an interesting model from our business perspective. As we get into the conversation, we’ll discuss how this has led to some interesting technical challenges for us because we operate in many places worldwide.

Nika: Does the product need any tech knowledge to set it up?

Simon: We aim at small businesses because they are sometimes underserved with great, simple tools. We’re often asked how we compete with a platform like WordPress. However, using WordPress can be difficult for a small business without much technical knowledge. That’s why we build our products to be extremely user-friendly. They offer everything small businesses need without making things complicated.

We design things mobile first. So we’re unique in that sense. You can fully build your website, e-commerce store, or bookings on a mobile phone. That forced us to be really careful and ruthless about how we design the product because mobile screens have limited space. It also made us think about exactly what features need to be exposed to the clients and helped us simplify the product. 

We believe that creating simple things is more challenging than adding lots of buttons and features. Making a simple, delightful user experience is the actual hard part.

Nika: Why did you transition from a general website builder to a more domain-oriented approach? What was the driving factor?

Simon: It all started because a big percentage of the small businesses using our website builder wanted to sell things.  We really wanted to build something native, a first-class product in our product set. So, integrating the website builder with e-commerce, bookings and CRM is completely seamless and really simple.

Partnerships

Shermadin: You mentioned that you only acquire new customers through partners. Why do you choose to bring in new customers through partners instead of trying another approach, say, offering free trials? Is there some business decision behind it?

Simon: We still work with our partners to offer free trials, campaigns, and marketing to their end-users. We’re just doing it through our partners. The decision came because the market is really saturated. Many huge site builders and e-commerce platforms have big marketing budgets, and sticking out in that crowd becomes difficult. 

We wanted to have a different route to market. While developing our product, we focused on providing a service to our partners and helped them be great at marketing. They, in turn, took care of that marketing to their end customers.

Another interesting point is that we operate globally. Our partners in certain parts of the world are experts at communicating with their customers in their language. They’re localized, already have their customers, and provide great support. So we’re working with partners that are just great in their region.

Shermadin: Can you share insights into your target markets? How are you targeting these people, and ​​how do you select your partners?

Simon: We operate globally, with partners on every continent. Europe has a significant number of our partners, and currently, 70% of our revenues come from European partners. That’s how the company has evolved.

But this year, for example, we’ve had lots of interest from Africa. Several African telcos have been interested in hosting and digital companies. They’re interested in picking the product up and rolling it out to their customers locally. So, how do we target? We can go anywhere with this product. It’s very easy to localize it since we can translate it and change images and things to make it culturally relevant. So we’re always looking where the demand might be. 

For example, if we consider Africa’s current position in the tech market, they seem to be in a good place to take on tools like Basekit. Whereas if we looked at the US,  it might be difficult to find partners there now. It is usually dictated by how much appetite a particular geography or market has for a product like ours.

Technical Setup

Nika: Could you share more details about the tech stack you use? Since we are official Laravel partners, I’m curious if Laravel is also part of your tech stack.

Simon: We mostly use PHP, Symphony, Redis, MariaDB, Ngnix and OpenResty. So it’s more bare-bones frameworks that we’re using rather than full Laravel. On the front end, we’re slowly switching out entirely to React. We still have components that are using the Backbone. Our tech stack, in this sense, is fairly standard. 

What’s interesting is we have two technical deployment models. The first one is what we call our hosted or SaaS model. This means we deploy our tech stack to the public cloud, spreading it across various locations globally. Partners can choose to use our hosted version in the environment that is closest to them.

For example, if we’re working with a hosting company with its own data center, they often prefer installing the Basekit application there. We monitor, manage, and maintain that within their own data center. So, one of the remarkable parts of our tech stack is how we handle and maintain 50 environments worldwide.

Most SaaS companies have one or a couple with staging. We’ve got 50 environments worldwide, and some of those also have staging environments. There are a hundred environments that we work with, and we have to monitor and maintain all of that. We have a troubleshooter, and every two weeks, we introduce new code to these environments to keep things running smoothly.

Nika: How do you manage requests from specific clients who ask for features unique to their needs?

Simon: We always try to generalize it. We’ve done very little that is specific to a partner. We have a flexible way of adding payment gateways and switching them on and off in different territories. 

If they ask for a specific feature that we know nobody else will need, we say no to keep things as pure as we can. We’re 15 years old now, and if we had done that every time, we would have an unmaintainable codebase and work with it would be difficult.

Nika: Did you start multi-tenant from the beginning or switch to that later? How was your journey there?

Simon: When we started, we were multitenant, and you could have multiple sites in an environment. Each tenant was the end customer who had their own website. Now, we’ve got two levels of tenants – the partner Brands and the customers underneath them. So, it definitely introduces some interesting complexity around how we managed and did reporting on it.

Handling Migration Challenges

Nika:  As you’ve mentioned, you’ve been using Backbone.js for the front-end stack, and then you tried to go to React. How did you handle that transition? In my experience, migration can be challenging because you’re not always sure what to move or what needs to be fixed in the old version. How do you prioritize migrations, and how did you handle all that?

Simon: In the past, we would rebuild the whole thing and spend 6 or 12 months doing so. However, it was sometimes not the right thing to do because you’re essentially putting a lot of engineering time into something that does not add additional value or features. 

What we’re doing now is if a feature that is a part of the code base still uses Backbone, we’ll put the additional effort and pay off that technical debt to convert that feature into React.

So we have a hybrid front end at the moment, which has some pieces of backbone still existing and some pieces of React. It might sound horrible from a technical perspective, but from a business perspective, it is often the right thing to do. However, the new products that we create, like bookings and CRM, are all 100% React.

Nika: How did the old VPS Stack transition to Kubernetes? We are also in that process, so sharing thoughts about that journey would be interesting.

Simon: We already had a head start as we Dockerised our production stack way back in 2015, so we were well placed to move to Kubernetes. We had to implement some scheduled jobs differently, but otherwise, the transition was pretty straightforward. We currently have around 20 environments running BaseKit on Kubernetes; the rest are running a standard Dockerised stack.

But when working with partners on any sort of migration, we often need them to deploy new servers or hardware to make the migration happen. So, that becomes a lot more challenging because it’s not just about managing the technology but managing partners and their expectations. It can take us longer because we are waiting for our partner to do something we need to make the migration happen. So it’s often more around that negotiating and timing.

DevOps Practices

Nika: I’m also interested in your approach to deployments, the whole CI/CD pipeline, and handling test cases. How do you go about managing these processes?

Simon: Our continuous delivery process relies heavily on automation, including automated testing and manual processes like peer reviewing our Git codebase. We work in two-week sprints, and throughout this period, everything is automatically tested, peer-reviewed, and merged into the main branch. At the end of those two weeks, our operations team manually kicks off a release to all of the servers.

Some of our environments operate on continuous deployment. This means we don’t have to wait for the end of the two-week Sprint when the feature is finished. These features undergo QA and automatic testing and merge with the main branch. We might be doing several releases a day.

Nika: How often do you encounter new bugs with this trunk-based development process, and how is your QA process structured to handle them?

Simon: We encounter bugs regularly, as is common with any big software product. Some types of bugs are difficult to pick up with automated testing and don’t become apparent until you deploy them to some of your customers. So, we have several levels of testing, such as developer testing, automated testing, unit testing, functional testing, and QA testing.

Our small QA team thoroughly tests the product and new features to ensure everything functions correctly. But if a bug gets through to the live environment, we have a hot fixing process allowing us to deploy code outside the regular two-week window.

If it’s picked up before the two-week cycle ends, we edit it in the main branch. Then, that’s automatically deployed to fix all those continuous deployment environments. By the time it reaches the end of the Sprint, all of the other environments will have the fixed code.

Nika: We mainly do automatic testing, unit testing and feature testing on the backend side. Considering that we use Laravel, this framework simplifies the process of setting up the features and exposing API endpoints on the Backend side. Since there are frequent changes on the front-end side, we usually skip unit testing. We use the automation tool Zephyr to document our test cases, test cycles, and full regression cycles. That allowed us to improve the quality of our deliverables by providing transparent information about statuses and progress. It’s also integrated with our GitHub releases for release management, so the entire process works smoothly.

Product Development Plans

Nika: What are your future plans? What’s the next big idea?

Simon: We’re currently working on BaseKit’s API, and one of our ongoing projects is the development of a widget SDK. This SDK refers to the components in BaseKit that make up a site and will enable our partners to integrate new widgets they have created into their BaseKit websites. Our team currently handles this process internally. Looking ahead to next year, part of our strategy involves opening up the platform. We’ve noticed a growing interest from SaaS companies looking to integrate the website builder with their products. So, that’s a big part of our plan for the upcoming year.

Hopefully, we will do something quite big next year with AI. We’ve got some ideas about how that might work. OpenAI has demos showing websites generated automatically and chatting with your site for edits. We’re still not wholly convinced by those, but they point in a certain direction. That’s going to take us to a place where you probably don’t use drag and drop to create a website in a couple of years. We’re taking a moment to think things through, and we’ll have a clearer plan by next year.

If you check out OpenAI’s recent releases, they focus on how chat GPT and APIs can communicate with external services. This is why we’re investing heavily in our strategy next year to open up our API fully. We can imagine that even if we don’t do the AI bit, someone will do it; they’ll talk to our API to build e-commerce stores. So, whether we come back and do something else with AI will be yet to be seen.

Nika: I think it will fit your business model really well. The main feature you offer is buildable websites, which can be simplified with AI’s help. The quality is probably going to go higher in the future years.

I’m looking forward to seeing how BaseKit grows in the future!