Baserow has grown significantly over the past two years. Our team has more than quadrupled in size, from 3 members to 18. The number of signups has increased from 10K to 35K in Baserow Hosted alone, and we now have hundreds of paid customers.
This growth spurt has led to big changes in how we operate as a team. The result is a new set of working processes based on what we’ve learned.
In open source fashion, we’re giving you an insight into how we work internally and how we build Baserow.
Tech stack
Backend tech stack:
Python, Django, and PostgreSQL.
Frontend tech stack:
Vue 2 and Nuxt 2, will soon be replaced by their version 3 replacements.
Product stack:
- Better Stack for our public status page: https://status.baserow.org/
- Figma for UI/UX and marketing designs
- BrowserStack for cross-browser testing
- Sentry for error logging
- Matomo for website analytics
- PostHog for product analytics
- Digital Ocean for our production environment
- Paddle as Merchant of Record (payment provider)
- Notion for wikis/persistent documents
Check out our founder’s detailed response on why we use these tools
Development team
The Baserow development team is divided into smaller teams responsible for specific parts of the codebase. Each team consists of a few full-stack developers and a tech lead.
The teams operate in a way where a developer is assigned an issue (task) that includes a functional description and UI/UX design. For significant features, we might have a video call to discuss the details further. If necessary, the developer prepares a technical plan that needs to be approved before implementation begins. Once completed, another developer on that team reviews the code. If approved, it is merged into the develop branch and eventually released.
We usually hire full-stack developers with experience in both backend and front-end development. This allows a single developer to build significant features from scratch. We strongly believe that developers should have ownership over their tasks and not constantly rely on others, which can delay the entire process. This approach enables us to ship features quickly without sacrificing code quality.
Release cycles
We work in 4-week cycles. After each release, we hold a planning meeting to synchronize completed tasks and work that still needs to be done, and prioritize features. The development team then works for 4 weeks, and regardless of progress, we prepare for a release. Every release undergoes extensive testing, is deployed to Baserow, and is officially released to all our self-hosters one week later. This ensures that the release content is well-prepared, runs stably, and makes it easier to fix bugs on Baserow before the release goes live for self-hosters.
Check out our founder’s detailed response on how we came to this approach to release cycles
Roadmap planning
Our goal is to become the open platform to create scalable databases, applications, and workflows without coding. If a feature request does not align with that goal, then it will not make it on the roadmap. Although, it’s not always as straightforward as that. We hear many great ideas, but you also need to say “no” sometimes. We have a good idea of what the product should look like in a couple of years, and we try to stick with that, instead of becoming a jack of all trades.
Check out our founder’s detailed response on how we manage roadmap planning
Feature prioritization
We use GitLab and Baserow to manage all feature ideas. Incoming requests are divided into big features, smaller changes, and bug fixes. To accomplish this, we wrote a script that synchronizes all GitLab issues with a table in Baserow. This gives us more flexibility in adding tasks that are not an issue, mixing in feature requests, and storing additional information like which customer has requested a feature.
Another thing we did was create a methodology where we score every issue related to six drivers: adoption, revenue, strategy, development effort, operational impact, and risk. Each of these drivers is scored on a scale of 1-6, with 6 being the best possible score. However, not each of those drivers is weighted equally. Because we’re in an early stage and have limited development resources, we decided to give adoption and dev effort extra weight when it comes to scoring.
We’re synchronizing the score back into the weight column in GitLab. This allows everyone to see a prioritized list of features.
Check out our founder’s detailed response on how we prioritize feature development
At Baserow, we know that every problem has multiple solutions. And while you may not always find the right solution the first time, the experience gained from trying out different approaches is valuable in uncovering what actually works.
With our Founder Chat initiative, we aim to show you how our processes have evolved into what we have now and what we’ve learned from them. As we continue to scale, we’ll revise and update these processes to reflect our evolving thinking.
Do you want to learn more about Baserow’s external processes? You can also submit questions for future weeks here. One of the Baserow founders will cover them in the next volumes of Founder Chat.
