As many of you know, Application Builder is currently in beta, and weāre actively thinking about what the future pricing and packaging could look like once itās fully released.
Customer delivery portal. In this use case, the delivery organization (for example an agency) is using Baserow as a single source of truth for a seller-customer relationship, effectively replacing many internal tools like CRM, employee management, capacity management, project and task management. Typically, 2-10 of their end customer employees login the portal weekly or bi-weekly. 5-30 active internal users, who login on a daily basis, have a separate application interface to be able to manage relevant context, e.g. multiple projects. From the portal, customers can review delivery related reporting, contracts, invoices, project details, milestones, tasks, statuses, and are able to leave comments, submit requests, etc. The use case would enable to significantly reduce or eliminate the need for synchronous communication tools like Slack.
Internal company app to deliver physical services, for example window cleaning services. Internal users would consist of management, marketing, sales, and deliveries. In total, there typically are 10-50 active internal users, who login in on a daily basis. The app would replace many of the existing internal tools, covering SOPs, service management, pricing management, marketing operations, leads management, sales pipeline management, contract management, capacity management, delivery management, asset management, and reviewing customer feedback and improvement ideas.
Impeccable timing! Iāve been thoroughly exploring options to build fully custom software for my real estate company (multifamily apartment acquisitions & operations), where Iāll need very different UI/UX for each logged-in user, whether they be an employee, resident, applicant, vendor, investor, guest, etc.
So Iāll have a fairly high number of rather infrequent users needing access only once or twice per month.
Iām particularly keen on whatever pricing model yāall land on, because regardless of internal platform capabilities, your external app pricing for my occasional high-mix / brief-access userbase could be super attractive or outright prohibitive, depending.
Anyway, let me know if yāall want to discuss any of this before I pick the wrong horse to ride. Thanks!
In my usage scenario for Baserow (a team management system for volunteers at an event that only happens once a year) I would have only one or two admins actually programming and administrating the database - meaning full access to Baserow. The data itself however would be monitored and modified only by around 3-10 people via a web app, who in total are probably only active in around 4-6 month a year. The thing where this becomes tricky is the ~250 volunteers who are supposed to provide us with the dates they want to work and also need some method of providing updates. They would also onlƶy be using an application builder frontend. Ideally, they would all have their own account where they can add and modify all their personal data as well as select and update their available dates. This means every user probably only logs in around 2-3 times each year.
We are currently doing this with a semi automated database (lots of manual adjustments and updates needed) in Notion, using their free guest accounts on an Enterprise plan. It works, but certainly is not ideal. The cost for users accessing am application builder frontend would make or break a switch to Baserow. If each frontend user would be about 4ā¬ per month active (as previously hinted at), it may already cross the threshold where a custom web application built with Claude Code may be cheaper in the long run. Itās an initial invest and certainly not as on-the-fly-flexible as Baserow, but money is the key aspect that we need to keep in mind.
Hope this gives you a better idea of our use case.
I also built an application for managing a large number of volunteers, and I thought that I might pass along an idea that might save you money, once Baserow charges for each user account. Rather than have each volunteer with an actual login, you can have them access their āindividual pagesā via a link (we send ours via email, with an āUpdate your contact infoā link or āSign Up for this eventā link that is customized in each email to include the individual id for the volunteer in the URL. When they click the link, it loads the Contact Information Update page using their rowid value as part of the URL, loads just their info and displays it, allowing them to update and save changes. You could even take them to a page to enter a pin code to verify access, which would pass their id and pin code to the next page to load the data if the pin code is valid.
It works for us without having to worry about logins and passwords for people that just need to give periodic updates or to sign up for shows and account management would be a hassle for so many volunteers.
Form to share your thoughts anonymously: Tell us about your Application Builder use case | Baserow
Thanks!