When deciding on a tech stack for a startup, there are typically three paths to follow:
Choose the technology that aligns with the technical experience of the founder.
Choose the technology that suits the purpose of your business.
Choose the technology with the most longevity and lowest switching costs.
As the technical founder, @bram chose option 1, which turned out to be the best decision for several reasons. In Founder Chat vol. 3, Bram shares the details behind the Baserow tech stack. Get insights into the backend, frontend, product stack, and examples of how we use Baserow internally.
Join the conversation and ask follow-up questions in the comments
The product team’s tool and tech stack is constantly evolving, but I’m pleased to share what we’re currently using.
Backend tech stack:
It’s always difficult figuring out which stack you’re going to use for your project because there are always tradeoffs, and it’s a lot of work to change later. As you know, I started Baserow as a side project. At that point, I decided to use Python, Django and PostgreSQL for the backend because I was already comfortable with that stack. I’m happy about that choice because the robust ORM (Making queries | Django documentation | Django) now helps us with making user table schema changes, prevents SQL injection, and much more. You can read more about that here: How Baserow lets users generate Django models on the fly // Baserow. There are also some performance downsides to using the ORM, that’s what I mean with the tradeoffs. PostgreSQL is a no-brainer because it’s the most advanced open source relational database out there. On top of that, we’re also using Django Channels, Celery and Redis for asynchronous tasks like making a table exports and real-time collaboration.
Frontend tech stack:
The frontend currently uses a combination of Vue 2 and Nuxt 2, they will soon be replaced by their version 3 replacements. The decision to go with Vue is because I already had some experience with it, and I decided to go with Nuxt because they have the universal mode where the initial page is server side rendered. At that point, I wasn’t completely sure how big of a role the server-side rendering was going to play, but thought it could be useful for allowing search engines to index publicly shared data. This was a good move because of that reason, but also because we’re working on an application builder where SEO and crawlability is important.
Product stack:
Better Stack for our public status page: https://status.baserow.org/. It automatically checks if our services are up.
Figma for UI/UX and banner design.
Browserstack for testing cross browser.
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 persistent documents.
Active Campaign for sending automated emails and our CRM. We have integrated baserow.io with it via their API.
Baserow:
We’re of course, using Baserow internally as well. This is for example, used for our design backlog, feature planning, various forms, project management, equipment management, investor tracking, and many other things as well.
Some other tools worth mentioning:
Pytest: use it for automated tests in the backend
Flake8+Black: linting and formatting in the backend
Jest+Playwright: automated tests in the web-frontend
SCSS: generating CSS code
Docker: for our development environment
Git+GitLab: to collaborate on code
Font Awesome: although it will soon be replaced because of our redesign, it makes Baserow look better
