What to Optimize For: Bridging the "It Depends" Trap in Architecture

TLDR

#

“It depends” is technically correct but practically useless. To bridge from ambiguity to decision, ask: What am I optimizing for? And to answer that: Who is this for? What are they trying to do?

I applied this to a trivial problem—building this blog—to showcase the thinking. The result: Hugo + Blowfish + Cloudflare Pages. Not because they are “the best” but because they optimize for what matters most in this specific context.

The “It Depends” Trap

#

Ask an architect about technology choices and you’ll get an “it depends.” Ask about patterns, scaling strategies, or framework selection—same thing. Unless that architect only has a hammer and treats everything as a nail.

It’s not wrong. Architectural decisions do depend on context. But “it depends” without structure frustrates everyone. Stakeholders don’t know what information to provide. Teams don’t know what tradeoffs they’re making. Decisions stall. And time waits for no one.

I’ve seen too many meetings where “it depends” became an excuse for analysis paralysis. Decisions are postponed without a clear direction. Or worse still, decided for the biased preference of the one with the loudest voice. We need a bridge to cross this trap, using context to get to a decision.

The Bridge: User Centricity + Use Case Specificity

#

Before asking “what technology”, clarify two things first:

1. Who is this for? Not some abstract “users”. Specific people with specific needs. What do they value? What frustrates them? What are their constraints? Don’t forget about secondary users!

2. What are they trying to do? Not “use the system”. Specific jobs to be done. What does success look like for them? What would result in failure?

These questions surface what matters. Once we know that, we can answer the critical question:

What are we optimizing for?

Not “what’s best practice” or “what’s trending”. What specific outcomes do we want to maximize? What are we willing to sacrifice to do so? This is turning “it depends” into a decision framework.

The Case Study: This Blog

#

Let’s try this out with a trivial example: the technical architecture for this blog.

Trivial because the stakes are low. A personal blog isn’t a distributed system serving millions of users. The content is public, no need to secure it. Still the decision framework is the same. The low stakes make it easy to show the reasoning without revealing confidential information.

Who Is This For and What Are They Trying to Do?

#

Primary user: The readers of this blog. Professionals interested in the content that is shared here.

What they value:

• Interesting insights, content worth reading
• Fast, distraction-free reading experience
• Mobile accessibility (they may be reading on the train or between meetings)

What they don’t care about:

• Fancy animations or interactive features
• Comments or social features (we have LinkedIn for that)
• What technology is used under the hood

Secondary user: Me, the author. I’m a tech-savvy architect wanting to write and publish easily, using the tools I’m familiar with, without losing time fighting with technology.

What I value:

• Write in Markdown with my preferred editor
• Git-based workflow (version control, branching, rollbacks, auto-deployment)
• Fast local preview with hot reload to see what I’m doing
• Zero maintenance, ideally at no cost
• Control over content and presentation

What I don’t need:

• Databases or servers to maintain
• Complex deployments with manual steps
• Fighting with WYSIWYG editors
• Paying for features I don’t use
• Platform or vendor lock-in

What do I optimize for?

#

With the users and their needs clear, we can identify what to optimize for:

1. Reader experience (highest priority)

• Distraction-free reading (no ads, no clutter)
• Mobile-responsive
• Fast page loads (< 1 second, the faster the better)
• No complications (no sign up, no login)

Why highest? This blog is to share insights. What is the point if no one sticks around to read it?

2. Author experience

• Markdown writing with automated Git workflow
• Instant local preview
• Easy to set up, zero maintenance

Why second? Primary users come first, but if it ain’t easy to write, there won’t be any content.

3. Good enough on SEO and performance

• Clean URLs, proper meta tags
• Decent lighthouse scores
• But not obsessing over 100/100
• Semantic HTML that search engines understand

Why “good enough”? Returns diminish beyond basics. Readers find me through LinkedIn and search, not because I micro-optimized Core Web Vitals.

4. Cost (minimal/free)

• Willing to pay some for hosting if it saves me time
• But not for enterprise features that are not needed
• Free tier is preferable if quality of service is good enough

Why lowest priority? My time is worth more than hosting costs. But it’s not a main driver in my context.

What do I explicitly NOT optimize for?

#

Equally important in making trade-offs: what do I choose to ignore:

• Maximum flexibility: No need for a headless CMS or a custom API
• Cutting-edge tech: No need to learn the latest framework
• Rich interactions: No comments, no live chat, no user accounts, no mailing lists
• Perfect performance: 95/100 is fine, No need for chasing 100/100
• Scalability: Static sites scale just fine, I’m not building for millions of users
• Community size: I need just what I use, not the biggest ecosystem or the most plugins

These may be valid optimization targets for other contexts. Not for this one.

The Fundamental Choices

#

With clear optimization targets, the architectural decisions become much more straightforward.

Static Site Generator vs. Hosted Platform vs. Custom Build

#

Options:

• Hosted platform (Medium, Substack, Ghost hosted)
• Static site generator (Hugo, Jekyll, Next.js, Astro)
• Custom build (Rails, Django, or roll my own)

How they score:

Decision: Use a static site generator.

Hosted platforms fail on author experience (I want the Git workflow) and vendor lock-in. Custom build fails on time and maintenance. Static generators hit all optimization targets.

Which Static Site Generator?

#

Options under consideration after a simple search:

• Hugo: Go-based, extremely fast builds, mature ecosystem
• Jekyll: Ruby-based, GitHub Pages native, large community
• Next.js: React-based, modern, flexible, can add interactivity later
• Astro: New, fast, component-based, good DX

How they score against my needs:

Decision: Use Hugo

No need for React components (Next.js strength). No desire to manage Ruby dependencies (Jekyll weakness). Astro is interesting but newer. Hugo is fast, stable, and has a good selection of themes. It is optimized for “easy writing and publishing”.

Theme: Custom vs. Pre-built

#

Options:

• Build my own custom theme (full control)
• Use a pre-built theme (faster to launch)

Decision: Use a Pre-built theme. A custom theme would take days I’d rather spend on writing good content.

A quick compare of Hugo themes and points to Blowfish because:

• Clean, professional design
• Good typography for readability
• Mobile-responsive out of the box
• Dark mode support (extra feature that some readers may appreciate)
• Well-maintained and documented

I sacrifice perfect customization for “good enough and ships today”.

Hosting: Where will our content live?

#

A quick search revealed the following options:

• GitHub Pages: Free, automatic, tightly integrated
• Netlify: Popular, generous free tier, good DX
• Cloudflare Pages: CDN-native, very fast, generous free tier
• Vercel: Great DX, optimized for Next.js
• Self-hosted VPS: Full control, more complexity, higher costs

How they score:

Decision: Cloudflare Pages.

All of the managed options meet my needs. Cloudflare Pages wins on:

• Global CDN performance (Cloudflare’s core strength)
• Generous free tier with no artificial limits
• Excellent build speed

GitHub Pages fits the bill. So do Netlify and Vercel. Cloudflare Pages is “optimized for global performance” which gives it the edge: Making pages load just that little bit faster for readers around the world.

The Outcome: Hugo + Blowfish + Cloudflare Pages

#

Not because these are “the best tools” but because they optimize for what I actually need:

✅ Reader experience: Fast loads, mobile-friendly, clean design
✅ Author experience: Write in Markdown, push to Git, auto-deployment
✅ Good enough: SEO works, performance is excellent
✅ Cost: Free tier handles my traffic easily

What did I sacrifice?

#

• Custom design (using a theme instead)
• Maximum flexibility (static site limits interactivity)
• Cutting-edge technology (Hugo is mature, not trendy)
• Optimal control (theme updates might break things)

These tradeoffs are acceptable as they don’t affect any of my optimization targets.

The Framework: Applicable Beyond Blogs

#

This works for most-if not all-architectural decisions:

1. Start with user centricity and use case specificity

• Who is this for? (Be concrete)
• What are they trying to do? (Be specific)

2. Identify optimization targets

• What matters most?
• What matters less?
• What can be ignored?

3. Evaluate options against these targets

• Not “what’s best in general”
• What’s best in this specific context

4. Make the decision

• Choose what hits the optimization targets
• Acknowledge the tradeoffs
• Decide and move forward (nothing is worse than decision latency)

5. Validate your decisions

• Did it deliver as expected on the optimization targets?
• What would you do differently next time?

The blog example is trivial. The decision framework is not.

I’ve used it for:

• Microservices vs. monolith decisions (optimize for team autonomy vs. operational simplicity)
• Database selections (optimize for read performance vs. consistency guarantees)
• Cloud provider choices (optimize for specific regional requirements vs. feature breadth)

The context changes. The decision framework stays the same.

The Key Insight

#

“It depends” is true. But it’s not useful until you know what it depends on and why.

It depends on: Who you’re serving and what they are trying to achieve. This determines what you should optimize for and what you can sacrifice.

Answer these questions first. Technology decisions become much more straightforward.

In addition: this may lead to interesting discussions and new insights: No you can’t sacrifice that! Why not? -> New stakeholders or needs may be identified! The earlier that happens the better.

This blog runs on Hugo + Blowfish + Cloudflare Pages because that stack optimizes for my context. Your context will be different. So will your optimization targets. Your decisions should be different too.

This is how you cross the “it depends” trap.