SaaS Development Company in Salt Lake City

Honest ranges tied to scope. A production-grade MVP, meaning multi-tenant authentication, a real tenant model, core workflow, Stripe billing, an admin console, audit logging, and deployment with CI and monitoring, typically runs USD 70,000 to 160,000 over twelve to twenty weeks. That is a shippable product a design partner can pay for, not a prototype. A full platform build with enterprise SSO and SCIM, granular permissions, a public API with rate limiting and webhooks, usage-based metering, tenant-level data residency options, and SOC 2 Type II readiness typically runs USD 200,000 to 550,000 across phases. Enterprise readiness work on an existing product, which is the most common request we get from Salt Lake City companies that are losing deals in security review, usually runs USD 60,000 to 180,000 depending on how the current authorization model was built. Ongoing product engineering runs as a monthly retained team. We quote fixed fee against a signed statement of work rather than open-ended time and materials.

There are three real options and the honest answer is that changing later is expensive, which is why we settle it in week one. Shared schema with a tenant identifier column plus Postgres row-level security is the default for most Salt Lake City SaaS products. It gives the best cost efficiency and the simplest operations, and row-level security means an application bug does not automatically become a cross-tenant data leak because the database refuses the query. Schema per tenant gives cleaner logical separation and simpler per-tenant export and deletion, at the cost of migration complexity that becomes painful somewhere past a few hundred tenants. Database per tenant is the right answer when a specific enterprise or regulated customer contractually requires physical separation, or when a single customer's volume would distort a shared cluster, and it is usually offered as a premium tier rather than the default. The pattern that works is a shared-schema default with a documented path to promote an individual tenant to a dedicated database, which requires that every query already goes through a tenant-scoped data access layer from day one. Retrofitting that layer into a product that used raw queries everywhere is the expensive scenario we get called to fix.

SOC 2 is an attestation against the AICPA Trust Services Criteria, not a certification, and Type II is the one enterprise buyers want because it reports on whether controls operated effectively across an observation window, typically three to twelve months. That window is the schedule constraint people underestimate: you cannot compress it, so controls need to be live before the clock starts. The engineering work is concrete. Access control with documented provisioning and quarterly access reviews. Change management with pull request approvals, CI gates, and a traceable link from ticket to deploy. Encryption in transit and at rest with documented key management. Centralized logging with retention that outlives the window. Vulnerability management with dependency scanning and a patch service level. Backup and restore that you have actually tested rather than assumed. Incident response with a written plan and evidence of a tabletop exercise. The Utah Consumer Privacy Act is separate and complementary. It took effect December 31 2023 and gives Utah consumers rights to access, delete, port, and opt out of sale and targeted advertising, plus a right to request correction of inaccurate data that was added to Section 13-61-201 effective July 1 2026. Your SOC 2 controls do not satisfy any of it. We build the data subject request pipeline as product functionality, which for a multi-tenant platform means it has to work per tenant as well as per consumer, since your enterprise customers will contractually push their own subjects' requests down to you.

FERPA governs education records held by institutions receiving federal education funding, and as a vendor you generally operate under the school official exception, which means the institution designates you as performing a function it would otherwise perform itself, keeps direct control over your use of the records, and you may not redisclose without authorization. That single sentence has architectural consequences. Purpose limitation has to be enforceable, so training a shared model on one institution's student data to benefit another institution is off the table unless the agreement explicitly permits it. Deletion and return of records at contract termination must be a real operational capability including backups and analytics copies, not a promise. Parent and eligible student access rights flow through the institution, so you need per-record export that the institution can execute. Directory information handling varies by institution, so it has to be configurable rather than hardcoded. Add COPPA if any users are under thirteen, which changes consent handling entirely. Practically, the Instructure ecosystem also means LTI 1.3 and LMS integration expectations, plus accessibility conformance that university procurement will test rather than accept on assertion. State-level student data rules vary by institution and district contract, so we implement the contract terms your customers actually sign.

Utah's industrial bank charter, administered by the Utah Department of Financial Institutions with FDIC deposit insurance, is why Salt Lake City institutions such as WebBank and Celtic Bank sit behind a large share of American fintech lending and card programs. Getting onboarded means passing that bank's third-party risk process, which since the interagency guidance issued by the Federal Reserve, FDIC, and OCC in June 2023 has become materially more rigorous. Expect a full diligence package: your SOC 2 Type II report, penetration test results with remediation evidence, a business continuity and disaster recovery plan with tested recovery objectives, an information security program mapped to GLBA safeguards, your own subservice provider inventory because their risk flows to the bank, financial statements, and a complaint handling process the bank can inspect. Architecturally, the bank will want the ability to audit your systems, immutable records of every consumer-facing decision, and clean separation between what your platform decides and what the bank decides. If your product touches credit, adverse action reasons must trace to real factors under ECOA and Regulation B. If it touches card data, PCI DSS v4.0.1 applies with the future-dated requirements mandatory since March 31 2025. We build the evidence as we build the product.

Usage-based billing fails in predictable ways and the fixes are architectural rather than commercial. Emit metering events from the application as an immutable append-only stream with an idempotency key on every event, so a retry never double-bills and a replay can rebuild any invoice from source. Never derive usage by querying current application state at invoice time, because state changes and last month's invoice then becomes unreproducible. Aggregate into a separate metering store, keyed by tenant, meter, and time bucket, and keep the raw events long enough to cover your longest dispute window plus the retention your auditor expects. Expose usage to the customer in near real time inside the product, because the single largest driver of billing disputes is a customer seeing a number for the first time on an invoice. Handle plan changes, mid-cycle upgrades, proration, credits, and commitment drawdowns explicitly in the model rather than patching them later. For implementation, Stripe alone works when meters are few and simple; Metronome or Orb earn their cost once you have committed contracts, tiered rates, and multi-dimensional meters. Build a reconciliation job that compares metered totals against invoiced totals nightly and alerts on drift, because silent metering bugs are revenue leakage that nobody notices for a quarter.