Integration details
Description
Buildfire helps app owners manage their Buildfire apps from ChatGPT. Users can list accessible apps, inspect installed features, search users, create users, assign or remove tags, review app and plugin analytics, inspect plugin memory, find push notification groups, and schedule push notifications with confirmation-oriented dry runs.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Category
- Pending
- Primary Subcategory
- AI App & Website Builders
- Secondary Subcategories
- None listed
- Brand
- BuildFire
- Access
- Account required
- First tracked
- 2026-04-07
- Tool count
- 19
- Geography
- US
The broad Category that contains the Primary Subcategory.
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Get alerts for Buildfire
Get updates when Buildfire’s Discoverability Score or category rank changes.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like
Competing in ChatGPT AI App & Website Builders
View Category19 tools agents can invoke
Assign one or more tags to a user in an app. Use this when the app owner wants to add a user to a segment, group, audience, permission set, or tagged workflow. This tool modifies user/tag membership. It is NOT read-only. MANDATORY SAFETY RULE: Do not call this tool until the app owner confirms the target user and tags. Before calling this tool, show the app owner: Tag Assignment Summary: • App: [friendly app name] • User: [username/email/display name] • Tags to assign: [tag names] Then ask: "Should I assign these tags to this user?" Only call this tool after the app owner confirms. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Resolve the target user with list_users when needed. - Use username internally. - Show friendly user and tag details.
assign_user_tags
Create a new user in a Buildfire app. This tool creates a real user account. It is NOT read-only and it is NOT idempotent. MANDATORY SAFETY RULE: Do not call this tool until the app owner clearly confirms the new user details. Before calling this tool, show the app owner: New User Summary: • App: [friendly app name] • Email: [email] • Display name: [display name if provided] • First name: [first name if provided] • Last name: [last name if provided] • Profile fields: [summary if provided] Then ask: "Should I create this user?" Only call this tool after the app owner confirms. SECURITY: - Never display the password back to the app owner. - Never log or summarize the password in user-visible output. - Do not invent a password unless the app owner explicitly asks you to generate one. - If generating a password, make it strong and remind the app owner to store it securely. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Use appId internally. - Show friendly app/user details, not internal IDs.
create_user
Fetch analytics metrics for selected app events in a single request. Use this for app-level analytics dashboards, comparisons, summaries, and mixed analytics requests across system events, plugin events, tags, and action-items. This tool is read-only. It only reads analytics metrics. It does not create, update, delete, publish, send notifications, or modify app data, plugin data, users, tags, or analytics records. IMPORTANT LIMITATIONS: - Maximum 20 items per request. - Never fetch "all data" without the app owner specifying specific events, plugins, tags, or a clear business question. - For broad requests, ask the app owner to narrow the scope before calling this tool. ANALYTICS TYPES: - daily: Requires fromDate and toDate on each item. - monthly: Requires toDate on each item. - all-time: Use analyticsType "monthly" with only toDate and set metric.showAllTimeData to true when supported. ITEM ROUTING: - System events: use eventName. - Tag events: use tagName and eventName will be converted to app/tagAssigned/{tagName}. - Custom plugin/action-item events: use pluginId and instanceId, or pluginName only when it can be uniquely resolved. GOLDEN RULE - NEVER expose: - appId - pluginId - instanceId - technical eventName keys - raw ISO dates unless explicitly requested ALWAYS show: - Friendly metric names - Friendly app/feature/tag names - Human-readable time range - Clear totals and trends
get_app_analytics_bulk
Get the appearance, visual theme, branding, and installed-device identity for a specific app. Use this tool when the app owner asks about: - The app's theme or design - Theme colors - Background, header, title bar, icon, status, warning, success, or footer colors - The app's font family or font weight - The app icon - The splash screen - The name displayed on the user's phone after installation - The app's home-screen or launcher plugin - Custom login-screen styling - Registration-screen configuration - PWA page layout - Whether custom CSS is enabled - Draft versus published appearance settings This tool is read-only. It only reads the app's appearance configuration. It does not modify colors, fonts, icons, splash screens, layouts, plugins, login settings, registration settings, custom CSS, or any other app data. VERSION HANDLING: - When published is false or omitted, return the draft appearance configuration. - When published is true, return the published/live appearance configuration. - Clearly tell the app owner whether the result is from the draft or published version. IMPORTANT FIELD MEANINGS: - colors contains the app's visual theme and component colors. - fontName identifies the font family used by the app. - fontWeight identifies the configured font weights. - launcherPlugin identifies the plugin instance used as the app's home screen. - launcherPluginType identifies the type of plugin used as the home screen. - iconUrl is the preferred app icon. - androidIconUrl should only be used as a fallback when iconUrl is unavailable. - appName is the name displayed on the device after the app is installed. - appName is not necessarily the public Apple App Store or Google Play listing name. - The public store-listing names must come from the separate app publishing/store-information tool. - splashScreen is the image displayed while the app is starting. - customLoginUI describes custom login-screen branding and styling. - customRegistration describes registration fields and registration-screen behavior. - pwaPageLayout describes the Progressive Web App page layout. - customCSS.active indicates whether custom CSS is enabled. RESPONSE GUIDANCE: - Explain the app's appearance in plain English. - Summarize the overall visual identity when useful. - Include exact color values when the app owner asks about colors or design details. - Prefer iconUrl over androidIconUrl. - Describe the launcher plugin using its friendly title and plugin type name. - Show image URLs when the app owner asks for the icon, splash screen, or other branding assets. - Do not describe appName as the App Store or Google Play name. - Do not claim that draft settings are currently live. - Avoid exposing raw datastore metadata or internal record IDs unless the app owner explicitly requests technical details. GOLDEN RULE: Do not ask the app owner for appId when the app can be resolved using list_apps. Use appId internally and show friendly app names in the response.
get_app_appearance
Get the Apple App Store and Google Play publishing configuration for a specific app. Use this tool when the app owner asks about: - The Apple App Store listing name - The Google Play listing name - Apple or Android publishing information - Store descriptions - Store categories - Apple keywords - Apple support or marketing URLs - Whether Apple or Android publishing is enabled for the app - Apple Developer Program setup - Apple Store Connect access - Google Play Console setup - Firebase certificate setup - Android certificate setup - Publishing account invitations - Store contact information - Store content-rating answers - Whether the customer indicated that the app already exists in either store - Draft versus published publishing configuration This tool is read-only. It only reads publishing configuration. It does not submit the app, publish the app, update store information, create certificates, invite accounts, or modify Apple App Store or Google Play data. VERSION HANDLING: - When published is false or omitted, return the draft publishing configuration. - When published is true, return the published/live publishing configuration. - Clearly tell the app owner whether the result is from the draft or published version. - Do not describe draft information as currently live. IMPORTANT STORE-NAME FIELD MEANINGS: - apple.appName is the intended Apple App Store listing name. - android.playStoreTitle is the intended Google Play public listing name. - android.googlePlayAccountName is the Google Play developer account name. It is not necessarily the public Google Play app title. - The installed-device app name comes from get_app_appearance, not this tool. IMPORTANT DESCRIPTION FIELD MEANINGS: - storeDescription is the Apple App Store description. - androidStoreDescription is the Google Play description. - apple.keyword contains Apple App Store search keywords. - apple.category contains the selected Apple App Store category. - android.category contains the selected Google Play category. - android.shortDescription contains the Google Play short description. PLATFORM FIELD MEANINGS: - useApple indicates whether Apple publishing is configured for the app. - useAndroid indicates whether Android publishing is configured for the app. - apple.isAppAlreadyInAppStore records whether the customer indicated that the app already exists in the Apple App Store. - android.isAppAlreadyInGooglePlay records whether the customer indicated that the app already exists in Google Play. - These fields are submitted publishing configuration values. They do not independently verify that the app is currently approved, publicly listed, or available for download. PUBLISHING-SETUP FIELD MEANINGS: - apple.appleDeveloperProgramEnrolled describes the submitted Apple Developer Program enrollment status. - apple.iosFirebaseCertCreated describes the submitted iOS Firebase certificate status. - apple.appleCertsForFirebaseProjectAdded describes whether Apple certificates were added to Firebase. - apple.appleStoreConnectManagerAdded describes whether Buildfire publishing access was added in App Store Connect. - android.googlePlayAccountCreated describes the submitted Google Play account status. - android.googlePlayFirebaseCertCreated describes the submitted Google Play Firebase certificate status. - android.googlePlayAccountAdded describes whether publishing access was added. - android.isAndroidCertExists describes the submitted Android certificate status. - google.googlePlayAccountUrl may contain an administrative Google Play Console URL. CONTENT-RATING INFORMATION: - Apple content-rating answers include violence, mature themes, medical information, gambling, alcohol or tobacco, sexual content, and related fields. - Android content-rating answers include violence, nudity, offensive language, drugs, interaction, personal information, location, digital goods, and related fields. - Report these values as submitted publishing answers, not as independent legal, policy, or compliance conclusions. PRIVACY AND SENSITIVE INFORMATION: - Publishing contact information may include a person's name, phone number, and email address. - Publishing invitation fields may include Buildfire or customer account email addresses. - Administrative console URLs may provide access-related context. - Do not expose phone numbers, personal email addresses, invited-account emails, or administrative console URLs unless the authenticated app owner explicitly asks for those details. - When the user asks for a general publishing summary, provide store names, descriptions, categories, platform configuration, and setup status without displaying sensitive contact or account-access details. - Never expose passwords, tokens, certificates, private keys, or credentials. This tool should not return those values. RESPONSE GUIDANCE: - Use Apple App Store and Google Play as separate sections. - Clearly identify the Apple listing name from apple.appName. - Clearly identify the Google Play listing name from android.playStoreTitle. - Do not use android.googlePlayAccountName as the public app name. - Explain whether Apple and Android publishing are enabled. - Summarize descriptions, categories, keywords, support URLs, and setup statuses when relevant. - Preserve Yes, No, and other submitted status values accurately. - Do not convert a Yes or No setup answer into a verified external fact. - Do not claim the app is currently live, approved, rejected, or publicly available unless that status is explicitly verified by a separate authoritative source. - Avoid exposing raw datastore record IDs or internal app IDs unless the app owner explicitly requests technical details. GOLDEN RULE: Do not ask the app owner for appId when the app can be resolved using list_apps. Use appId internally and show friendly app and store-listing names in the response.
get_app_publishing_info
Get the total number of registered users in an app. Use this when the app owner asks how many users, members, signups, or registered users an app has. This tool is read-only. It only reads a user count. It does not list full user records, create users, update users, assign tags, remove tags, or modify app data. Use this instead of list_users when the app owner only needs a count.
get_app_users_count
Fetch daily analytics counts for a specific plugin instance event in a app. Use this when the app owner wants analytics for a specific feature/plugin event over a date range. Expected flow: 1. Resolve the app with list_apps if needed. 2. Resolve the feature/plugin with search_plugin_instances. 3. Discover available events with list_plugin_instance_analytics_events. 4. Ask the app owner for the time range if not already clear. 5. Convert the app owner's local time range to UTC. 6. Call this tool with the resolved internal IDs and eventName. This tool is read-only. It only reads analytics metrics and does not create, update, delete, or modify app data, plugin data, users, tags, notifications, or analytics records. TIME HANDLING: - fromDate and toDate must be UTC ISO 8601 strings. - Do not expose raw ISO timestamps to the app owner unless they explicitly ask. - Show human-readable dates in the app owner's local timezone. GOLDEN RULE - NEVER expose: - appId - pluginId - instanceId - eventName keys - raw ISO dates unless explicitly requested ALWAYS show: - App name - Feature name - Friendly event title - Human-readable date range - Total and daily counts
get_plugin_instance_analytics_daily
Get the number of users assigned to one or more tags in an app. Use this when the app owner asks: - How many users have a specific tag? - How large is a tagged segment? - How many users are in a target audience before sending a notification? This tool is read-only. It only reads counts for tag membership. It does not assign tags, remove tags, update users, create users, or modify app data. Use this instead of list_users when the app owner only needs audience size/counts.
get_tag_users_count
List available analytics event categories for an app. Use this before querying broad app analytics so the assistant can understand which metrics are available and choose the right follow-up tool. Returns: - System analytics events such as installs, opens, registrations, and sessions - Available categories such as custom plugins, tags, and action-items - Friendly titles and technical event names for internal use This tool is read-only. It only reads analytics metadata. It does not create, update, delete, or modify app data, plugin data, users, tags, notifications, or analytics records. PREVENT HEAVY REQUESTS: If the app owner asks for "all data" or another unbounded query: 1. Ask which specific features, events, or tags they want to analyze. 2. Ask what time period they want. 3. Only then fetch analytics for a limited set of events or plugins. TIME RANGE LIMITS: - Daily/monthly analytics should normally be limited to practical date ranges. - For long historical views, prefer all-time/monthly summaries when supported. GOLDEN RULE - NEVER expose: - Technical eventName keys unless explicitly requested - Internal event formats ALWAYS show: - Friendly event titles such as Opens, Installs, User Signups - Plain-English categories and descriptions
list_app_analytics_events
List installed plugin instances and app features for a specific app. Use this when the user asks what features/plugins an app has, wants to find a feature by name, or needs to select a feature before checking analytics, opening plugin memory, or creating a notification action. This tool is read-only. It only reads installed app features. It does not modify the app, publish features, update plugin data, send notifications, or change user data. Do not ask the user for appId directly if the app can be resolved from list_apps. If multiple apps match, ask the user to choose by friendly app name.
list_app_features
Search for and list individual user records in an app. Use this when the app owner needs actual user records, such as names, emails, usernames, devices, signup dates, or users matching a search/tag/date filter. ROUTING: - For total app user count: use get_app_users_count. - For user count by tag: use get_tag_users_count. - For actual user records: use this tool. This tool is read-only. It only searches and reads users. It does not create users, update users, assign tags, remove tags, send notifications, or modify app data. TIME / DATE FILTERING: - minSignUpDate and maxSignUpDate must be provided together. - Dates should be UTC ISO 8601 strings when possible. - Do not expose raw internal timestamps unless the app owner asks for technical detail. TAG FILTERING: - If tags are provided, searchTagsCriteria is required. - Valid criteria should match supported behavior, such as includesAll, includesSome, excludeSome, or excludeAll. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Use appId internally. - Show user results in a friendly way. - Avoid exposing unnecessary internal IDs unless needed for a follow-up action.
list_users
List the apps the authenticated app owner can access. Use this as the first step when the user asks about their apps, users, notifications, analytics, plugins, or app features and you need to resolve which app they mean. This tool is read-only. It does not create, update, delete, send notifications, or change app data. Return the app list with friendly app names and IDs so the assistant can silently use the correct appId in later app-specific tools. Do not ask the user for an appId when the app can be selected by name.
list_apps
Discover what analytics events are available for a specific plugin feature. Use this after resolving the plugin instance through search_plugin_instances. Do not ask the app owner for technical event keys. This tool returns: - Built-in event: "Opened" with key app/openedPlugin - Custom plugin events with friendly titles and descriptions Each event key is the exact value to pass internally as eventName to get_plugin_instance_analytics_daily and search_plugin_instance_event_users. This tool is read-only. It does not create, update, delete, or modify analytics, app data, plugin data, users, tags, or notifications. GOLDEN RULE - NEVER expose to the app owner: - appId - pluginId - instanceId - event key values like app/openedPlugin or custom event keys ALWAYS show the app owner: - Friendly event title, such as Opens, Messages Sent, User Joined - Event description when available DISAMBIGUATION: If multiple events are available, present friendly titles only and ask which event they want to analyze.
list_plugin_instance_analytics_events
Discover the operations a plugin exposes. Different plugins expose different capabilities — a Locations plugin can search locations by title or near a point, a Task Manager can list a user's tasks, a Chat plugin can read rooms and messages. Every operation is read live from that plugin's own published contract, so this list is whatever the plugin currently exposes; it is not a fixed set, and a plugin with no published contract has no operations here. Expected flow: 1. Resolve the app with list_apps and the feature with search_plugin_instances to get the pluginId. 2. Call this tool with that pluginId to list its operations. 3. Run the chosen operation with the tool that matches its "crudMode": run_plugin_read_operation, run_plugin_create_operation, run_plugin_update_operation or run_plugin_delete_operation. Returns, for each operation: the operation name, a description, its parameter spec (name, type, required, sampleValue), and: - "crudMode": what the operation does to data — "read", "create", "update" or "delete". This is which of the four run tools accepts it; each one refuses the other three. - "paramsSchema": the same params as JSON Schema, with additionalProperties false — build the "params" object from it rather than guessing names. - "write": true for create, update and delete. - "type": how it runs — "datastore", "publicData", "userData" or "appData" for declarative data access, "function" for one implemented in the plugin's own code, or "firebase" for a query against the plugin's firestore project. - "host": where the operation is declared to run — "generic" or "headlessSdk" run here; "controlForeground", "controlBackground", "widgetForeground" and "widgetBackground" do not (the plain "control"/"widget" spelling reads the same as its *Background variant). The Foreground/Background half says whether the operation expects someone watching the app while it runs. None of these four is invocable here — see "invocable" below — so never offer one; if asked, explain that it only runs inside the app itself. - "surface": the buildfire API the operation reads or writes through, when it is a declarative one. A "userData" operation reads one app user's own records, and there is no signed-in app user here, so it takes a "userToken" (or "userId") param naming whose records to read — resolve that user first rather than guessing. - "displayName": a human-readable label for the operation. Use it when telling the app owner what you are about to do. - "flags": what the plugin says about the operation. The five it may set are "mutating" (or "mutable" — changes data), "dangerous" (can destroy or expose more than the request implies), "throttable" (rate limited — run it once, never in a loop), and "control"/"widget" (it belongs to the app builder or the app itself, so running it from here may not be what the owner expects). - "warnings": those flags written out as plain sentences. Relay them to the app owner in your own words before running the operation — do not summarise them away. - "needsOwnerAction" and "ownerActions": true when the operation carries any flag, with what the app owner will be asked to do about each one — tick a box to apply a change, type the operation's name for a dangerous one, accept that it belongs to another side of the app. The server asks them itself; you do not need to collect these. - "invocable" and, when false, "notInvocableReason" — some declared operations cannot run through a single MCP call: live listeners/subscriptions, transactions, bulk writes, and any "function" operation whose code is restricted to a frame in the app (only code declared for a "generic" or "headlessSdk" host runs here). Do not offer those; if asked, explain the operation exists but cannot be run from here. The list may also report the plugin's "events" — what that plugin announces when something happens, with the data each carries. Events are not operations and cannot be invoked; they are context for understanding the plugin's data. This tool is read-only; it only describes capabilities and does not read or modify any app data. If the plugin has not published a contract, an error says so — that plugin exposes nothing here yet.
list_plugin_tools
Search for push notification groups in an app. Use this to resolve a friendly group name to a group ID before scheduling a push notification to a specific audience. This tool is read-only. It only searches push notification groups. It does not create, update, delete, send, or schedule push notifications. Use this when the app owner says things like: - Send this to the internal group - Send it to group 1 - Which push groups do I have? - Send it to the members group If multiple groups match, show the friendly group names and ask the app owner which one they mean. GOLDEN RULE: - Do not ask the app owner for group IDs. - Use the group ID internally only. - Show friendly group names to the app owner.
list_push_notifications_app_groups
Remove a tag from a user in an app. Use this when the app owner wants to remove a user from a segment, group, audience, permission set, or tagged workflow. This tool modifies user/tag membership and removes an existing relationship. It is NOT read-only and it may affect app behavior, permissions, audience targeting, or notification eligibility. MANDATORY SAFETY RULE: Do not call this tool until the app owner confirms the target user and tag to remove. Before calling this tool, show the app owner: Tag Removal Summary: • App: [friendly app name] • User: [username/email/display name] • Tag to remove: [tag name] Then ask: "Should I remove this tag from this user?" Only call this tool after the app owner confirms. GOLDEN RULE: - Do not ask the app owner for appId if the app can be resolved by name. - Resolve the target user with list_users when needed. - Use username internally. - Show friendly user and tag details.
unassign_user_tags
Schedule a push notification for users in an app. This tool creates or schedules a real push notification. It is NOT read-only and it is NOT idempotent. MANDATORY SAFETY RULE: Do not call this tool until the app owner clearly confirms the final push notification summary. Before calling this tool, show the app owner: Push Notification Summary: • Title: [push notification title] • Message: [push notification text] • Recipients: [Group name / user count / all devices] • Action: [Opens feature / web link / phone / email / none] • Sending: [Now / scheduled local time] Then ask the app owner for clear confirmation in your own natural wording. The confirmation question should sound conversational and match the context. Do not use a fixed scripted sentence. Examples of acceptable confirmation wording: - Does everything look good to send? - Want me to send it now? - Should I schedule this for you? - Ready for me to send this push notification? - Can I go ahead with this? Only call this tool after the app owner clearly confirms with yes, send it, go ahead, schedule it, or another clear approval. USER EXPERIENCE: Think conversationally, not technically. When the app owner wants to send a push notification: 1. Ask who should receive it. 2. Ask what the title/message should say. 3. Ask what should happen when users tap it. 4. Ask when it should send. 5. Resolve all IDs internally. 6. Show a final summary and wait for confirmation. RECIPIENT TARGETING: Option 1 - All devices: - User says everyone, all devices, all users, or all. - Do not set group_id. - Do not set users. Option 2 - Specific group: - Use list_push_notifications_app_groups to find the group. - If multiple groups match, ask the app owner which one. - Use group_id internally. - Do not set users. Option 3 - Specific users: - Use list_users to find the users. - If multiple users match, show the full friendly list and ask which users to target. - Use the selected user objects internally. - Do not set group_id. PLUGIN TAP ACTION: - If the app owner says the push notification should open a feature, use search_plugin_instances. - Never use a plugin name as instanceId. - Resolve instanceId internally and do not expose it. ACTION ITEM BEHAVIOR: - Default behavior: show the in-app message with the action as a CTA. - Only set autoExecuteActionItem true when the app owner explicitly wants the tap action to run automatically. TIME HANDLING: - sendAfter must be a future UTC ISO 8601 timestamp. - Convert the app owner's local time to UTC before calling this tool. - Do not expose raw ISO timestamps unless explicitly requested. - Show human-readable local time in the confirmation. GOLDEN RULE - NEVER expose: - appId - group_id - instanceId - actionItem objects - URL query strings - raw ISO timestamps unless explicitly requested ALWAYS show: - Friendly app name - Friendly group name or user count - Friendly feature/action name - Human-readable sending time
schedule_push_notification
Search user-level analytics event records for a specific plugin instance event in an app. Use this when the app owner asks who performed an event, which users opened a feature, which users triggered a plugin event, or similar user-level analytics questions. Important: - eventName must exactly match the key of one of the events returned by list_plugin_instance_analytics_events. - limit is capped at 15 to avoid heavy responses. - Use pagination with skip/limit when more records are needed. This tool is read-only. It only reads analytics event records and related user metadata. It does not create, update, delete, or modify app data, plugin data, analytics data, users, tags, or notifications. GOLDEN RULE - NEVER expose: - appId - pluginId - instanceId - eventName keys - raw ISO dates unless explicitly requested ALWAYS show: - Friendly feature name - Friendly event title - Human-readable date range - User names/emails when available
search_plugin_instance_event_users
Search for installed plugin instances/features by name inside a specific app. Use this when the app owner asks about a feature/plugin by friendly name, such as Chat, Community Wall, Places, Forms, or any installed app feature. Use this before: - Querying analytics for a plugin instance - Resolving where a notification tap action should open - Finding the correct pluginId and instanceId for a feature - Loading plugin memory for a selected plugin - Helping the app owner understand which features exist in an app This tool is read-only. It only searches installed plugin instances. It does not create, update, delete, publish, send notifications, or modify app data, plugin data, users, tags, or analytics. GOLDEN RULE - NEVER ask the app owner for appId, pluginId, or instanceId directly if they can be resolved by name. If multiple plugin instances match, show friendly feature names/titles and ask the app owner which one they mean.
search_plugin_instances
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Buildfire alternatives on ChatGPT?
As of 2026-09-28, Buildfire competes with Adalo, AI Roleplay Chat Simulator, Akwadra, AppDeploy, Base44, Charming, Craftian, Floot, FluxBuilder, FreakUI, GoodBarber, Hatchable, Hercules, Hostinger AI Builder, Lovable, Macaly Cloud, MiniUp, ProductOS, Replit, Softr, Sticklight, Val Town, Zite in ChatGPT AI App & Website Builders, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.