Show strategy as a product
Patter translates modernization thinking into an interactive experience rather than leaving it as slides, frameworks, or abstract architecture language.
Build narrative
How I turned a modernization idea into a working cloud planning application.
Patter was built in roughly 30 hours through an AI-assisted development workflow, more than 500 focused iteration loops, and a lightweight AWS static hosting architecture.
Business motivation
Make cloud modernization planning tangible.
Connect executive and technical audiences
The application frames portfolio assessment, target-state planning, dependency sequencing, and roadmap storytelling in a way both leaders and builders can use.
Demonstrate modern delivery
The build itself proves a point: experienced architecture judgment plus AI-assisted development can compress the path from idea to deployed product.
Development model
Not one big prompt. Hundreds of small improvement loops.
The operating model
Visual Studio Code was the core IDE, and an AI development plugin was the driving force behind implementation. The workflow was conversational and iterative: define a product need, generate or revise a capability, test the experience, identify friction, refine the behavior, and repeat.
The important part was not that AI wrote code. The important part was the cadence: hundreds of directed loops guided by architecture judgment, product intent, and real enterprise modernization experience.
Runtime technology stack
Simple static hosting architecture, intentionally production-shaped.
- Static front endThe Patter application is delivered as browser-based static assets, avoiding an always-on application server.
- Amazon S3Static application asset hosting with a durable, low-operational-overhead origin.
- CloudFrontGlobal content delivery, edge caching, HTTPS termination, and public distribution.
- Route 53 + ACMDNS management and AWS-provided public TLS certificates for secure access.
Cost implications
Low infrastructure cost because the app is static.
Hosting Patter as a static site avoids always-on servers, containers, databases, and application runtimes. Most ongoing cost is tied to storage, requests, DNS, and data transfer. The model is especially cost-efficient for a portfolio application because traffic can be served from CloudFront edge cache and the S3 origin remains simple.
| Area | Cost implication | Why it matters |
|---|---|---|
| S3 storage | Typically small for static HTML, CSS, JavaScript, and image assets. | No compute runtime is required to serve the application. |
| CloudFront | Costs scale mainly with requests and data transfer. | Caching improves performance and reduces repeated origin load. |
| Route 53 | Hosted zone and DNS query costs are predictable and modest. | Provides durable domain management for a public portfolio experience. |
| AWS certificates | Public certificates through AWS Certificate Manager can be used without a separate certificate purchase. | HTTPS is built into the hosting pattern rather than bolted on later. |
| Build and deployment | GitHub source control and Terraform-based deployment reduce manual setup, rebuild effort, and configuration drift. | The bigger savings are operational: repeatability, reliability, and speed. |
Build and deployment lifecycle
The same loop carried from product design to deployment.
What the lifecycle proved
The workflow mirrored the product philosophy: take a complex modernization problem, structure it into manageable decision points, and use repeatable tooling to make progress visible.
The application is stored in Git and GitHub, while Terraform is used as the repeatable build-and-deploy mechanism for the AWS hosting environment. Terraform is not the runtime stack; it is the deployment discipline that keeps the infrastructure reproducible.