Web operations
WordPress and WooCommerce hosting, performance tuning, Cloudflare edge behavior, backups, restore planning, update discipline, and operational cleanup for sites that have become more important than their original build quality.
01 · Overview
What I tend to build
I am usually working on the parts of a system that are easy to ignore until something breaks: access, DNS, hosting, automation, monitoring, recovery, performance, and the software glue between them.
My background is computer science with a networks and security concentration but my passion for technology, systems and innovation started in early childhood. In practice, my work has become a blend of engineering, operations, and business judgment. I care about the architecture, but I care just as much about whether someone can understand it six months later.
I have found that the best systems are rarely the most complicated ones. Simplicity is key. The best systems are the ones with clear boundaries, honest documentation, boring recovery paths, and enough discipline that the next change does not become a gamble.
- 01Build for the person who has to operate it after the interesting part is over.
- 02Prefer direct ownership over vendor blame loops and unclear responsibility.
- 03Use automation to reduce fragile repetition, not to hide a process nobody understands.
02 · Work
The areas I stay closest to
Cloud infrastructure
AWS, Linux, DNS, TLS, firewalls, routing, network segmentation, remote access, monitoring, and infrastructure automation with an emphasis on maintainability and blast-radius reduction.
Software systems
Internal tools, custom workflows, portals, integrations, reporting surfaces, and the application logic needed when off-the-shelf tools get close but not close enough.
Identity and communication
Microsoft 365 or Google Workspace posture, MFA, admin boundaries, email authentication, deliverability, shared mailboxes, and the quiet account structure that keeps small teams from losing control.
Operational strategy
Stack maps, risk registers, migration planning, vendor handoff, renewal cleanup, documentation, and clear 30, 60, and 90 day stabilization paths.
AI-assisted engineering
AI is useful when treated as acceleration, not authority. I use it for research, drafting, analysis, and implementation support, then verify the result against the system, the logs, the code, and the business requirement.
03 · Projects
Selected work, lightly described
The details below are intentionally summarized. Most useful engineering work happens inside private business systems, so public descriptions should explain the shape of the work without exposing client internals, architecture diagrams, credentials, vendor dependencies, or operational weak points.
Managed WordPress cloud stack
Standardized hosting patterns for small-business websites with isolated infrastructure, edge caching, security controls, automated configuration, backup coverage, monitoring, and repeatable migration practices.
Hosting · AWS · Cloudflare
Client operations platform work
Product and workflow design around client review cycles, resource previews, approval states, auditability, and operator readback surfaces. The emphasis is on making client-facing workflows clear without exposing the underlying system complexity.
Software · UX · Workflow
Secure access and network patterns
Small-office and cloud access designs using segmentation, controlled egress, secure administration paths, logging, device boundaries, and practical recovery options for when normal access is unavailable.
Networking · Security · Access
Digital operations cleanup
Work across domains, DNS, email, forms, analytics, payments, automations, and account ownership to reduce the number of hidden systems a business depends on without realizing it.
Ops · Identity · Automation
Commerce and service-business systems
Checkout reliability, form delivery, scheduling flows, tracking hygiene, receipt behavior, content structure, and the practical operational layer behind websites that are expected to generate revenue or leads.
Web · Payments · Leads
04 · Approach
How I think through systems
- Map reality before improving it. A clean diagram of the actual system is worth more than a confident guess about the intended one.
- Separate risk from preference. Not every ugly setup is dangerous, and not every modern setup is good. The question is what can fail, who notices, and how it recovers.
- Make recovery boring. Backups, rollback paths, access procedures, and monitoring should exist before the work becomes urgent.
- Use simple mechanisms where possible. Complexity has a carrying cost. Sometimes the right answer is a smaller system with stronger boundaries.
- Document the decisions, not just the settings. Future work gets easier when the reason behind a choice is preserved along with the configuration.
- Infrastructure
- AWS, Cloudflare, Linux, DNS, TLS, HTTP behavior, routing, firewalls, monitoring, backups, and configuration automation.
- Software
- Python, PHP, JavaScript, TypeScript, React, WordPress, workflow tools, APIs, data models, and internal systems that make operations less manual.
- Security
- MFA, least privilege, account recovery, admin boundaries, email authentication, edge controls, incident triage, and practical hardening.
- Interests
- Systems architecture, reliability, physics, space, networking, infrastructure economics, and the way small assumptions compound inside complex systems.
05 · Background
A concise version
Education
Computer Science, with a networks and security concentration. The academic foundation matters most when it shows up in practical decisions: threat models, failure modes, protocols, data flow, and maintainable architecture.
Current role
Founder and operator of Thunblom Cloud Solutions, focused on cloud systems, web operations, custom software, infrastructure automation, and digital operations for small businesses.
Working style
Calm, direct, detail-oriented, and biased toward building the version that will still make sense later. I would rather slow down for the right boundary than move fast into a system nobody can safely change.
Public detail
This page is intentionally restrained. It is meant to give context without turning private client work, internal projects, or operational infrastructure into public surface area.
Good systems do not need to be loud.
The work I care about most is usually invisible when it is done well: fewer incidents, clearer ownership, safer changes, cleaner handoffs, and a stack that does not require guesswork every time something moves.