How the Website Was Built

TL;DR

• Sunflower Design Studios runs as a static website: code in Azure DevOps, built by a pipeline, hosted on Bunny, served worldwide by a CDN.
• The pages travel the same road: idea, research, draft, review, build, test, deploy, monitor, correct, improve.
• The road follows ITIL: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement.
• Nothing reaches production without a test run first. Nothing ships without a review. Corrections leave a record.

The pipeline at a glance

1. Idea: name the story, name the audience, name the goal.
2. Research: verify the facts against sources. Record the source beside the fact.
3. Draft: write the post. Build the interactive element. Collect openly licensed images.
4. Review: check facts, check tone, check licenses, check accessibility.
5. Build: commit the code to Azure DevOps. The pipeline builds the static files.
6. Test: publish to the test address first. Click the links. Load the pages. Fix the errors.
7. Deploy: promote to production with a change-control entry. Purge the CDN cache.
8. Monitor: watch analytics, watch real-user performance, watch uptime.
9. Correct: log the errors as tickets. Fix the errors. Test the fixes. Deploy the fixes.
10. Improve: feed the lessons back into the next post.

1. Service Strategy — start with the idea

Start with demand, not with code. Answer three questions before writing a word:

• Name the story the page tells.
• Name the audience the page serves: readers, clients, search engines, the studio's reputation.
• Name the success measure: reads, shares, inquiries, a portfolio piece.

Record the answers in a ticket. The ticket carries a number, a priority, and a status. The ticket outlives the post: the ticket holds the research, the decisions, and the corrections.

Pick the home for the story. Sunflower Design Studios lives at sunflowerdesignstudios.com, registered at Porkbun on November 8, 2026, for $11.81 a year, auto-renew on, expiring November 8, 2027. DNS runs on Bunny, zone 984130, with DNSSEC validated. The domain belongs to the design studio; the site shows the studio's work and the studio's thinking.

Choose the service model up front. The site is static: HTML, CSS, and JavaScript, no server code, no database, no containers. Static keeps hosting cheap (about $1 a month at Bunny's minimum), keeps the attack surface small, and keeps the pages fast. The 3D demos on the hub follow the same model: static pages with Three.js in the browser.

2. Service Design — draw the blueprint

Design the page before building the page. The blueprint covers five parts:

• Content: the story, the facts, the sources. The facts carry sources. Unverified claims stay out of the draft, or the draft flags the claim as unverified.
• Media: photographs and graphics with clear open licenses only. Wikimedia Commons supplies the dome photographs in the Century post: CC BY 2.0 and CC BY-SA 4.0, attribution lines included. No image enters the site without a license and a credit. Resize the big files before publishing: the 2017 dome photograph measures 6000 by 4000 pixels and 14.9 MB raw.
• Interaction: the 3D viewer. The viewer rebuilds the subject to scale in Three.js, from published measurements, not from memory. The viewer ships as static files: a single HTML page, a single JavaScript module, the same vendored Three.js copy used by the Sunflower hub demos. No build step, no server code.
• Measurement: Google Analytics on the pages, Datadog RUM on the pages the studio builds. Analytics shows reader behavior. RUM shows how the pages perform on real devices. Analytics plus RUM are standing requirements for the studio's pages.
• Accessibility: keyboard controls for the viewer, a text alternative describing the subject in words, a reduced-motion mode, real buttons with labels, alt text on the images.

Design the hosting alongside the page. Code lives in an Azure DevOps repository in the sjultra organization. The pipeline builds the static files, deploys the files to Bunny Storage, and purges the Pull Zone cache. The test address, hub.sjuapi.com, serves from the first Dell T110 in Los Angeles through the Cloudflare tunnel. The production address, hub.sunflowerdesignstudios.com, serves from Bunny. The apex and www addresses redirect to the hub.

3. Service Transition — build, test, release

Move the work from draft to live in gated steps. No step skips the gate ahead.

• Build: commit the draft and the assets to the Azure DevOps repository. The pipeline builds the static files. A failed build stops the line: fix the build, run the build again.
• Test: publish to the test address first. Open the pages. Click the links. Load the 3D viewer in a desktop browser and a phone browser. Check the console for errors. Check the images for licenses and alt text. Check the page against the accessibility list. Record the results.
• Change control: promotion from test to production is manual, with a change-control entry for the promotion. The studio owner approves the promotions. No promotion moves without approval, and no approval covers work outside the approved change.
• Release: deploy the approved build to Bunny Storage. Purge the Pull Zone cache so the new files replace the old files worldwide. Verify the live pages over HTTPS: hub, apex, www, and the new post. Verify the redirect: apex and www point at the hub.
• Rollback: keep the previous build in the repository. A bad release rolls back by redeploying the previous build and purging the cache again. The rollback path gets tested before the rollback is ever needed.

Note the boundary: static sites use no container registry. The demos ship as files, not as images, so Harbor plays no part in the Sunflower pipeline. The test origin uses the T110 and the tunnel; the production origin uses Bunny. Test and production stay separate by design.

4. Service Operation — run the live service

Operate the site as a service, not as a pile of files. Operation covers four duties:

• Serve: Bunny CDN serves the pages from the edge, with free SSL on the custom hostnames. The origin stays in Bunny Storage. The DNS stays in the Bunny zone, DNSSEC validated.
• Monitor: watch the numbers daily. Analytics counts readers and pages. RUM measures load time, interaction delay, and errors on real devices. Uptime checks watch the addresses. CDN logs show traffic and cache behavior. A quiet day still gets a look: silence in the monitors means the monitors work, never a vanished site.
• Respond: treat errors as incidents. A broken link, a failed image, a viewer crash, a wrong fact: log the incident in a ticket, fix the incident, verify the fix on test, deploy the fix to production. The ticket stays open until the verification passes.
• Support: answer reader mail and client inquiries from the studio mailbox. Route the mailbox to the studio team. Keep the response time visible: unanswered mail is an incident too.

5. Continual Service Improvement — correct and improve

Close the loop. Improvement runs on a cycle, not on inspiration:

• Correct the facts: re-check the post on a schedule. News moves: the Century 24 apartment proposal reached the press in November 2026, after the first draft. The 2025 completion projection for the Century 21 rehabilitation missed, and the draft says so. A correction goes through the same road as a new post: research, draft, review, test, deploy. The correction carries a date, so readers see the page stay current.
• Fix the recurring problems: a repeated error becomes a problem, not a series of incidents. Find the root cause. Fix the cause. A broken image pattern becomes an image checklist. A slow viewer becomes a performance budget.
• Measure the improvement: track the key numbers: page load time, viewer error rate, broken-link count, time from incident to fix, time from idea to publication. Publish the trend, not just the snapshot.
• Feed the lessons forward: posts improve with the lessons. The Century domes post taught the pipeline three lessons already: verify dimensions against the architect's own description, treat a projected completion date as a projection until construction starts, and check the image license before falling in love with a photograph. Record the lessons in the ticket. The next draft starts from the lessons, not from zero.

The stack

Current status — read before quoting the page

Read the status with care: the pipeline above is decided, not yet live. As of November 9, 2026:

• The domain and DNS are live. The Bunny zone holds no records yet.
• The test build is on hold pending the pipeline plan.
• The Azure DevOps repository and pipeline await plan approval.
• The analytics property and the RUM application await decisions.
• The Century domes post and the 3D viewer prototype exist as drafts in the ticket folder only. Nothing is deployed to test or production.

The page above describes the pipeline as designed. Update the status table when the parts go live. Never describe a decided step as a finished step.

The Century domes post as a worked example

Trace the Century domes post through the five stages:

• Strategy: the studio wanted a post showing the website pipeline at full strength: a local history story with a 3D centerpiece, published on the studio's own domain.
• Design: the post pairs a verified history with an interactive dome viewer, built to scale from the architect's measurements, plus openly licensed photographs with attribution lines.
• Transition: the post sits as a draft in the ticket folder with research notes, an image inventory, and a standalone viewer prototype. Review, test build, and deployment wait for the pipeline plan.
• Operation: once live, analytics and RUM will measure reads and performance, and uptime checks will watch the page.
• Improvement: the post already carries two dated re-checks: the Century 24 apartment proposal (November 2026 reporting) and the rehabilitation status (no construction started as of August 2026). The two re-checks belong on the calendar.

Draft prepared November 9, 2026, ticket #F7ZY. Pipeline facts follow tickets #G65H, #5OCZ, and #A2GC. Status statements reflect November 9, 2026; update the status table as the pipeline goes live.

Pronoun check, November 9, 2026: the draft passes the mechanical grep with a single documented exception, a quoted proper name, not authorial voice: the requested page title "how we built this website" contains "we". The draft uses "How the Website Was Built" as the heading to keep the prose pronoun-free; the requested title appears in the quoted exception line of the verification note. No other hits on the core or extended pronoun lists.