01 / Guide
A Test That Never Fails Is Not Reassuring
Tests earn trust by exposing mistakes. A practical look at boundaries, regressions and failure cases, using the verification workflow behind this static site.
Writing
Archive
All published writing, in chronological order.
2026
02 / Essay
Everything Is a Trade-off: What Software Architecture Actually Looks Like in Practice
A forest-monitoring exercise shows how buffering, recovery targets and limited bandwidth turn software architecture into a series of explicit trade-offs.
03 / Essay
Reliability Is What Happens After the Happy Path Ends
Reliability becomes visible when networks fail and work must recover. Explore buffering, bounded retries and requirements that describe useful failure behavior.
04 / Essay
Good Interfaces Reduce Thinking, Not Just Clicking
Fewer clicks can still mean more confusion. A practical argument for interfaces that expose state, explain choices and reduce the memory a task requires.
05 / Guide
Reliable Software Starts Before the Code: Turning Vague Requirements into Things You Can Test
Turn vague promises about reliability into measurable scenarios, with explicit failure conditions, recovery boundaries and evidence a test can actually collect.
06 / Essay
Design Patterns Are Vocabulary, Not Architecture
Strategy, Adapter and Observer help name design choices. Their value depends on the forces they address, their costs and the boundaries they preserve.
07 / Field note
The Best Code Is Often the Code You Can Delete
Removing a visitor counter simplified an entire operating model. A field note on maintenance cost, safe deletion and responsibilities hidden behind features.
08 / Essay
Web Engineering Is Mostly State, Boundaries and Boring Details
Web systems accumulate complexity around state, URLs, caches and integrations. Follow a catalogue change across boundaries a polished interface can hide.
09 / Field note
Coding Agents Are Useful When You Stop Treating Them Like Autocomplete
Building this website with a coding agent changed the unit of delegation: a bounded engineering task, with repository context, checks and a reviewable result.
10 / Essay
AI Coding Gets Better When You Make the Model Prove It
AI-assisted changes need inspectable evidence: repository context, meaningful tests, visual checks and diff review. Generation is the beginning of the workflow.
11 / Guide
AI Features Need an Evaluation Plan Before They Need a Demo
An impressive output is a starting point. Build an evaluation plan around realistic tasks, visible failures, human review and changes to prompts or models.
12 / Guide
The Best LLM Workflow Has an Exit Ramp
An LLM workflow needs a route for uncertainty, invalid output and exhausted retries. Design review queues and deterministic checks before automating decisions.
13 / Essay
Context Engineering Beats Prompt Tricks
Better AI-assisted work starts with approved decisions, useful evidence and clear limits. A practical approach to context that survives real project changes.
14 / Essay
n8n Is Great Until Your Workflow Becomes a Product
Visual workflows can coordinate useful work without owning each rule. Examine testing, recovery and the point where domain logic deserves its own boundary.
15 / Guide
Automate the Boring Part, Keep the Judgment
A practical way to choose automation boundaries for catalogue work: stable transformations, inspectable inputs, visible exceptions and deliberate human review.
16 / Guide
AI Infrastructure Starts With Boring Questions About Cost, Latency and Failure
Latency, cost, rate limits and recovery shape an AI feature long before a model benchmark settles the choice. Design the dependency around the actual user task.
17 / Essay
Problem-Solution Fit Comes Before Your Feature List
Revisiting FiscoBud exposed a useful distinction: a coherent product concept can still rest on untested problems. Feature planning needs evidence underneath it.
18 / Essay
SaaS Pricing Is a Product Decision Before It Is a Finance Decision
Pricing shapes who a SaaS product serves and how customers experience its value. Explore packaging, usage measures and honest tests of willingness to pay.
19 / Essay
Build-Measure-Learn Is Not a Three-Step Checklist
The useful work begins before building: identify a risky assumption, choose evidence that could change a decision and design the smallest meaningful experiment.
20 / Essay
Go-to-Market Starts Before You Have Something to Launch
Distribution, buying decisions and trust belong in product discovery. Trace the route from a customer problem to a first conversation and useful adoption.
21 / Guide
Validation Is Not Asking People If They Like Your Idea
Compliments cannot carry a product decision. Connect assumptions to recent behavior, existing alternatives and experiments that can genuinely change the plan.
22 / Essay
Building in Public Is Useful Only If You Know What You’re Learning
Public updates can create conversations, but attention alone cannot validate a product. Define the learning goal, audience and evidence before sharing work.
23 / Essay
A Smaller Product Can Be a Bigger Strategy
Reconsidering an all-in-one product can reveal a clearer entry point. Notes on FiscoBud, focused scope, educational support and a credible path to expansion.
24 / Field note
The Hard Part of E-commerce Is Usually the Product Data
Supplier files become a systems problem when identifiers, variants, prices and stock disagree. A practical way to build a catalogue you can safely publish.
25 / Essay
A Roadmap Is a Bet Portfolio, Not a Promise
A roadmap can explain strategic choices without pretending uncertainty has disappeared. Make bets, dependencies and review points explicit before promises.
26 / Guide
CSV Is Not a Database, but Sometimes It Is the Interface You Get
Supplier files need an explicit boundary: preserve the input, detect its schema, normalize carefully and validate meaning before creating channel exports.
27 / Field note
One Product, Five Marketplaces, Fifty Different Rules
Multi-channel commerce is an integration problem: shared product facts meet different schemas, publication states and failure modes that need explicit handling.
28 / Essay
WooCommerce Works Until Your Operations Stop Being Simple
WooCommerce can support commerce, while integrations and operating rules need their own design. Examine data ownership, extensions and recovery at the edges.
29 / Guide
An API Integration Is a Relationship Between Failure Modes
The happy path is only the beginning. Design integrations around ownership, retries, idempotency, partial updates and reconciliation of uncertain outcomes.
30 / Field note
I Almost Used a VPS for a Static Website. I’m Glad I Didn’t.
A small visitor counter was pulling this portfolio toward a backend. Removing it made the hosting decision simpler without giving up the features that mattered.
31 / Guide
E-commerce Architecture Is Mostly About Keeping Systems from Lying to Each Other
Catalogue, prices, orders and stock overlap across commerce systems. Decide who owns each fact, how changes travel and how conflicts are detected and repaired.
32 / Essay
Digital Operations Is Where Strategy Meets the Spreadsheet
Product data, approvals and exception queues turn strategy into daily work. Make decisions explicit before automating the spreadsheet that holds them.
33 / Essay
A Good Development Workflow Removes Decisions You Shouldn’t Have to Make Twice
Scripts, publication gates and nearby documentation turn repeated project decisions into a predictable workflow that humans and coding agents can both follow.
34 / Guide
GitHub Actions Became My Publishing System
Versioned articles, validation, static builds and search indexing form a publishing pipeline. Here is how this site connects editorial changes to delivery.
35 / Guide
Inventory Is a Consistency Problem Before It Is a Number
A stock number means little without ownership, reservations and freshness. Explore overselling, delayed updates and reconciliation across sales channels.
36 / Guide
Linux Is Boring Until It Saves Your Day
Files, permissions, processes, ports and logs make infrastructure inspectable. Use a Linux investigation to narrow a failure without breaking more things.
37 / Essay
Own the Source, Rent the Infrastructure
Control can live in source, content and a portable build. A practical look at static hosting, independent recovery and the limits of infrastructure ownership.
38 / Essay
Your Laptop Is Part of Your Development Environment
Memory, storage, thermals and ergonomics shape daily development. Evaluate a laptop through a workflow and its constraints, rather than a specification contest.
39 / Essay
A Productivity Stack Should Remove Context Switching, Not Add Apps
More apps can create more places for work to disappear. Design a productivity stack around clear ownership, fewer handoffs and recovery after interruption.
40 / Guide
When a SaaS Comparison Becomes an Architecture Decision
When a service becomes part of your infrastructure, migration and data access matter. Compare SaaS tools through boundaries, recovery and a tested exit plan.
41 / Essay
Complexity Is Usually a Coordination Problem Wearing a Technical Costume
Complexity grows when components, people and states must agree. A practical look at coupling, shared state and the coordination hidden inside architecture.
42 / Guide
“It Should Be Fast” Is Not a Requirement
Turn vague performance expectations into testable scenarios, with explicit workloads, measurement boundaries and targets that reflect real user needs.
43 / Essay
Every Extra Choice Has a Cost
Choices impose reading, comparison and recovery costs. Design defaults and progressive disclosure around what people need to understand before acting.
44 / Essay
Architecture Decisions Have Expiration Dates
Architecture decisions depend on assumptions that change. Record context, review triggers and migration costs so yesterday’s sensible choice stays visible.
45 / Guide
Give the Agent a Definition of Done, Not a Vibe
Make repository tasks verifiable with acceptance criteria, focused context, meaningful tests, visual review and clear boundaries for a production release.
46 / Essay
The Prompt Is the Smallest Part of the Context
Useful AI context includes repository state, schemas, examples and tool results. Curate evidence and authority instead of polishing one instruction forever.
47 / Guide
An AI Feature Is a System, Not a Model Call
Design AI features around inputs, retrieval, evaluation and recovery. A model response needs a reliable product workflow before anyone can depend on it.
48 / Field note
The Best Python Script Is the One You Can Run Again Tomorrow
Make repeatable Python catalogue jobs with explicit inputs, rejected rows, dry runs and deterministic output, then define what a successful rerun means.
49 / Essay
The First Version of a Product Should Answer a Question
Scope a first product around the assumption you need to test. Choose evidence, participants and decision rules before turning a hypothesis into a backlog.
50 / Essay
Users Are Better at Describing Pain Than Designing Your Product
Use interviews to understand recent behavior, workarounds and constraints. Treat feature requests as clues to investigate before committing to a solution.
51 / Essay
A Failed Experiment Can Be a Successful Product Decision
Design experiments that can stop a weak idea as well as support it. Define decisions, measurement checks and stopping rules before interpreting results.
52 / Essay
Bootstrapping Changes What “Good Architecture” Means
Limited time and operating capacity shape architecture. Use the static publishing workflow to examine fixed costs, reversibility and justified complexity.
53 / Field note
Supplier Data Is an API Even When It Arrives as Excel
Treat supplier spreadsheets as versioned external interfaces. Make schemas, provenance, missing values and identity rules explicit before importing rows.
54 / Guide
Catalogue Automation Fails Quietly Before It Fails Loudly
A catalogue job can succeed while publishing incorrect prices or mappings. Add semantic checks, reviewable changes and recovery to the import boundary.
55 / Essay
Integration Bugs Live Between Systems
Integration failures emerge from timing and conflicting assumptions. Design for retries, duplicate delivery, partial updates and evidence across boundaries.
56 / Guide
A Product Identifier Is More Important Than It Looks
Distinguish internal IDs, supplier references, SKUs and GTINs. Preserve identity, packaging context and mappings before automating downstream catalogue work.
57 / Essay
Git History Is Part of the Product
Clear commits preserve the reasoning behind software changes. Make history useful for review, debugging and recovery without burying behavior in noise.
58 / Guide
DNS, Hosting and SSL Are Three Different Things
Separate DNS delegation, hosting, TLS and HTTP redirects. Lessons from moving this static site from SiteGround toward its verified HostingPerTe deployment.
59 / Guide
Deployment Should Be Boring Enough to Trust
Build predictable releases with validation, restricted credentials and manifest ownership. Examine the boundaries of this static site’s deployment pipeline.
60 / Essay
Tooling Is Good When It Disappears
Choose development tools that make correct work easier. Balance formatting, linting, types and tests against setup friction, exceptions and maintenance.