mjashanks

At the moment any tool that you write inline in your instructions - the agent has access to use.

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.

I feel like now, more than ever, the time is right for the EU's move to open-source to succeed.

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...

The point that foxbee was trying stress is that Budibase is not for building SaaS products.

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.

Yes - we want this, except that we happen to have an open bug for this at the moment: https://github.com/Budibase/budibase/issues/3164 - so it's not working right now.

Thank you! Credit to https://www.thehypefactory.uk

Thank you! I hear you with the pricing for activity. It's definitely something that we will consider.

And who doesn't love a vanity URL?!

I hear you! Budibase is not meant for building a SaaS product. However, it's good for "Customer Portals" - whereby you are giving access to external users. This is a problem for per-seat pricing, but there are ways to solve it.

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!

TLDR; AppSmith and Budibase are quite different platforms, but with significant overlap.

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.

Thanks Ace!

Thanks for the feedback! We've not yet settled our pricing, which is why its not listed.

Great to hear some opinions on it :)

Thanks! Open-source has been fantastic for us. We've only recently launched our cloud platform, yet we've had a good sized community using Budibase and feeding back issues, feature requests etc. for ages. Building an open-source product has been so rewarding that way.

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.

We haven’t yet worked out out our pricing model for Budibase Cloud. However, it will most likely be user-based / per seat - similar to platforms like Retool & Airtable.

Hey Everyone! Other Budibase co-founder here.

An open-source platform is the missing piece to the low-code/no-code landscape - I'm also here to answer any questions!

You could provide an "Export Data" function, and even supply them with regular, scheduled exports.

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.

Yes! I have been using Svelte on Budibase (https://github.com/Budibase/budibase) for the past year. Although Budibase is not in production yet, its a serious project that we plan to release in the next few months.

I have used React and many others over the years - currently using react in my day job.

I really like Svelte. I would happily choose it over React for any of my own projects. I find Svelte simple and intuitive - it is the easiest framework i've ever used, to get to grips with.

The tooling, resources and no. of 3rd party libraries are way smaller than the bigger hitters, like React - understandably as it is much younger. I have not found this to be an issue at all - theres a VS code extension and a great community and website/docs/examples.

It will obviously be more difficult to find devs with Svelte skills, if you are hiring... but its so easy to pick up, i dont think thats a problem.

Could really do with the freelancer CRM actually, i haven't seen anything out there thats not targeted at enterpise.