Stacker pricing for a customer or partner portal

You want customers to check their own projects without inviting them into the internal workspace. Stacker pricing needs a closer check before you budget that portal: its main page now lists a credit-based plan, while a separate live portal-pricing page still shows customer limits. Get the applicable offer in writing before multiplying a displayed rate by twelve.

Evaluate Stacker if its documented source connection and customer permissions meet the workflow, and you can confirm the usage cost. Keep your existing portal when it already separates customer records and costs less to maintain than a replacement. Adding more customers is a reason to compare complete offers, not proof that changing products will reduce the bill.

Start with the offer linked from the main pricing address

On October 27, 2026, the former stackerhq.com pricing address redirected to Stacker’s current pricing page. It listed an early-bird Standard plan at $50 per month with 250 monthly credits, no per-seat charges, and unlimited customer portals. Enterprise was custom-priced. Twelve months at that unchanged Standard rate would be $600 before additional usage and other costs.

That is a base-rate calculation, not a verified annual contract or a quote for your portal. The page labels the rate early bird, so ask how long it applies and what renewal terms follow. It also describes credits as consumption for agent actions. Do not equate a customer login, a synced row, or a completed request with a particular number of credits without confirmation.

A separate portal-pricing page remained live during the same review. It listed Personal, Starter, Plus, and Pro with customer allowances of 20, 100, 200, and 1,000, plus a custom Business option. This is a different commercial presentation. The public pages do not resolve which offer applies to a particular account, so this article does not combine their allowances or prices.

If you already use Stacker Classic, check your contract and account with the vendor. Current pages and older Classic documentation describe different products and user arrangements. Preserve the existing quote until Stacker confirms the migration path and commercial terms; a changed public page alone is not evidence that your subscription has changed.

Ask for one portal quote with a fixed workload

Use an illustrative scope of two internal builders, three internal operations members, and 100 external customer logins. Everyone needs access throughout the year. The portal displays 10,000 project and request records from a specified source, with customer-specific visibility and permitted status updates. These numbers define a buying scenario, not a tested deployment or promised plan capacity.

Ask the seller to price that exact roster and data scope under the offer available to your account. A full total remains unknown until usage, applicable limits, and implementation are confirmed. If Standard applies and the rate remains unchanged, the $600 base calculation is one line in that estimate. It is not a claim that the entire scenario costs $600.

For another portal option, Softr pricing examines user allowances and data requirements. Give each vendor the same scenario, including the people who maintain the app. Otherwise a comparison can omit internal access on one side or customer access on the other.

Separate customer access from the internal workspace

Stacker’s current user-type documentation distinguishes Builders, Members, and Portal Users. Builders configure the app, Members use the internal admin experience, and Portal Users use the published customer portal. The documentation says Members have full read access without a users table and that Builders and Owners are not restricted by those user-table rules.

Assign the customer the portal role and external login address. Keep the internal owner list short enough to review, and verify that each builder needs broad access before inviting them. The absence of a per-seat charge in an offer does not remove the need to decide what each person may see or change.

For the customer data itself, Stacker’s permissions documentation describes selecting a users table, linking data to the signed-in user, and controlling field visibility and editing. Configure project access through the customer account relationship. Treat shared reference tables, such as a public status list, as a separate decision from customer records.

Verify the connection used by the portal

Stacker’s connector documentation lists source-specific objects, authentication, sync schedules, and access requirements. For example, it documents Salesforce accounts, opportunities, and cases through OAuth with source-side API and object access. Use the entry for your actual source; a broad integration count does not establish that every required object or operation is supported.

Record where an update is supposed to land. If a customer changes a request status in the portal, decide whether that changes only portal data or must update the source application. Verify the selected connector’s documented behavior and test the permitted operation before promising it to customers. Include source subscriptions and any API entitlement in the full estimate.

Run the same customer request through the candidate plan

Prepare fictional data for two customer accounts, each with a project, an open request, and an attachment. Add an internal margin field that neither customer should see. Configure the users table and account links, build the project and request pages, and enable only the fields customers may update. The expected output is the customer’s own project status and a recorded request change.

Stacker’s row-access documentation describes filters through an owner, related record, or organization. Use its preview tools, then repeat the task with separate test logins. Try a direct link to the other customer’s request, open its related records, and verify access after removing the account relationship. These are proposed acceptance checks, not reported test results.

During the trial, record the credit balance before and after the actions you intend to automate. Repeat the expected pattern with permitted sample data and ask the vendor to explain unexpected consumption. Stacker’s main pricing FAQ says monthly credits reset and agents pause when credits run out. Confirm how that affects the particular workflow instead of assuming every portal function stops or continues.

Keep app configuration and business data in the exit plan

Stacker documents an on-request Git connection for app definitions and code. Its documentation explicitly excludes business records and secrets from that repository. Confirm a separate export and recovery procedure for the customer records and attachments, and obtain a sample export before treating access to the app code as a complete exit plan.

Inventory customer identifiers, account relationships, invitations, custom domains, integrations, and permission rules before moving an existing portal. Recreate access and reconnect credentials at the destination, then compare a customer’s visible projects against the old portal. Keep the old environment available for an agreed acceptance period. Knack pricing covers another portal budget where record capacity and required controls deserve a separate check.

Where Permute fits: tracing the status shown to a customer

Permute is the connected business data and custom application software we sell, so our interest in this evaluation is commercial. We can help reconcile project references across permitted source data and preserve the evidence behind the customer status. A request export and an accounting record may use different identifiers even when both refer to the same job.

We can reuse approved matching rules and declared status definitions in a report or custom app. An operations owner can inspect the source records and freshness behind an output, subject to access permissions. That work is relevant when the portal looks correct but its status disagrees with the information the internal team uses.

Scope the portal and source connections

We do not sell Stacker subscriptions or promise a native Stacker connector. Source access, data movement, and any permitted updates need an explicit implementation scope. Enterprise app development covers that planning. A working portal can stay in place while its data definitions and reporting are improved.

Budget from the confirmed offer and observed usage

Confirm which Stacker pricing offer applies before estimating the customer portal. Keep the same people, records, and annual period in each comparison, then add the cost of implementation and usage. Test customer separation and the source-update behavior before inviting live users. Keep the existing portal when the confirmed terms and acceptance results do not support a move.

Questions about budgeting a Stacker portal