Web Development Company in San Antonio

In ranges, because a brochure site and a public utility platform share a name and nothing else. A marketing site for a small or mid-sized San Antonio business, meaning a custom design system, a headless CMS, ten to twenty-five page templates, bilingual English and Spanish content, and accessibility and performance work done properly, typically runs USD 25,000 to 70,000 over eight to fourteen weeks. A larger corporate or multi-brand site with complex navigation, dozens of templates, integrations into a CRM or marketing automation platform, and editorial governance across multiple contributors typically runs USD 75,000 to 220,000. A public sector or utility platform with outage maps, account and payment integrations, service request workflows, surge capacity planning and a formal accessibility conformance report typically runs USD 150,000 to 500,000 and up. Ecommerce sits on its own curve depending on catalog size and payment complexity. Budgets here sit well under what the same scope costs through a coastal agency, and under Austin pricing too, which is why San Antonio marketing teams can often afford a custom build where a template retainer was the assumption. Ongoing work after launch is a monthly retainer sized to your content and campaign cadence. We scope in phases and price each phase in writing before it starts.

San Antonio is a majority-Hispanic city and Spanish is a first language for a large share of the audience, so a machine-translated mirror is worse than no Spanish at all: it ranks badly, it reads badly, and it signals that the Spanish-speaking visitor is an afterthought. The technical foundation is locale-prefixed routing, so English and Spanish pages have distinct stable URLs, with hreflang annotations that pair them correctly including es-US rather than a generic es, plus an x-default. In the CMS, Spanish is a first-class content model with its own editorial workflow and its own reviewer, not a translation field hidden inside the English document, which lets a Spanish page differ where it should. Design has to be checked in Spanish because translated strings run roughly fifteen to twenty percent longer and navigation, buttons and card layouts break in predictable places. Language selection should respect an explicit user choice in a persistent cookie rather than guessing forever from a browser header, and it must never redirect a user away from a URL they were sent. Forms, error messages, transactional email and PDF documents all need translation too, because those are exactly where half-localized sites fall apart. We use professional translators for anything customer-facing and reserve machine translation for internal drafts.

It depends on who you are, and the answer got sharper recently. If you are a state agency or a public institution of higher education in Texas, including UT San Antonio and the Alamo Colleges District, 1 TAC Chapters 206 and 213 apply through the Texas Department of Information Resources, and the technical standard is WCAG 2.1 Level AA covering web content, electronic documents, multimedia and mobile apps. If you are a state or local government entity, the Department of Justice ADA Title II rule finalized in 2024 sets WCAG 2.1 Level AA as the standard for web content and mobile apps. The compliance dates originally landed on April 24 2026 for entities serving populations of 50,000 or more, but DOJ published an interim final rule extending them, so large entities now have until April 26 2027 and smaller entities and special districts until April 26 2028. The substantive requirements did not change, only the deadline. If you are a private business, Title III has no published technical standard, but courts and plaintiffs have consistently treated WCAG 2.1 Level AA as the benchmark, and demand letters are common. We build to WCAG 2.1 Level AA by default, run automated axe checks in CI, and do manual keyboard and screen reader testing because automation catches roughly a third of real issues.

The first move is to stop optimizing the lab number. Google ranks on field data from real Chrome users, so we baseline against the Chrome User Experience Report and instrument real user monitoring on the live site, then treat lab tools as a debugging aid. On San Antonio tourism and hospitality sites, Largest Contentful Paint is almost always a hero image problem: oversized files, no explicit dimensions, no priority hint, and a lazy-loading attribute mistakenly applied to the above-the-fold image. We fix that with AVIF and WebP at correct responsive sizes, fetchpriority on the LCP element, and preconnect to the image origin. Interaction to Next Paint, which replaced First Input Delay as a Core Web Vital in March 2024, is usually a JavaScript problem: too much third-party tag manager code, hydration of components that never needed interactivity, and long tasks blocking the main thread. Server Components, code splitting and deferring non-essential tags fix most of it. Cumulative Layout Shift is nearly always missing image dimensions, web fonts swapping without a size-adjust descriptor, and ad or banner slots injected after paint. We then write the budget into CI so a pull request that regresses LCP or bundle size fails the build, which is the only way the gains survive six months of content edits.

Having a hyperscale region inside the city is a real advantage and also easy to over-weight. Azure South Central US sits in the San Antonio area with availability zone support, so if you have an in-state data residency requirement, a public sector procurement that prefers it, or backend systems already in Azure, putting the origin there is the obvious choice and it gives the lowest origin latency for local users. That said, for a marketing or tourism site the origin matters far less than most people assume, because a properly built Next.js site serves nearly everything from a CDN edge node that is already in or near San Antonio regardless of where the origin lives. So the honest advice is: choose the origin for compliance, integration and operations, and choose the CDN and caching strategy for speed. If you are on AWS, note there is no Texas region; the nearest are us-east-2 in Ohio and us-east-1 in Virginia, with an AWS Local Zone in Dallas for latency-sensitive edge components. Google Cloud's nearest full region is us-south1 in Dallas. We deploy to Vercel, Azure Static Web Apps with Front Door, or your existing cloud, and we care much more about cache hit ratio and image pipeline than about the map pin.

Three things matter more than everything else combined. First, a complete and consistent Google Business Profile for each physical location, with the same name, address and phone format everywhere it appears, correct primary and secondary categories, real photographs, and current hours including Fiesta week, holidays and seasonal changes for attractions. Inconsistent suite numbers and legacy phone numbers across directories quietly suppress map pack visibility. Second, on-site structured data using JSON-LD: LocalBusiness or the more specific subtype for each location page, Event markup for anything on a calendar, which matters enormously for River Walk and Pearl venues and for the convention calendar, FAQPage where you have genuine questions, and BreadcrumbList so search results show useful paths. Third, location pages that carry real information rather than a template with the city name swapped, because thin duplicated location pages are actively harmful. If you serve multiple neighborhoods, write about what differs at Stone Oak versus Southtown versus the Medical Center rather than reprinting the same paragraph. Spanish-language pages need their own structured data and their own Google Business Profile description where the platform allows it. We wire all of this at build time from the CMS so it stays accurate as content changes rather than drifting out of sync.