mjashanks
Joined 7 years ago
Joined 7 years ago
Linux Desktop is now simply better than Windows, by far. Open office is good. There are many high-quality, commercially supported open-source products available now, developed by full-time, highly talented engineers.
There's every chance that this will work & breaking up oligopolies is great for everyone, not just Europe.
I wrote about this recently if you're interested: https://budibase.com/blog/updates/eu-digital-sovereignty-and...
There is absolutely no reason why you could not give login's out to your customer - i.e. a customer portal.
It's just difficult to draw this distinction with simple terms, so sometimes we say "Internal" to try and separate from "SaaS Product". Naming is hard - we've been using the term "Business App" more often now.
And who doesn't love a vanity URL?!
We've thought about pricing per MAU. The difficulty is that we would always be charging for last month's usage, rather than more predictable upfront charging. Also - coming up with an exact definition of "active" is not trivial!
Thanks for the feedback!
Budibase is meant to be used by IT Professionals (sysadmins, dbas, IT managers, PMs, developers). AppSmith is more targeted at developers. Because of this, Budibase has much less of a reliance on code - we like to say “code optional”.
Also, you will see us talk more about “Business apps”, rather than “Internal Tools”. A Budibase app is a real, single-page application - which you would happily give out to external users and folks in other departments who do not need to know your team’s internal processes. The apps are also responsive by default.
Another differentiator is that Budibase comes packaged with a database (runs on CouchDB). This makes creating new applications easy - without having to spin up another DB. We also offer 1st class support for SQL Databases - Budibase will automatically fetch your tables and automate the basic INSERT, UPDATE, SELECT and DELETE statements (like an ORM).
If you want to place us in the overall low-code landscape, we are more like an open-source Powerapps/Mendix/OutSystems. I sometimes say (half-jokingly) that Budibase is what would happen if Retool and Stacker had an open-source baby.
Great to hear some opinions on it :)
Of course, you're exactly right - we now have another ball to juggle; keeping our cloud up and running!
It took us nearly 3 years to open our cloud up, but I'm so glad that we left it this long. Only now do we have the engineering resource to handle open-source/self-host and cloud whilst still keeping the pace of development up.
So, for tips - work on product, product, product. Build your community and give them a great open-source offering. Your community will give back in return - even pure product feedback is gold. Then launch cloud when your direction is solid and you're confident in your product.
An open-source platform is the missing piece to the low-code/no-code landscape - I'm also here to answer any questions!
Also - you can still license your product with a closed source license, but allow your customers to run "On-Premise" ... i.e. they can still run your product for themselves, and own their data, but are also paying you a license fee for the pleasure.
It's a different revenue model, but can work - afterall, this is how business was done with software, pre SAAS.
Often, companies who license in this way offer $xxx.xx per year - getting them support and upgrades for the year. Then, if they cancel after the year is up, they get to keep it - with no upgrades. It's important that your pricing model reflects this scenario.
One of the upsides of this model is that you have zero infrastructure costs.
The way to scope down access, would be to use an Automation (our RPA, zapier-like section). You can give an automation parameters and control exactly what it does, then use it as an agent tool.
In future, we'll be looking into user-delegate permissions. I.e. you give your users a role (RBAC) in Budibase, which gives them access to certain resources. Any agent calls will be done under the user's permissions. This is not always desirable - sometimes you want your agent to have more permissions that the user - so this will need to be configurable at some level.