2.0 feedback 🖋

[melohagan]

Version 2.0 of Budibase has been released for you to try out!

If you have any issues, feedback, or suggestions, please post them here!

Budibase plugins have been released as part of 2.0!

Share your ideas for custom integrations below:

• Suggest a datasource integration 🔌 #7807
• Suggest a custom component 🎡 #7858

[andreasbhansen]

Suggestion:
Enable testing and developing custom components with live-reload (watch) in the hosted cloud environment. Airtable Extensions (previously Blocks) does something similar to this where you pull some generated files and keys, start the local dev server, and the Airtable Extensions panel will automatically reload with changes when you save code locally. This could probably enable more people to contribute with custom components as there's quite a bit of setup and disk space needed to get Docker (composer) etc. up and running just for component development.

[joebudi]

Thanks @andreasbhansen . This is great feedback.

[andreasbhansen]

Here's a short video of the developer experience. As you can see, it has quite nice DX!
https://user-images.githubusercontent.com/1404793/191591734-b59a23df-182e-4a91-8c80-49d624ba89bd.mov

[joebudi]

This is super helpful, thanks. 👍

[poirazis]

Upgrading my two staging servers was smooth as silk , no issues to report so far !

[joebudi]

Thanks @poirazis

[aderici]

Congrats launching 2.0! I like the idea of custom frontend components!

I dont like the idea of per user pricing though. Day passes makes it even worse, people will be scared to log in and use the system. Thats my personal opinion though, we'll see how the market will respond.

Looking forward to more premium features!

[JCV67]

Self hosted Budibase is no longer open source?

[mjashanks]

It is still open source, but some features are not open-source. This is a well-known business model for open source products - "open core".

We will not retract any open-source features and we will continue to build new open-source features.

[JCV67]

OK, I understand, you must pay salaries and expenses.
Thank you and keep up with your good work

[arladmin]

Hi @mjashanks , i'm a bit confused by the pricing info on https://budibase.com/self-host/

Does this imply that now the self-hosted version is paid as well, to benefit all features?

[mjashanks]

Hi @arladmin

Yes, you are correct - some Budibase features will be commercially licensed. Just to reiterate the above

1. What is open-source today will remain open-source always.
2. We will continue to improve our open-source offerings (it's vital to the health of the product)
3. We will also be developing non-open-source features on top.

[andyburgessmd]

Although I totally understand and support the new pricing options. It could have been a bit nicer if we had a little more time to deal with selecting a package. I just hit the day pass limit and don't have a company credit card to add to upgrade so now applications are unavailable.

[shogunpurple]

Sorry to hear that @andyburgessmd - first of all thank you for the support. We will get you back up and running ASAP until you get your company card.

What’s your tenant ID?

[kontosa]

Please take this as constructive, I really like how budibase has progressed to date - but the pricing implementation was a shock - no mention of this coming when you announced 2.0 on HN?

The pricing seems steep for what is still being pitched as a 'business internal tool'. But this may be me coming from a dev-ops perspective without market knowledge of pricing of such tools. But note that for the likes of us (many of your to-date customers?) this makes it a hard-sell we will have to make to managers now that even self-hosting is $$$.

The day passes (once understood) are fairer and that is great, but the allowances appear stingy on top of the p/m cost*?

And no reduction in pricing for self-hosting? Wouldn't you be relieved of the cost of hosting and its maintenance and shouldn't that be passed on to customers?

*A scenario that we are looking at implementing:

• a self-hosted internal 'Op's task tracker' for a small team of 8 within a larger company.
• About 30 regular 'viewer/reports users' and all users needing OIDC authentication.

= using up lots of day-passes quickly, unless choosing a larger pack or a pricier tier that the managers will baulk at, for what would be for them an untried solution from a young company.

= for the team - reluctance to log-in/use the tool as we worry about using up a pass... just to check this one thing... wait, how long has it been since I last logged in? Was it today? How many passes left?

Apologies if this reads harsh, I respect the need to introduce pricing - it points to a longer-term future for you and bb and that's great for us too :-)

Craig.

[bluepuma77]

I am personally not happy with your "unusual" pricing, please let me explain why.

On a first look, it seems very nice and inexpensive, though complicated. A person is only using the app once a month, so you only pay a day, not a full month subscription.

It seems very fair to do pricing just by usage, as we do with lower-level cloud services. You could even charge by minutes used. You could go one step further and charge by requests used, like lambda functions. Just customers don't know how many requests a single action creates. Hey, every link, button and action could have a dedicated price tag next to it ;-)

But on second look, how do you want to forcast the usage? And for budgeting of companies this is important.

If a person only works a single day a week, this is easy. But if a person works 20-22 days a month, how do you know how many day tickets you need? Do you ask every employee in your organisation? They say 22. If you explain them the cost, they might say less. But then you have internal discussions: "Hey X, can you not use app tomorrow, I need an additional day to finish up". This is not how I envision a work environment, where every step needs to be pre-planned and needs to be paid for.

If you are the department manager, you suddenly need to do forcasting for the budget you need to run the app. This is hard, this a real skill. How should a financial department budget this for the overall company? They hate nothing more than unpredictable cost. They can live with a bigger cost for your app, but they don't want high volatility and uncertainty.

Finally, how do you want to enable the auditing of your monthly cost? Do you want to list the usage of every employee like it's done with phone calls (CDRs)? Be aware that in some European countries this will not sit well with the workers councils and they will just block the app to be used in their company because of individual usage logging. (We know it's in the database anyway, but you make it more explicit.)

So from a making-it-more-predictable side I like the user/month methodology. But at the same time when looking at Slack this gets very expensive pretty fast and people will then potentially look into other more cost effective solutions.

I have been looking into SupaBase and their self-hosted model is completely free, no strings attached. You charge for self hosting the same price as for your SaaS offering, that seems strange.

You choose user groups as arbitrary feature to push your customer to upgrade. How come? I am happy that you have not chosen auth as Elasticsearch has done for many years to sell their X-Pack ;-) But it somehow seems random. I checked some of your competitors (Retool, Appsmith, Tooljet) and they seem to have different models, some selling an "enterprise license" at an undiscloded price.

Of course I would like to see more features for free, only have enterprise customers pay real money, how about making the self-hosted pricing more dependant on clustering? When you want to use Traefik in a cluster (with Let's Encrypt), you need to pay them at least 3000€/year for a support contract. Dropbox has <5% paying customers.

On a second "finally", at first I didn't understand why most app-builders use "for internal use" in their marketing. Of course this makes sense when using a users/month pricing. But personally I really want to build an external portal where people can register so I don't have manual paper work. Would love to see a viable pricing model for that, too.

Just my 2 cents. Overall I don't really have a clear recommendation, just a little food for thought.

[JCV67]

Been thinking about this. If, as said before, Budibase wants to be the "WordPress of Low code", charging over self-hosted won't get you there.
WordPress charges only for services hosted in their servers.

[mjashanks]

Firstly, thank you @kontosa @aderici @bluepuma77 @JCV67 for your constructive feedback on pricing. You have all recognised
a) Our need to make money to continue to build a great product
b) Our effort to implement a fair pricing model

And, you have all done so in a friendly and professional manner. That makes me proud to be a part of this community.

Thank you. Many of your criticisms are valid - we will try to address them.

I will now try to explain our choices below.

Pricing unpredictability & confusion

The day passes model is indeed unpredictable for finance/procurement - we totally accept this criticism, and we knew it before we implemented it. It's the big tradeoff with the model.

There are some things that I think we can do to alleviate the unpredictability. Some around education on the model, and some on the model itself. This is something that we need to chat about internally, and I'd love to hear any opinions from the community.

I suggest at this time that you can still think of it per-user if you like. You will never pay more that 23 day passes per user (usually it's 22). So, when you calculate per user, you'll see that we charge between $10 and $20 per user on all tiers. It's even less if you have a lot of users that only occasionally use Budibase apps.

I appreciate that nobody wants to estimate this - especially a procurement team - and this is the primary issue here. Telling you to calculate it is missing the point :) but I wanted to paint the picture anyway.

Day passes is not a common model. Confusion is another tradeoff of the model. Our other pricing model options are

• Per user - doesn't allow for infrequent users - all users are priced equally. If you'd rather we just charged per user - I'd love to hear it. We went against it initially because we felt like it would scale for people.
• Per app - we never want to limit the amount of apps that people can build.
• Per query (pure usage). Even more unpredictable.
• Combination per users + additional day passes (guests). We are open to this - but may cause additional confusion. Please give your opinions on this

Paid tiers are expensive

We are charging a very similar price to competitors. If all of your users use apps on every working day, it comes in around $10 - $20 per user per month.

Granted, our paid tiers are not fully fleshed out. However, if you have been following us for some time you will know that we execute fast. Over the next 6 months, those paid tiers will start to look a lot juicier - with environments and revision history planned for this year. All this is happing whilst us putting equal effort into improving the free and open-source product.

If anyone in our community has this concern - i.e. "I want to support Budibase, but the paid tiers are not quite worth it yet" - I'm happy to offer you a time-limited community member discount on the listed price - all you have to do is reach out and talk to me - just click "Contact sales" on the website.

We also may look at increasing some of the allowances on our lower tiers.

Reduction in price for self-hosting

I'd like to clear this one up. There is the perception that because we don't have to pay for hosting, self-hosted deployments should be cheaper. Here's why I disagree.

Our monthly hosting costs accounts for significantly less that the average monthly salary of one employee in our company. We've had over 40,000 companies use our SaaS platform. It's a tiny amount of our operating costs. The vast majority of our spending goes our amazing staff whom we pay to bring this wonderful product to you.

We set the self-host versus SaaS pricing to be equal because we want to incentivise use of SaaS.

• It's easier to support
• It's easier to keep people up to date
• We can get better product analytics that help us to improve the product.

That said, I completely understand why SaaS is not an option for many. Maybe you need hosting in your own country. Maybe you are not willing to open your database to the public internet. And more reasons.

These reasons are why we still offer a great self-hosted solution, despite missing out on the above benefits. We still very much believe in self-hosting, and we will continue to improve the self-hosted offering. But - it is not cheaper for us.

If you have a self-hosted deployment that gets high usage, but you still don't like the price - please talk to us. We still offer custom pricing for enterprise.

Once again, thank you all for your great feedback. We want to continue the conversation. Feel free to chat here, in discord, or in private.

Mike

[kontosa]

Thanks Mike,
appreciate your feedback to help clarify the team's position. I can take this info to our leads for further feedback.

Re pricing

Per user - doesn't allow for infrequent users - all users are priced equally. If you'd rather we just charged per user - I'd love to hear it.

I think we just need to get used to this model - it is fairer than a blanket per-user model and as you note is beneficial for infrequent usage to reduce costs.
Could you provide further additional info re this on the Pricing pages - i.e. some comparison examples to a per-user model cost for ease of financial planning?

Re authentication
Thx @bluepuma77 who mentioned other services using 'auth' as a 'tier-selector' (to me always feels more like a cynical enterprise-prodder . [most services:] 'Oh, you want security?' [Everyone:] Well, yes.)
I'm sure this was a deliberate decision - please keep it. In our case we will need self-hosting for .gov customers and Azure-AD auth via OICD. And we would want to evaluate that from the initial stages. Having it available from the open-source plan is ideal.

Craig.

[avivkri]

I've been waiting eagerly for the custom components but I'm disappointed that the number of plugins is restricted to just 10 for the free plan with the recent introduction of pricing changes. When the plugins are like custom extensions contributed by the community through the hackathon or individual developers who may sell it, I feel that such a restriction is too limiting. The fact the plugins are not per app but global makes it even more limiting. Please let me know if I understand this right.

I humbly request you reconsider restricting plugins behind the paywall.

[melohagan]

I might be biased 😄, but In my opinion 10 plugins on the free plan is quite generous. Most users will only need a handful of plugins to fill in the gaps that were missing, if any, for building their applications.
In regards to the hackathon event, the limit might be a little inconvenient for those building lots of plugins, but it's very easy to remove plugins you are no longer working on (and re-import plugins) as needed.

[JayP718]

@melohagan I agree, I think it's generous compared to other companies who have a freemium pricing model. Budibase has to eat too :)

I would agree it would be cool if we can buy extra plugin slots maybe? Especially for someone who doesn't need all the other features which will be added to budibase pro.

[fernandocalsa]

First of all, congratulations for this new version, it is a huge achievement, and I'm sure it will push BB as one of the most important Low Code platforms in the market.

I have some questions about it:

1. How can we upgrade to version 2.0 from a self host BB? Are the apps compatible, so if we create a new instance of BB 2.0 and export the apps would work alright?
2. How do you check that in a self host instance there are no more than 10 plugins? or there are no more than x day-passes? I can imagine that you require a connection from the BB instance to your servers, but in many cases we choose self host version because we have strong connection requirements, so we can not open the connection to the Internet. How will you manage it?

Thanks for your time and great effort, this project is improving our day to dat work, and it will do it even more with this upgrade!

[feurer98]

Happy mixed feelings with the release of 2.0

I find the functionality of the plug-in interface great and have already explored it a bit.
Currently there is a proposal from me to use BB in our business. This is because our infrastructure urgently needs an update.

I also criticise the pricing again. If we set up a time recording system, then every person (5-8 people at the moment) is logged in at least every day 1-2.
A quick calculation: On average 7 persons * 5 days/week * 4 weeks/month = 140 day passes.
I understand very well that you also have bills and development costs to cover. But I would rather think about limiting the size of the project (e.g. measured by the total memory of the apps).
This would mean that smaller companies could use the free version of the app for longer. However, with growth and more turnover, they would have to subscribe to a higher plan.
However, the small private persons or farms with already low budgets could continue to work with it.

In summary, for me the focus is on the mainstream. But if the masses are not prepared to pay, the "larger" companies will never have people who want to work with it.

---

Apart from that, I only noticed one error, which was caused by the update to 2.0. It is no longer possible to fill in additional columns for users in the app. As far as I know, this was still possible in version v1.4.16.

[mjashanks]

Hi @feurer98 what do you think would be a fair price to pay for your 7-user scenario?

Are you saying that this scenario should be possible on our cloud free tier? That's ok if you think that by the way!

I am genuinely trying to gather feedback here.

Thank you :)

[feurer98]

I think that the target audience to cover the big money and thus your work should not meet the small ones.

In short, we would have to pay 1632/year according to the current structure. And I don't know how I could convince my boss to do that. In a company you try to keep the running costs as low as possible. I estimate that 100/year per employee could be convincing. So we would be at about 700-800 for such a team.

What I see as an option here is to get people to upgrade via the plugin interface, as is already the case. But even there, I would have spared the small users there by allowing a "plugin number upgrade" to be completed separately from a user subscription.

I imagine the following scenario:
As a developer, I want to develop and test the tool, I don't know the technology behind it yet and I'm still suspicious. How do I sell the tool to the team leader if I can't present our case because I already need the team subscription for my intended use?

But can I test and build it first, can I say look this is how it works, let's do it? Costs 800/year for the team of 7 people.
After a year, the team, demands and budget have increased: look cheff for these adjustments we need more plugin interfaces (200/year) plus more users + 100/user/year.

So the price grows with the size of the application. But of course this can then also do more and relieve the burden on operations.
Of course, I would be happy if the option were still free for our team. But I still have to say that there is a lot of work behind it and that free would almost be an exploitation.

---

What I'm trying to do from the sale side:
To get into bigger companies, you need a broad mass which the "bigger" companies bring in (because they know the tools (Budibase)).
But it doesn't help much if the pricing scares the masses away.

[mjashanks]

Awesome feedback! Really appreciate the thought that you've put into this. Thank you.