Have something to say?

Tell us how we could make the product more useful to you.

Planned

Make Unused Monthly Messages & Integration Credits Rollover to the next month

Your monthly messages and integration credits stay with you when you don’t use them and rollover to the next month and continue to accumulate. This helps for big launches and more complex apps and also puts Base44 in line with what market leaders like Bolt are already doing in the vibe coding space. I’m adding here screenshots from Bolt for reference and the link to their post about this on X. Obviously people love this and it’s a win-win for both parties. Happy customers = loyal customers. This just gives people more power to build, which is what the people naturally and logically want. It is not a coincidence that Bolt has over 5 Million users and in this in particular we can learn from them to improve Base44 on this front. Link to post on X: https://x.com/boltdotnew/status/1930625733409362041

Mauricio Rubio 9 months ago

24
💡

Feature Request

Ability to NOT use credits for fixing items you've already asked it to do.

When I give it a command to create something and it tells me it’s implemented, but when I test it, it’s not, I shouldn’t have to use another credit to tell it to fix it again. In the conversation, when it outlines what it’s done, there should be a fix button that you click for it to fix that feature and not having it cost a credit. I also noticed that when it’s done implementing something, it doesn’t automatically preview the app, and I have to tell it, which then costs me another credit. I think that’s called credit gouging.

JRK007 9 months ago

40
💡

Feature Request

Planned

Feature Request: Native Push Notifications Support

Hi base44 Team, TL;DR: Need to send mobile push notifications, but I'm blocked because the platform prevents me from registering the required Service Worker. Static files (/sw.js) are not permitted, and dynamic (blob:) Service Workers are blocked by mobile OS security policies. The Problem: My app's core functionality relies on sending reminders to users when the app is closed. This is standard for modern web apps but is currently impossible on base44 due to the following technical limitations: Service Worker Failure: Cannot register a Service Worker, which is essential for receiving push messages in the background. Static file paths like /sw.js are not allowed. Dynamic registration via blob: URLs is blocked on mobile with a protocol not supported error. Missing Infrastructure: There's no backend integration to manage push subscriptions (device tokens) or handle VAPID key authentication. The Request: Please add a native push notification feature to the platform. An ideal solution would be a simple integration (SendPushNotification) that automatically handles the complex Service Worker registration and subscription management in the background. This is a critical feature for building engaging, modern applications. Any information on your roadmap for this would be greatly appreciated. Thank you.

זאב ליפשיץ 7 months ago

104
💡

Feature Request

Feature Request: Root-level sw.js Hosting for Enhanced Push Notifications

Our application is implementing push notifications, and we've encountered a crucial requirement for Android devices: for notifications to be received when the app is closed, the service worker file (sw.js) must be directly accessible at the app's root directory (e.g., your-app-domain.com/sw.js). Currently, the Base44 platform's file structure doesn't seem to allow placing files directly in a public root directory. This limitation prevents us from fully leveraging push notifications for our Android users. We would greatly appreciate it if Base44 could provide a solution for this. Is it possible to: Allow developers to place custom files like sw.js at the app's root? Offer a mechanism for Base44 to host our sw.js file at the root path? Thank you for considering this enhancement!

howmoo2015 22 days ago

💡

Feature Request

Completed

Baked In Payment Solution, no more Stripe payment setup pain

So THE key value proposition from Base44 has always been and continues to be: being an all-in-one solution with baked in auth, db, email sending and AI. BUT, the missing piece of puzzle is payments (app monetisation). Because it’s currently working more like a third party integration where you have to go and manually setup the payment solution, like you would with other vibe coding apps that rely on third party integrations for everything (which is exactly what makes them so painful). Base44 should apply the same design/architecture principle they have applied for everything else, but also for the payments solution, so that non technical users (so 99.5% of the market -according to the latests stats from Grok: https://grok.com/share/bGVnYWN5_d8e0059d-d3a0-4633-b335-ab36bb914741 ) don’t have to worry about things like “back end functions,” webhook this, webhook that or trying to integrate with things like Zapier or RevenueCat which might be “simple” for a Dev but are not for a non technical vibe coder. I know, I have tried doing it multiple times, multiple ways and it just hasn’t worked for me at all. Even when I used the Stripe integration from Base44 (in Alpha release) it wasn’t pulling the data from Stripe even though it said it had successfully connected and it just wasn’t working. I have wasted countless hours on this. So I don’t want to waste time on things like this, I just want it baked in like everything else. The closest I’ve seen to what I want and what Base44 should have is seen on this video from Cosmic: https://x.com/samuelp4rk/status/1930728398902772101 -as you can see in the video they have a baked in payments solution (built using Stripe under the hood), BUT they don’t have free trials on it, which is crucial of course. So Base44 could learn from this and implement something similar but better that actually considers the classic/frequently used use case of 7-day free trial, collects payment details up front, automatically charges the user when the trial expires, removes app access when they cancel (if they cancel). So the logic/sync between user, payment/trial, access to the app, auth and db needs to work under the hood and be baked in. Given people don’t build things just for the sake of building things but more because they aspire to achieve financial freedom so they can decide what to do with their time, monetisation and having baked in payments is THE #1 Problem to Solve for Base44. It is THE key missing piece of the puzzle for Base44 to level up and I would give this priority above everything else.

Mauricio Rubio 9 months ago

4
💡

Feature Request

Higher Security and EU Data Residence

Hello, With GDPR will there be a possibility that the data don't leave the EU? And are more secured. Cause we can not sell if data are getting transferred to the US. So no AI should be trained and not data leave EU or are entered by Base 44. Is there any chance that the data will remain entirely within the EU? When GDPR and SOC 2 compliance are implemented, will the data stay in the EU? Additionally, is it possible — within an enterprise setup — to fully isolate the data from all third-party servers to ensure higher security? Regarding the backend: as far as I can see, the processing currently takes place in the U.S. Even if another server is used, the code indicates that BASE44 can reroute traffic to another server if it becomes overloaded. Does the backend get transferrend too, when bring your own Database is out? We need a own server or data not leaving the EU. Not Even for Processing. Will that be possible? We need a secure, EU-based, and fully compliant solution with clear transparency and control policies. Otherwise it will be hard to sell apps built with Base44 in the EU.

Website Excellence Builders 5 months ago

30
💡

Feature Request