Hi Base44 team and community, I'm the founder of InsurMatch (insurmatch.de), a B2B matching platform for the German insurance industry built entirely on Base44. I love the platform — but I've hit a wall that genuinely threatens my business model. The problem: Base44 apps are rendered client-side (SPA/React). Search engines and crawlers receive an empty HTML shell until JavaScript executes. This means: Google indexes pages slowly or incompletely Tools like NotebookLM, Perplexity, and Bing fail to read my content entirely Organic SEO — which is central to my go-to-market strategy — is severely limited Real impact: After weeks live, only a few subpages are organically discoverable via Google. My entire business model relies on insurance companies and service providers finding InsurMatch through search. Without SSR or pre-rendering, this is a structural blocker — not just an inconvenience. What I'm asking for: Server-Side Rendering (SSR) or Static Site Generation (SSG) for Base44 apps Or at minimum: pre-rendering / dynamic rendering for crawlers This isn't a nice-to-have. For any Base44 user building a public-facing platform, marketplace, or content site — this is a dealbreaker. I'd love to know if others are experiencing the same issue and how many votes this gets. Who else is affected? If you're building a public app on Base44 and care about SEO — please upvote or comment. 🙏 — Tobi

Tobias Kelm about 6 hours ago

💡

Feature Request

Extremely frustrating and seems so obvious it must be an oversight that can be fixed. When building with a Superagent, users develop a long-term context, memory, and working relationship with their agent — knowledge files, project history, business logic, custom skills. Currently, if you want to graduate your project to the App side (for auth, custom domains, scaling), you lose access to that agent entirely. The App side only has a generic AI editor with no memory or context. Feature request: Allow a Superagent to be connected to an App-side project as the designated AI collaborator — so the same agent (with full memory and context) can push code changes, debug, and build features through the Superagent chat interface, with changes reflected in the App-side project.

Erica Moyer about 9 hours ago

💡

Feature Request

The Superagent chat interface sends a push notification to my device every time the agent responds to a message during an active conversation. This creates a notification loop during any working session — I receive dozens of notifications per hour simply by having a back-and-forth conversation. This makes reminder automations unusable and the chat interface disruptive. Request: add a notification setting to suppress chat message pings during active sessions, or only notify when the chat window is not in focus. How do i stop this?

Joseph Petrovich about 17 hours ago

💡

Feature Request

package names can not be changed within base44 but to get my app accepted on google play i need to be able to change it to a specific name as the one set by base44 is been rejected

Dan Barker about 19 hours ago

💡

Feature Request

One of the biggest opportunities within Base44 is enabling teams to move from building projects to building reusable systems. Right now, when working across multiple projects, there is a lot of repeated effort rebuilding similar logic, flows, and backend structures. This becomes a major bottleneck for agencies and companies operating at scale. What would be incredibly powerful is the ability to save, store, and reuse entire sections of functionality across projects not just components, but complete working systems. What this could look like: Save full feature sets such as: Ecommerce backends CRM workflows Automation engines Dashboard systems Store these in a centralised workspace library A single place where teams can maintain their proven systems and deploy them when needed Enable plug and play importing into new projects Drop in a system and have it immediately functional with minimal setup Add context awareness on import Automatically adapting to: Project structure Environment variables Schema differences Naming conventions Allow fast reconfiguration and rebranding So the same underlying system can be reused while quickly adjusting UI, styling, and business rules Real world example: An agency builds a bespoke ecommerce backend once. Instead of recreating it for every client, they can reuse that same system across projects, only adjusting branding and edge case logic. What used to take days becomes something that takes minutes. Token usage consideration: A potential concern might be reduced token usage if teams reuse systems instead of generating from scratch. However, this can be solved by introducing a token weighted reuse model. For example: When a module or system is created, Base44 assigns it a token value based on its complexity Each time it is reused or imported, a proportional token cost is applied This ensures: Base44 maintains a fair and scalable usage model Users still benefit from speed and efficiency Pricing aligns with the value of the system being deployed Why this matters: Eliminates repetitive build work across projects Enables teams to create their own internal frameworks Increases speed of delivery significantly Improves consistency and quality across builds Positions Base44 as a true system builder, not just a project builder This would fundamentally change how teams use Base44, shifting from one off builds to scalable, repeatable product infrastructure.

Jandyr 1 day ago

💡

Feature Request

According to the ai chat screenshots I’ve attached this is a platform request I wish to make. 1. 2. 3. 4.

Thomas Iozzo (James Thistle) 1 day ago

💡

Feature Request

Olá boa noite, estou enfrentando sérios problemas para disponibilizar meu aplicativo na apple store considerando a falta de integração do base 44 com story kit. Para fazer todo processo que é necessário exige um conhecimento técnico avançado, seria interessante uma integração direta do Base 44 com a apple para facilitar esse processo de cobranças dentro do app.

João Batista Junior 1 day ago

💡

Feature Request

You all SERIOUSLY need to add a extra credit buying feature to float people until their next subscription date, its ridiculous to have to double the price when people dont need that many credits to finish a project, you all might want to do this because when your competitors do, you will see a mass exit from your platform

Terrence Johnson 1 day ago

💡

Feature Request

Currently, all credits in a workspace are pooled together and consumed from the workspace owner's plan. I'd like the ability for individual workspace members (e.g. engineers, collaborators) to connect their own paid Base44 plan and have their edits/prompts consume credits from their own account rather than the workspace pool. This would be especially useful when bringing on external contributors or contractors who want to pay for their own usage without relying on the workspace owner's credit balance. It would make collaboration more scalable and flexible for teams of all sizes.

jayden “Dior” dior 1 day ago

💡

Feature Request

Hi Base44 team and community, ​Currently, apps built on Base44 using a custom domain (e.g., mydomain.com) face a significant limitation: backend functions are only accessible via Base44 system URLs, such as api.base44.com/... or app--.base44.app/.... ​While this works on a technical level, it creates a critical SEO and User Experience (UX) issue when trying to generate dynamic Open Graph (OG) tags for social media platforms (X/Twitter, Facebook, WhatsApp, etc.). ​The issue in detail: If we use a proxy function to generate metadata (title, image, description) when sharing a user's public profile or an event, the link displayed on social media and crawled by bots belongs to api.base44.com, not our custom domain. ​This has two severe consequences for any builder: ​Loss of SEO Authority (Backlinks): All external links shared on social networks pass the domain authority to Base44, rather than building authority for our own brand/domain. ​User Distrust (UX): Seeing a generic API link instead of the app's official domain drastically lowers the Click-Through Rate (CTR), as it looks like a suspicious or unprofessional link. ​Proposed Solution: Enable native support for backend functions to be accessible via the app's associated custom domain. For example: mydomain.com/api/functions/myFunction or mydomain.com/_functions/myFunction ​This is an industry-standard feature (available on Netlify Functions, Vercel API Routes, Supabase Edge Functions, etc.) and is absolutely vital for any public web app that relies on organic traffic and social media virality. ​If you are building a directory, a marketplace, a blog, or any app with public profiles on Base44, please upvote this request so the team can prioritize it. Thank you!

Busca Bolos 1 day ago

💡

Feature Request

Hola comunidad y equipo de Base44, ​Actualmente, las aplicaciones construidas en Base44 que utilizan un dominio personalizado (ej. midominio.com) tienen una limitación importante: las funciones de backend solo son accesibles a través de las URL de sistema de Base44, como api.base44.com/... o app--.base44.app/.... ​Aunque esto funciona a nivel técnico, genera un problema crítico de SEO y de Experiencia de Usuario (UX) cuando intentamos generar etiquetas dinámicas Open Graph (OG) para redes sociales (X, Facebook, WhatsApp, etc.). ​El problema detallado: Si utilizamos una función proxy para generar los metadatos (título, imagen, descripción) al compartir el perfil público de un usuario o un evento, el enlace que se visualiza en la red social y al que apunta el crawler pertenece a api.base44.com, no a nuestro dominio. ​Esto tiene dos consecuencias graves para cualquier creador: ​Pérdida de Autoridad SEO (Backlinks): Todos los enlaces externos compartidos en redes sociales transfieren la autoridad de dominio a Base44, en lugar de a nuestra propia marca/dominio. ​Desconfianza del usuario (UX): Al ver un enlace genérico de API en lugar del dominio oficial de la app, la tasa de clics (CTR) baja drásticamente porque parece un enlace sospechoso o poco profesional. ​Solución propuesta: Habilitar el soporte nativo para que las funciones de backend sean accesibles a través del dominio personalizado asociado a la app. Por ejemplo: midominio.com/api/functions/miFuncion o midominio.com/_functions/miFuncion ​Esta es una funcionalidad estándar en la industria (disponible en Netlify Functions, Vercel API Routes, Supabase Edge Functions, etc.) y es absolutamente vital para cualquier aplicación web pública que dependa del tráfico orgánico y la viralidad en redes sociales. ​Si estás creando un directorio, un marketplace, un blog o cualquier app con perfiles públicos en Base44, por favor, vota esta sugerencia para que el equipo la priorice. ¡Gracias!

Busca Bolos 1 day ago

💡

Feature Request

Hello, I can't upload my app to Google Play because it includes camera access permissions. However, my app doesn't use the camera. Therefore, I need to remove the camera access permission, but I can't do this manually, neither with AI nor with me. What do you think I should do?

Ketzilla 2 days ago

💡

Feature Request

It be nice if we had an agent that could make follow up calls and more

DENNIS BRENNAN 2 days ago

💡

Feature Request

The superagent would be a lot more useful for what I need if it could take screen recordings, not just screenshots. Additionally the app building part would be a lot better if it had an “undo” button. Its a hassle trying to get the ai to go back and undo certain things.

Audrey Tate 2 days ago

💡

Feature Request

on the free plan, collaborators that do not own the workspace cannot edit anything with ai, even if they have editing permissions pls fix this

Life_Is_Nice 2 days ago

💡

Feature Request