You want customers to check their own work orders without buying an internal software seat for each person. Knack pricing is worth evaluating for that use because the vendor advertises unlimited app users. The budget still needs a record forecast and a list of required controls. A portal with a modest login count can accumulate substantial history.
Consider Starter when the record allowance and basic app requirements fit. Evaluate Pro when the portal needs its listed custom-domain or scheduled-task features, and get a Corporate quote when its controls or higher capacity are required. Keep a working portal if its access rules, exports, and total cost remain acceptable. This assessment uses official documentation checked October 23, 2026, not firsthand product testing.
Price the same portal on consistent billing terms
The Knack pricing page lists standard monthly rates of $59 for Starter and $130 for Pro. Annual billing shows $49 and $110 per month respectively. Corporate starts at $300 monthly or $250 per month billed annually, with final cost dependent on requirements. Enterprise requires a quote. Promotional first-month offers are excluded from the recurring budget below.
Assume one hypothetical portal, two builders, two hundred customer users, and thirty thousand stored records. Hold that population constant when comparing plans. The table shows USD subscription costs before taxes, implementation, optional services, and additional usage. A price shown for a plan that fails the record requirement is a reference point, not a recommendation.
| Plan | Published record allowance | Annual billing calculation | Twelve standard monthly payments |
|---|---|---|---|
| Starter | 20,000: below example need | $49 × 12 = $588 | $59 × 12 = $708 |
| Pro | 50,000: fits initial example | $110 × 12 = $1,320 | $130 × 12 = $1,560 |
| Corporate | 125,000 at starting tier | $250 × 12 = $3,000 starting total | $300 × 12 = $3,600 starting total |
| Enterprise | Confirm in quote | Unknown until quoted | Unknown until quoted |
Under these assumptions, Pro is the first listed tier with enough initial record capacity. That does not settle the decision if you require a control it lacks. Knack’s plan documentation lists Pro with one month of record history and Corporate with two months. Record-history retention and your business evidence-retention requirement need a separate comparison.
If you compare this with Airtable pricing, use the same customer actions and builder population. A customer who reads a portal and an employee who edits a database may belong to different billing categories. Do not multiply every external login by a vendor’s internal editor price without confirming how the proposed deployment is licensed.
Count records added by the workflow, not just customers
List every table the portal needs: customers, work orders, status events, and any separate document metadata. Record the current count in each table and the number added by a normal month. Do not assume one customer equals one record across the app. A customer with several work orders and many status events contributes to several parts of the stored history.
For a hypothetical growth check, begin with thirty thousand records and add two thousand each month, with no deletion or archival. Ten months brings the total to fifty thousand, and the next month exceeds that amount. This is arithmetic for the stated sample, not a forecast of Knack performance. Add your own record-retention policy before deciding when another tier or an approved archive is needed.
Keep attachment storage and automation usage in separate budget lines. The plan overview lists Pro with 10 GB of file storage and 2,000 included Flows transactions, alongside its record allowance. Confirm current billing periods, overage treatment, and additional capacity in the quote. Having room for another database row does not establish room for its files or the automations it triggers.
Check customer separation with more than a hidden page
Knack’s Data Access Control documentation describes table-level rules applied to pages, searches, API requests, and exports. It distinguishes page access from access to the underlying records. The documentation says the feature is available for new apps and is being rolled out to existing apps, so confirm its availability and enforcement on the specific app you are buying or inheriting.
Build a synthetic acceptance sample with customer A and customer B, each with a work order and an attachment. Add a support employee who can work across both accounts. Configure the intended customer ownership and role rules, then sign in as each customer. Require that searches, linked records, and permitted exports show only the records that account should receive.
Change the test customer’s assignment and remove access, then repeat the checks. Record the expected result before running them so a convenient output does not become the requirement after the fact. These are proposed evaluation steps, not observed product results. Ask the builder to document how ownership is assigned when a work order arrives from another source.
Include a usable handover in the implementation price
Ask for the table relationships, access rules, integration credentials inventory, and operating instructions as part of delivery. A second builder should be able to make an approved change without sharing the original builder’s login. Test a failed source update and confirm who sees the error and how they can rerun it without duplicating work orders.
Include time for reconciling customer identifiers when the source CRM and accounting system use different codes. Choose which source owns each field, preserve unresolved matches, and retain the source identifier in the portal record. The enterprise app development discussion covers these ownership decisions beyond the subscription itself.
An export needs a separate plan for files and app behavior
Knack’s record export instructions support CSV, text, and JSON exports and explain that Builder exports operate one table at a time. File and image fields export URLs to the stored files. A spreadsheet containing a URL is not a separate copy of the attachment, so include file retrieval and verification in a migration rehearsal.
Export a permitted sample from every related table and preserve stable identifiers. Rebuild relationships in the destination, compare row counts, and open the retrieved attachments. Keep a separate inventory of pages, rules, scheduled tasks, and source connections to reproduce. Data export by itself does not recreate the application’s behavior or its access model.
Agree on a final change cutoff and a rollback owner before moving customer access. Check that updates made during rehearsal are included in the final transfer. Invite a limited set of approved testers, compare their visible work orders, and keep the prior app available for the agreed recovery period. Use the same acceptance sample when considering another builder such as Zoho Creator.
For a portal that keeps its existing backend, the WeWeb pricing example separates builder access from hosting. Include the database and operating work on both sides before comparing the subscription figures.
Where Permute fits in a portal backed by several systems
Permute sells connected business data and custom applications. We can scope the work of matching customer and work-order records across permitted sources and preserving the evidence behind those matches. Our interest in app-building decisions is commercial, and Knack can remain a suitable choice when its own data model and controls meet the job.
We can apply your declared status definitions to a recurring view so an operations owner can inspect the source and freshness behind a customer update. The implementation needs an agreed access model and a supported connection path. Confirm those details before treating a proposed customer view as production-ready.
Explore the data behind a customer view
Start with a permitted sample of customer and work-order records to inspect their identifiers and definitions.
Confirm the scope beyond the portal subscription
We do not sell Knack licenses or promise a native Knack connector. Connection work, hosting arrangements, and any external actions require separate scoping and the relevant permissions. A report showing a proposed update does not authorize changing a customer’s record in another system.
For the example portal, Pro has enough starting record capacity at the stated annual subscription price. Growth and required controls can change that choice before the customer count does. Check access with separate customer identities, budget for maintaining the app, and rehearse a complete export. Keep the current portal when those checks support staying.
Scope one customer portal workflow
Bring the source records and the customer access requirements to discuss what needs connecting and maintaining.
Questions about budgeting a Knack portal
Should a temporary discount determine the annual budget?
Use the continuing rate for the recurring budget and list any confirmed introductory discount separately. Check eligibility and the date the normal rate starts. This prevents a short offer from being mistaken for the long-term operating cost.
Can I delete old records to stay under the allowance?
Only after agreeing on retention and preserving any required evidence and relationships. Rehearse retrieval from an archive before deleting the live copy. A lower count is not useful if customer history can no longer be reconstructed.
Who should own the builder account?
Assign ownership to a company-controlled identity and maintain a documented backup administrator. Use separate accounts for contractors and remove access when their work ends. The handover should leave the business able to maintain the app without a former contractor’s credentials.
Does exporting records also move customer passwords?
Do not assume that a record export recreates authentication at the destination. Confirm the supported user migration path and plan invitations or password resets where needed. Test the target access model before inviting customers.