Softr pricing for a portal with 50 client users

Your portal works for the sample client, and now the account team wants to invite everyone else. Softr pricing needs to cover those client accounts as well as your employees. A plan that fits the builder and a few test logins can still be the wrong purchase for the launch roster.

For five internal app users and 50 external client users, Pro is the first current self-serve plan whose included user allowances fit. Evaluate Business when your design needs its global create, edit, and delete restrictions. Stay with the current portal if its access controls and total cost meet the requirements. This comparison uses official documentation checked October 22, 2026, not a firsthand trial.

Identify which accounts consume each allowance

Softr’s pricing documentation distinguishes workspace members from app users. Workspace members can use apps without consuming an app-user allowance. Team app users share a business email domain with a workspace member; other app users are classified as Client users. Free email domains do not establish that business-domain match.

For the budget below, assume the five employees are Team app users rather than additional builders, and all 50 customers qualify as Client users. Verify that classification against the actual addresses before sending invitations. Someone being a customer in your CRM does not by itself establish how the subscription classifies their account.

Then define the portal’s required actions. Do clients only read progress, or can they submit, correct, and delete requests? Decide who can change a request’s client assignment and who can close it. Those requirements determine the permission test and may change the plan even when the user count fits.

Price the same five-team, 50-client workload

Assume one workspace, a request portal, and twelve months of use. The examples are US dollar subscription calculations before taxes, implementation, external database subscriptions, and additional usage. The base prices and included user counts come from Softr’s current plan documentation.

Annual rates are billed upfront for twelve months. Client users are included only up to the allowance, not free without limit. Pro and Business permit paid additional users within published maximums; obtain the applicable rate and growth calculation before exceeding the included count. The price of any additional builders or other required add-ons remains outside this example.

A plan that fails the roster is not a cheaper version of this deployment. For another approach to building the portal, use the AI app builder comparison with the same audience and permission requirements. Keep the cost of reproducing the client access rules in the comparison.

Separate user groups, record capacity, and write access

Softr’s product FAQ lists up to three custom user groups on Pro and ten on Business. A group can describe a role such as client or staff reviewer. You do not necessarily need a separate group for every customer if a verified client identifier can determine which records that role may access.

For this proposed portal, use a Clients group and a Staff group, then tie each request to its client. Do not let customers edit the field that establishes their client identity. A membership condition based on an untrusted, self-edited profile field could assign access differently from what your account team intended.

The global data restriction documentation says view restrictions are available on all plans, while global create, edit, and delete restrictions require Business or above. It also excludes the Comments block from this feature. If confidential discussions are part of the portal, test that feature separately rather than assuming the request-table rule covers every comment.

Softr’s database page describes plan-specific record limits. For a hypothetical 2,000-request deployment, request confirmation of the current per-database, workspace, and app-source allowances in the chosen plan. These are different quantities. The current limits for the exact storage setup remain a purchasing check here; no database capacity is inferred from the number of included users.

If the portal reads Airtable instead of native Softr Databases, keep the source subscription and its capacity in the budget. The free Airtable alternatives article addresses the storage decision. Changing a portal plan does not establish that an external database has more capacity or different permissions.

Test two clients against the same request table

Create hypothetical Client A and Client B records, each with a stable ClientID. Add two client users and a staff reviewer. In Requests, store RequestID, ClientID, Requester, Description, Status, and UpdatedAt. Seed one request for each client, using names that make an accidental cross-client display obvious.

Link each signed-in client user to the client record approved by staff. Softr’s conditional filter documentation describes using logged-in user parameters to select records. Configure exact client matching for the list and detail view, and apply the corresponding global view restriction to the Requests table. Keep the staff rule explicit rather than granting broad access by accident.

Softr’s user group documentation says its record conditional filters and visibility checks run on the server. That differs from merely hiding content after sending it to the browser. The rule still has to be configured correctly: a filter for “open requests” says nothing about which client owns them. Publish changes before testing the deployed app.

Sign in as Client A and inspect the list, search results, detail links, and related-record selectors. Try opening the saved URL for Client B’s request. Repeat with Client B, then verify the reviewer’s access. The expected output is each client’s permitted request and a denied or empty result for the other client’s record. These are proposed tests, not observed product results.

If clients can submit or edit requests, test that they cannot choose another ClientID or alter the staff-only completion fields. For a Business design, configure the global write restrictions as well as action permissions. Repeat the test after removing a user from the allowed group. Do not approve launch based only on a page that looks correct under an administrator account.

Recheck restrictions after moving the data source

Before switching storage, export a sample and confirm that client IDs, request IDs, relationships, and attachment references remain usable. Inventory the forms, filters, user synchronization, and actions that point at the old tables. Assign someone to reconnect and test each dependency.

Softr’s database migration documentation states that global restrictions are tied to a specific table and source, so they do not carry over automatically. Rebuild them against the replacement tables and repeat the two-client access test. A successful data import does not establish a secure portal migration.

Keep a working portal in place until the replacement reproduces the required behavior. The enterprise app development article covers assigning delivery and maintenance ownership. Include ongoing account administration in that ownership, especially when clients change companies or stop working with you.

Where Permute fits: matching client records across sources

Permute is the connected business data and custom application software we sell. When a CRM account, a request export, and an accounting customer record use different IDs for the same client, we can help establish matching rules and preserve their source references. Your team decides which evidence confirms the match and which account membership permits access.

We can build a repeatable view of the client and its requests with source evidence and freshness visible to permitted users. An uncertain match stays unresolved for review. That helps an operations lead investigate a missing request without joining records based on a similar company name alone.

The portal still needs its own access tests

We do not supply Softr licenses or validate a deployed portal merely by preparing its data. Source access requires confirmation, and this article promises no native Softr connection or write-back. Your application owner remains responsible for testing the final user, record, and action permissions.

Choose the plan that covers the launch roster and actions

Pro covers the stated user counts, while the proposed global write-control requirement points to Business. Confirm the storage limits and any add-ons before approving the twelve-month budget. Run the two-client test under real account roles before inviting the full roster. Keep the existing portal if a replacement has not shown a benefit worth the migration work.

Questions about a Softr portal budget