Native Enterprise Modernization
StarQuilts247 – Native Craftsmanship Online
A culturally grounded web showcase for traditional Native star quilts, ribbon wear, and custom orders — built to highlight talent, preserve legacy, and support overwhelming demand.
Before and after
The situation
The challenge
StarQuilts247 needed a public presence, but the real problem underneath was operational, not visual. Billy Werk ran a growing custom-order business from Fort Belknap with no owned digital infrastructure: no controlled DNS zone, no hosting environment, no deployment pipeline, no TLS, no durable backup of her product photography, and no way to absorb a sudden traffic spike. Order intake was scattered across phone calls, texts, and social messages, which meant no reliable record of customer requests and no way to throttle demand.
Three constraints shaped the engagement:
- Bandwidth reality. A large share of visitors were on rural and mobile connections across Montana. A heavy origin server or unoptimized asset delivery would have made the site effectively unreachable for the people it was built for.
- Zero operating budget. The business could not carry a monthly infrastructure bill, so the architecture had to hold near-zero run cost while still being production-grade.
- Single-operator risk. One person owned the business, the content, and every account. Any design requiring ongoing server maintenance, plugin patching, or manual intervention would fail within months.
The conventional answer for a business like this is a shared CMS host with a public admin login, a database, and a monthly bill. That would have introduced a persistent patching obligation and a standing compromise vector for an owner with no technical staff.
Supported outcomes
Results and project impact
- Attack surface reduced to near zero. No CMS, database, or admin login exists to compromise. No security incidents have occurred, and there is no patching backlog to accumulate.
- Zero recurring infrastructure cost, sustained through a significant traffic spike with no overage charges and no emergency plan upgrade.
- Fast, reliable delivery on rural mobile connections, which was the primary audience and the hardest performance constraint in the engagement.
- Demand surge absorbed without capacity planning. Within weeks of a quiet launch, inquiries arrived by phone, email, and message in volume, and the client was booked through the following year. The edge architecture handled the load without intervention.
- Controlled shutdown as a feature, not a failure. When orders exceeded fulfillment capacity, the site was taken offline cleanly at the client's request, with domain, DNS zone, and deployment history fully preserved. Restore is a single promotion of an existing immutable deployment.
- Complete client ownership of domain, source code, and platform accounts, with no vendor lock-in and no dependency on us to keep operating.
- Zero maintenance burden carried by a single-operator business, which was the outcome that made the whole architecture worth choosing.
Recommended approachStrategy
The strategy was straightforward: reduce the attack surface to as close to nothing as possible, push delivery to the edge, and treat cost as a hard design constraint rather than a line item.
- Static-first by default. No origin server, no database, no runtime admin surface. If it does not exist, it cannot be compromised or patched.
- Platform over servers. Run on a managed edge platform so that TLS renewal, OS patching, and scaling become the provider's responsibility, not the client's.
- Git as the control plane. Every change versioned, reviewed, and revertible. Deployments are immutable and atomic, so there is no partially-deployed state and no SSH or FTP path into production.
- Cost ceiling as an architectural requirement. Design to stay inside free-tier limits, then validate that assumption under spike load instead of hoping for it.
- Client ownership from day one. Registrar, repository, and platform accounts held by the client, with consultant access delegated and revocable. No vendor lock-in, no hostage infrastructure.
This is the same posture we apply to larger cloud engagements, right-sized for a one-person operation.
How the work movedDelivery process
Discovery and assessment
We inventoried what already existed: domain registration and DNS state, account ownership, and where the product photography actually lived. Just as important, we profiled the audience. Most visitors were on rural and mobile connections across Montana, which set a hard performance ceiling that every later decision had to respect. Budget and maintenance capacity were documented as constraints up front rather than discovered later.
Architecture and risk review
We evaluated the conventional managed CMS path against a static edge architecture, scoring both on attack surface, recurring cost, maintenance burden, and performance under poor connectivity. The static edge model won on every axis that mattered for this client. The decision and its tradeoffs were documented so the choice is reviewable rather than assumed.
Build and pipeline
We stood up the repository, CI/CD pipeline, and per-branch preview environments first, then built the static application and the build-time image optimization pipeline on top of them. The serverless inquiry endpoint was added with validation and rate limiting in place from its first deploy.
Security and DNS cutover
DNS was consolidated under a single managed provider, TLS issued and verified, HTTPS redirects enforced, registrar lock enabled, and unused records removed. The cutover ran with lowered TTLs and a documented rollback plan so the change was reversible within minutes.
Validation
We tested page delivery on throttled mobile connections, verified redirect and certificate behavior across both hostnames, probed the inquiry endpoint for abuse handling, and ran a live rollback drill so the recovery path was proven before it was ever needed.
Handover
Documentation delivered, credentials transferred to client ownership, and a walkthrough session completed. The client left the engagement owning every account in the stack.
Operate and advise
We monitored the post-launch surge and stayed available as demand climbed. When orders exceeded fulfillment capacity, we executed a controlled takedown at the client's request, preserving the domain, DNS zone, and full deployment history for a clean restore when she is ready.
After launchCurrent status and ongoing support
The site is currently in a controlled offline state at the client's request while she works through her order backlog. This was a planned capability, not an outage. The domain, DNS zone, TLS configuration, repository, and full deployment history remain intact and under her ownership, so bringing the site back is a single promotion of an existing immutable deployment rather than a rebuild.
Support continues on a light advisory basis: domain and DNS custody, periodic security posture checks, and cost verification to confirm the workload stays inside free-tier limits.
The next phase under discussion is a waitlist or pre-order intake path, so that demand can be throttled at the infrastructure layer instead of being absorbed manually. The current architecture supports that addition without any change to the hosting model, the cost profile, or the security posture.
Context
Client or organization background
Billy Werk (StarQuilts247) is a Native artist and seamstress from the Fort Belknap Indian Reservation in Montana. She crafts star quilts, ribbon skirts, and custom wearable art rooted in Nakoda and Aaniiih tradition. Her work is well known across Montana and beyond, and demand for her pieces regularly exceeds her capacity.
Success criteria
Project goals
- Establish owned, client-controlled cloud infrastructure with no monthly run cost
- Harden DNS and enforce HTTPS across every hostname
- Deliver fast, reliable page loads on rural and mobile connections
- Eliminate the server patching and maintenance burden for a single-operator business
- Create a validated, abuse-resistant order inquiry intake path
- Enable instant rollback and safe redeploy at any time
- Absorb unpredictable demand spikes without capacity planning or cost exposure
- Transfer full ownership of domain, code, and accounts to the client
InnoNative responsibilities
Scope and services delivered
- Cloud Architecture Design
- Cloud Deployment & Migration
- DNS Configuration & Hardening
- Security Posture Assessment
- Performance Engineering
- CI/CD Pipeline Setup
- Cloud Cost Optimization
- Static Infrastructure Modernization
- Monitoring & Alerting
- Documentation & Knowledge Transfer
- Ongoing Cloud Advisory
Implementation
Technical solution
The site is built with Next.js and Tailwind CSS, statically exported and deployed to the Vercel edge network. Because every page is pre-rendered at build time, there is no database query and no server-side render on request. Time to first byte is edge cache latency, not application latency.
Images are processed to modern formats and responsive sizes during the build and served from edge cache with long-lived immutable headers. This avoided both an external image service dependency and a runtime image pipeline that would have needed securing and paying for.
Order inquiries are handled by a validated, rate-limited serverless function that routes to email. Each branch gets its own preview deployment for verification before merge, and rollback is the promotion of a previous immutable deployment, which completes in seconds with no rebuild required.
Tailwind's purge step and the deliberate absence of heavy client-side frameworks keep the JavaScript and CSS payload small, which matters more than anything else on an older phone over a rural connection.
Capabilities
Key features
- Zero-server static architecture with no public admin surface
- Global edge delivery with immutable caching
- Automated TLS provisioning and renewal
- Hardened, consolidated DNS with registrar lock
- Git-based CI/CD with atomic deploys and instant rollback
- Per-branch preview environments
- Rate-limited, validated serverless inquiry endpoint
- Build-time image optimization for low-bandwidth networks
- Client-owned domain, repository, and platform accounts
- Zero-cost free-tier operation with no overage exposure
- Documented controlled takedown and restore procedure
Connected systems
Integrations
- GitHub (source control and deploy triggers)
- Vercel (build pipeline, edge delivery, serverless functions)
- Vercel Managed DNS (authoritative zone and automated TLS)
- Domain registrar (delegation and registrar lock)
- Transactional email routing for order inquiries
- Uptime and deployment monitoring with email alerting
- Privacy-preserving edge traffic telemetry
- Social channels as inbound traffic sources
Handoff
Launch deliverables
- Production static site on client-owned cloud infrastructure
- Hardened DNS zone with automated TLS and enforced HTTPS
- Git-based CI/CD pipeline with preview environments and instant rollback
- Rate-limited serverless inquiry endpoint with email routing
- Security posture summary and documented risk register
- Cost model confirming zero recurring infrastructure spend
- Operations runbook and account ownership register
- Uptime, deployment, and error monitoring configuration
- Offsite backup of product photography and source assets
- Documented takedown and restore procedure
Visual details
Project gallery
Selected screens and project materials. Open any image for a larger view.
Your next step
Have a project with similar goals or constraints?
Share the business need, desired outcome, timeline, and expected investment. InnoNative will review the information and recommend a next step when there is a potential fit.