Web Development Company in Minneapolis

Ranges, because scope and compliance load drive the number more than page count. A marketing site rebuild on a headless CMS with a documented component library, WCAG 2.1 Level AA conformance, and a performance budget enforced in CI typically runs USD 35,000 to 90,000. A larger content platform with multiple templates, a localization or multi-brand structure, editorial workflow, and integration into marketing automation typically runs USD 90,000 to 220,000. A headless commerce front end integrated with an existing order management and inventory stack, built for seasonal peak, runs USD 150,000 to 450,000 depending on catalog complexity and how many back-end systems have to be fronted. A customer or member portal with authentication, account data, and transactional workflows typically runs USD 120,000 to 350,000. Accessibility remediation of an existing site is usually quoted after an audit because the number depends entirely on what the audit finds, but a full audit with a written conformance report and a prioritized remediation plan generally runs USD 12,000 to 30,000. We quote fixed fee against a signed statement of work, and for remediation work we quote the audit first and the fix second so you are not buying a number nobody can justify yet.

It depends on who you are, and Minnesota has more layers than most states. Minn. Stat. 16E.03 subdivision 9 directs the state chief information officer to develop accessibility standards for technology, software, and hardware procurement, and state agencies build to the digital accessibility standard issued under that authority. Minn. Stat. 363A.42 requires public entities to make records accessible and carries USD 500 per violation plus reasonable attorney fees, with a USD 15,000 cap per person and a one-year limitation period, and it exempts technology acquired or developed before January 1 2013 unless it has been substantially modified since. Separately, the Department of Justice ADA Title II final rule published April 24 2024 applies WCAG 2.1 Level AA to web content and mobile apps of state and local governments, and a Federal Register interim final rule published April 20 2026 set the compliance dates at April 26 2027 for public entities serving populations of 50,000 or more, which covers the City of Minneapolis, Hennepin County, and the larger school districts, and April 26 2028 for smaller entities and special districts. Health and human services programs receiving HHS federal financial assistance fall under the HHS Section 504 rule published May 9 2024, and you should confirm your own compliance date against the current rule text rather than a secondhand summary. Private companies have no explicit federal web standard, but ADA Title III litigation in practice treats WCAG 2.1 AA as the benchmark, so we build to it regardless.

The Minnesota Consumer Data Privacy Act, Minn. Stat. 325M.10 through 325M.21, has applied since July 31 2025 and it changes what your tag manager is allowed to do. Two requirements bite hardest on the web layer. First, opt-in consent is required before processing sensitive data, which includes precise geolocation, health data, and biometric data, so a location prompt or a health-interest tracking pixel needs an actual consent gate rather than a footer link. Second, controllers must honor universal opt-out signals, and Global Privacy Control is the practical one, which means your site has to read the browser signal server-side and suppress the relevant processing before a tag fires, not after. That is an engineering change, not a banner change: we wire consent state into the server-rendered response so third-party scripts never load for a visitor who has opted out, rather than loading them and hoping a client-side script blocks them in time. We also build the data-subject request path, because Minnesota grants access, correction, deletion, portability, a right to the list of specific third parties that received the data, and a right to question profiling results. On the web layer that means a working request form, an identity check that does not itself become a data collection exercise, and a documented fulfilment path, because the attorney general's warning-letter step expired on January 31 2026 and a broken request form is now the violation rather than the warning.

Two different load shapes, two different designs. Retail peak is predictable, so we plan for it: static generation or incremental regeneration for catalog and content pages so most requests never touch an origin, edge caching with stale-while-revalidate so a slow back end degrades into slightly stale content rather than an error page, and a queue-and-shed strategy on the checkout path so the transactional flow keeps working when browse traffic spikes. We load test at the actual projected peak, not at a comfortable multiple of average, and we test the failure modes deliberately by taking the inventory service offline mid-test to see what the user sees. Storm traffic for a utility or airline is not predictable, and it arrives with everyone hitting the same three pages at once. There the pattern is an aggressively cached outage or status page that can be served entirely from the edge with a short time to live, a separate lightweight path that does not depend on the authenticated portal, and a static fallback that publishes automatically when the origin health check fails. We also plan for the mobile network reality of an outage: people checking a storm status page are often on a degraded connection, so payload size matters more than usual.

We build to Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, measured at the 75th percentile of real users rather than in a lab. Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024 and it is much harder to pass, because it measures the full interaction latency rather than just the delay before processing starts, which exposes heavy client-side JavaScript that the old metric let through. Whether it matters depends on the site. For an e-commerce or lead-generation site the honest answer is that the conversion effect is usually larger and more measurable than the ranking effect, so we treat these as revenue metrics that Google happens to also read. For a portal behind a login, ranking is irrelevant and the metric still matters because a slow interaction on a billing page generates support calls. We enforce budgets in CI so a regression fails the build, we track field data from the Chrome User Experience Report month over month, and we report against your own baseline instead of a generic benchmark.

A marketing site rebuild runs ten to sixteen weeks. Weeks 1 to 3 are discovery: field performance and accessibility audit of the existing site, content model design with the people who publish, information architecture, and a performance budget agreed in numbers. Weeks 4 to 11 are design and build in two-week sprints with a Thursday 2:00 PM CT review on a live preview. Weeks 12 to 14 are content migration, which is reliably the phase clients underestimate, plus accessibility remediation and QA across the browser and assistive technology matrix. Weeks 15 to 16 are launch, redirect mapping, and post-launch monitoring. A commerce front end or a customer portal runs twenty to thirty-six weeks because integration with order management, inventory, billing, or a system of record dominates the schedule. An accessibility remediation program on an existing large site runs eight to twenty weeks depending on template count and how much of the content is legacy documents, which is often the worst part of a public sector engagement. Where a legal deadline is driving the work, we sequence remediation by user impact and traffic so the highest-risk paths conform first rather than leaving the important pages until the end.