Every log line should answer three questions: when, what, and about whom.
A log line that doesn't answer all three is something you wrote for a human reading it once. Useful for development, useless for incident response.
JSON. Or logfmt. Pick one, stick with it, do not mix. Plain-text logs are unparseable at scale. Every modern logging library supports structured output. There is no defensible reason to ship plain text in 2026.
{
"ts": "2026-05-08T14:23:11.421Z",
"level": "warn",
"event": "rate_limit.exceeded",
"request_id": "req_3kz9a",
"user_id": "usr_8821",
"endpoint": "POST /api/checkout",
"current_rate": 142,
"limit": 100
}Now you can grep, group, filter, aggregate. The same line in prose is unsearchable.
Most teams degrade their log levels into noise within a year. The discipline:
The error level is the one that breaks most often. Aspirational: an ERROR log should be rare enough that a human looks at every one.
One ID, generated at the entry point of a request, propagated through every downstream call, attached to every log line. Without this, debugging a multi-service request is archaeology. With it, you grep one ID and see the whole story.
OpenTelemetry handles this automatically if you let it. Use OpenTelemetry.
Production traffic is too high to log every request fully. The naive answer is to drop log lines — and you always drop the wrong ones. The better answer is to sample: log 100% of errors and slow requests, log 1% of everything else, but keep the structure consistent so the sample can be aggregated.
Most modern logging pipelines (Honeycomb, Datadog, Grafana) support this natively. Use it. Your bill will thank you and the data quality will improve.
console.log sprinkled before deployment. You will forget at least one. Use a logger, route it through your normal pipeline.You don't need everything. We rely on two patterns in 2026:
That's it. We don't self-host Elasticsearch. We don't ship logs through a third queueing system. Simpler infrastructure has simpler failure modes when the alarm goes off at 3am.
When an incident is over, before the post-mortem, write down the single query that would have surfaced the issue fastest. If that query is hard or impossible, the logs aren't doing their job — fix the logs before you fix the bug. Teams that do this consistently halve their mean-time-to-resolution within a quarter. Teams that don't treat logs as a product end up rediscovering the same blind spots every time.
Good logs are written for the person who will read them at 3am. That person is usually you, six months from now, with less context than you have today. Write accordingly.
]]>Stop thinking of an agent as a faster typist. Think of it as a junior engineer with infinite tabs open and no biological need to sleep. The bottleneck is no longer code generation speed — it is the quality of your instructions and the precision of your verification step.
The teams getting wins in 2026 share three traits:
Renaming a symbol across 200 files, adding a parameter to every call site, converting a logging API — agents nail these. They beat any IDE refactor on multi-language repos and never miss a stale string-template usage.
Pointing an agent at an untested module with a sentence like "give me a Jest suite that covers the public API and the error branches" produces 80% of the boilerplate. The 20% you fix yourself is the part where you remember what the module is actually supposed to do.
Schema migrations, API version bumps, framework upgrades. The agent reads the diff of the upstream changelog, scans your code, and produces a plan. You read the plan, push back on three things, and you're done in an afternoon what used to be a week.
Agents still get lost in ambient context — codebases where the rule about how things are done is implicit, scattered across Slack threads, or stored exclusively in one tenured engineer's head. If your team can't articulate why the build pipeline does what it does, the agent will not magically intuit it.
They also struggle with cross-cutting product decisions. "Refactor checkout to use the new pricing engine" is a product question dressed as an engineering task. The agent will pick a plausible interpretation and run with it. Sometimes that interpretation is wrong in a way you only discover at the next billing cycle.
The unit economics matter again. A long-running agent task can burn through tokens fast. Our rule of thumb in 2026: budget the cost the same way you'd budget a contractor's day rate. If a task feels like it should cost $20 and you're at $400, something is wrong — usually the agent is in a loop or hallucinating dependencies. Kill it and re-scope.
The features we most often hand to an agent in 2026 are the ones nobody wanted to write themselves:
Treat agents as force multipliers, not replacements. Our team of six ships roughly what a team of nine shipped two years ago, and the gain comes almost entirely from removing the work nobody enjoyed in the first place. Code review headcount, on the other hand, has not gone down. Senior engineers spend more time reviewing diffs and less time writing them. That is the trade.
The pattern that keeps proving itself: agents are excellent at making your codebase more like itself and dangerous at changing what your codebase is. Use them accordingly.
]]>Native CSS custom properties have been usable for years. In 2026 they're strictly better than Sass variables for almost everything — runtime updatable, scoped, debuggable in the browser. We still use Sass on legacy codebases, but new projects don't need it.
Native nesting is universal. oklch(), color-mix(), and relative color syntax cover the cases that needed postcss-color-function. The build pipeline gets shorter.
The runtime cost of styled-components, emotion, and friends never went down. The build-time alternatives (Vanilla Extract, Linaria) survived and are pleasant, but native CSS is now expressive enough that "I need JS to style this" is rarely true. Hover states, focus states, dark mode, container queries — all native, all without a runtime.
Tailwind and its kin are still good tools. We use Tailwind on most client work. But the pattern of "every component is a thousand utility classes" doesn't scale aesthetically or maintainably. The 2026 approach is utilities for layout and spacing, semantic CSS for the component-specific bits, both in the same file.
The exact tooling matters less than the discipline. Whether the tokens live in Style Dictionary, in Tailwind's config, or in a hand-written set of CSS custom properties, every team that ships consistent UI has tokens.
Modern browsers agree more than they used to. They still don't agree completely. A small reset (or Tailwind's preflight) at the top of the cascade saves a category of bugs that we still see.
BEM, semantic class names, utility classes — any of these are fine. What still doesn't work is "no convention." A new contributor to a codebase needs to be able to write a class name and have a reasonable expectation of what it should look like.
The single biggest practical win of the last few years. Components style themselves based on their container, not the viewport. The mental model of "this card looks like X when it's in a sidebar and like Y when it's in a grid" finally has a native primitive.
Specificity wars are now solvable. @layer reset, framework, custom; at the top of your stylesheet imposes a deterministic order that's easier to reason about than !important ever was.
:has()The parent selector we waited 20 years for. Real, supported, immensely useful for "style this thing based on what it contains."
Reads like Sass, works without a build step. The biggest quality-of-life improvement to writing CSS in years.
Cross-document and within-document. Smooth page transitions are now achievable without a framework. We use this on every content site we ship.
:has() freely.CSS is no longer the language people complain about. It is the language people now reach for first, instead of last. The tools that filled the gaps for a decade are mostly optional. If you haven't looked at native CSS seriously since 2020, you're carrying tooling weight that doesn't earn its keep anymore.
]]>If your output is a folder of static files (it usually is), the entire deploy is one command:
npx wrangler pages deploy ./dist --project-name=your-projectThe first time it runs, Wrangler creates the project. Every subsequent run uploads a new immutable deployment, gives you a unique preview URL, and atomically swaps production once you confirm. No build pipeline, no GitHub Actions, no waiting in a queue.
We keep this layout for every Pages project:
The principle: a junior teammate should be able to ship a fix to production by running one command they did not have to write.
Out of the box, Pages serves files with reasonable defaults. We override two categories:
/*.css
Cache-Control: public, max-age=31536000, immutable
/*.svg
Cache-Control: public, max-age=31536000, immutableAnything content-hashed gets a year. Pages handles invalidation by serving new hashes on the next deploy.
/*.html
Cache-Control: public, max-age=0, must-revalidateHTML is always re-validated. The CDN still caches it, but stale-while-revalidate keeps users on the latest deploy without us touching anything.
If you're moving a legacy site (we do this often), preserve URLs religiously. Pages reads _redirects in Netlify format. One line per redirect, glob patterns are allowed:
/old-blog/* /blog/:splat 301
/feed/ /feed.xml 301
/wp-content/* / 404Run the redirects through a check before deploying — broken redirects look the same as working ones until somebody links to one.
Add the domain in the Pages dashboard. If the domain is already on Cloudflare, DNS is automatic — Pages picks the right CNAME for you. If it isn't, you'll get the records to add. SSL is free, renews itself, and the certificate is issued before the page reloads.
The thing that still trips people up: www. vs apex. Decide which one is canonical, set up a redirect for the other, and put the right one in your sitemap. Pages will happily serve both, but Google does not love seeing duplicates.
Pages Functions are a flat /functions/ directory of route handlers. They run on Workers, billed at Workers prices, and there is no cold start to worry about. The 2026 advice: if you can avoid them, do. Every function is something else to test, monitor, and reason about. Reach for them only when:
Deploy speed. Even on a 5,000-file site, a fresh deploy completes in under a minute. The diff-uploading is doing real work.
Preview URLs are first-class. Every deploy gets one. We send those links to clients for sign-off without anyone learning what "staging" means.
Wrangler quirks. The --commit-message flag is useful — those messages show up in the Pages dashboard. We populate it with a timestamp and the commit hash, which makes rollbacks much less guesswork.
Pages is not a CMS. If your content team needs a click-through publishing flow, you need a CMS in front of Pages — we usually pair it with a headless one and a webhook that triggers redeploy.sh. The split adds complexity worth thinking about before committing.
And for genuinely dynamic apps — auth-heavy, database-heavy, server-state-heavy — Pages is the wrong shape. Reach for Workers proper, or somebody else's platform.
For everything in between, the answer is still: ship the folder, walk away, do something else.
]]>Cloudflare Workers, Vercel Edge, Deno Deploy, Fastly Compute, Netlify Edge. Code runs in hundreds of data centres globally, milliseconds from the user. V8 isolates rather than full VMs, so cold start is effectively zero. Limited by language (JS/TS, WASM), resource ceilings, and the fact that your database is probably not next door.
An EC2 instance, a Fly machine, a managed container service, a serverless function in one or two regions. Full runtime, full language choice, full filesystem. Latency to the user depends on where they are and where the region is.
The browser. Increasingly capable: WASM, WebGPU, OPFS, persistent workers. For some workloads — heavy data manipulation, image processing, certain ML inference — running in the browser is faster than any server-side path, because the data is already there.
Code runs at the location closest to the data it needs.
If the data is mostly the user's session and a few cached values: edge.
If the data is in your primary database: near the primary database.
If the data is the user's own files: their machine.
Almost every architectural pain point we've audited in 2026 came from violating this rule — running auth checks at the edge that needed to make six database round-trips, or running heavy compute on a regional origin when the inputs were on the user's phone.
Teams discover that edge runtimes are fast and start pushing everything they can to the edge. Three months later they have a complex distributed architecture for what could be a single regional service, and they've introduced subtle bugs where the edge code and the origin code disagree about the state of the world.
The edge is a powerful tool. It is not a free upgrade. Every hop you add to a request path is a hop you have to monitor, version, and debug. We try to keep the request path as simple as the latency budget allows, and no simpler.
The honest answer is usually: most routes stay at the regional origin, a small but high-value set move to the edge, and a growing fraction move to the user's device. The architecture diagram looks worse for it — three locations instead of one — but the user experience and the cost structure are both better.
"Run it at the edge" is not an architectural strategy. It's a tool you reach for when the data and latency profile of a specific route justifies it. The teams getting wins in 2026 picked one or two routes per app, ran them at the edge with discipline, and left the rest alone. The teams burning cycles on edge migrations of routes that didn't need it learned that lesson the slower way.
]]>Bun is meaningfully faster for the things it's faster at, drop-in compatible for most things it claims to be, and still occasionally surprises you in ways Node never would. We use both. The choice is per-project, not per-team.
If you're doing anything Lambda-shaped or CLI-shaped — short-lived processes, scripts, build tools — Bun starts up in a fraction of the time. We replaced our internal CLI tools with Bun and the difference is felt every single day.
bun test is the test runner Node should have shipped in 2018. Jest-compatible API, zero config, fast enough that watch mode is actually pleasant. We migrated our smaller services off Jest entirely.
Running TypeScript or JSX without a build step is genuinely useful for prototypes and internal tools. The Bun bundler is no replacement for esbuild or Rolldown for app builds, but for "run this script directly," it removes a category of friction.
bun install is fast in a way that changes how you treat node_modules. We've stopped caching it aggressively in CI for some projects — it's faster to install from scratch than to validate a cache.
Steady-state HTTP throughput on a properly-tuned Node process is competitive with or better than Bun for most workloads we've measured. The cold-start advantage doesn't matter for a process that lives for weeks.
Some packages we depend on still misbehave under Bun. Native modules, anything that does clever things with the loader, certain telemetry libraries — every few months we hit something. The fix is usually pinning to Node for that specific service.
Production-grade tracing and profiling tooling is still Node-first. Bun's diagnostic story has improved, but if your incident response runbook involves --inspect, heap snapshots, or specific APM agents, Node is the lower-risk choice.
Bun's headline is "drop-in Node replacement." This is true most of the time. The 5% of the time it isn't, you find out at the worst possible moment. We've been burned by:
process.versions shape differences breaking a version check.None of these are showstoppers. All of them ate a half day before we found them. Treat Bun as a Node-compatible runtime, not as Node. Test the path that matters.
For a new service:
Don't pick a runtime for sentimental reasons. Bun is good. Node is good. The interesting questions in 2026 are about where your code runs (edge, serverless, container, longlived VM) more than which JS runtime it runs on. Optimise the choice for that, and the runtime question usually answers itself.
]]>Relational data — yes. JSON documents — yes, with proper indexing. Full-text search — yes, well enough for most needs. Vector search — yes, since pgvector hit production. Time series — yes, with TimescaleDB or even just well-designed indexes. Geospatial — yes, with PostGIS.
Each of those workloads has a "best in class" specialised database. Postgres is not the best at any of them. Postgres is good enough at all of them, which means you can defer the decision to specialise until you have data that justifies it. Most projects never reach that data.
Managed Postgres is now boringly good. RDS, Cloud SQL, Neon, Supabase, Crunchy Bridge, Fly Postgres — pick a vendor based on price and region. Backups, point-in-time recovery, read replicas, connection pooling, automatic minor version upgrades. The operational burden of running Postgres in 2026 is meaningfully lower than it was in 2018.
Native logical replication, change-data-capture via the WAL, and tools like Debezium make Postgres a viable source of truth for event-driven architectures. The "we need Kafka because our database can't emit events" argument has weakened.
pgvector for vectors. pg_cron for scheduled jobs. pgmq for queues. PostGIS for geo. pgaudit for compliance. Each extension means one less external dependency in your architecture. We've killed entire microservices by replacing them with a Postgres extension.
Not everywhere. The boundary conditions:
Notice the pattern: we leave Postgres for workloads where its general-purpose nature is a real liability, not for workloads where someone wrote a blog post claiming it doesn't scale.
Almost every "we outgrew Postgres" story we've audited turned out to be "we had a bad schema, no indexes, and unbounded query patterns." The actual hard scaling limits of well-tuned Postgres are far higher than most teams reach. Things that helped us:
EXPLAIN ANALYZE. Most slow queries have a simple cause and a simple fix.The cost of changing databases is enormous. The cost of staying on a database that no longer fits is also enormous. We default to Postgres because it pushes the change-database decision out the furthest. By the time we've genuinely outgrown it, we usually know exactly what we need and the migration is a deliberate engineering project, not a panic.
If you're starting a new project this year and you don't have a specific reason to pick something else, you should pick Postgres. The reasons to pick something else are real, but they should be specific. "It might not scale" is not a reason. "Our write pattern is 50k/s of time-series data and we've modelled the load" is a reason.
]]>"Migrate to TypeScript" is not a goal. It's a path. Before starting, decide what you're actually buying:
strictNullChecks to be on, eventually.allowJs + JSDoc almost for free.These goals require very different amounts of work. The team that mistakes "better tooling experience" for "strict type safety" will be unhappy halfway through.
Add a tsconfig.json with allowJs: true and checkJs: true. Don't rename a single file. Add JSDoc type annotations to existing JS files. The editor lights up, errors get caught, and the team gets a feel for the language without committing.
This is the right first step on any codebase larger than a few thousand lines. It buys 70% of the type-safety value at 10% of the conversion cost. Skip the temptation to rename files until the JSDoc layer is mature.
Once JSDoc is in place, rename leaf modules — utilities, pure functions, small components — first. The dependency graph means renaming a leaf is contained. Renaming a hub means you'll be touching every consumer.
For modules that have to keep working with un-converted callers, write a small barrier file that exports the original API with TypeScript signatures. The implementation moves to a .ts file. The barrier handles the boundary. Callers can be converted at their own pace.
Turn on noImplicitAny first. Live with it for a sprint. Then strictNullChecks. Then the rest of strict. Flipping the whole strict flag on day one produces an unmanageable error list. Flipping it one flag at a time produces a finite list per sprint.
Tempting on small codebases. Disastrous on anything real. Even on 30k-line projects we saw productive teams burn six weeks on rewrites that produced no business value and introduced regressions.
anyStarting with any everywhere just to get the codebase to compile feels productive and is, in fact, the worst of both worlds. You pay the TypeScript tax (build step, tooling, mental overhead) and get none of the safety. If a type is genuinely unknown, use unknown and narrow at the use site. any is for two specific cases: shimming a third-party library with bad types, and emergency hotfixes you intend to revisit within a week.
TypeScript will let you build deep class hierarchies. Don't. The idiomatic TS code is closer to "Java verbosity with TS's structural type system" — interfaces, discriminated unions, plain functions. You'll spend less time arguing about generic variance and more time shipping.
tsc --noEmit. Stops type regressions from landing.On a 60k-line Node API: about a quarter of senior-engineer time, spread over two quarters, plus elevated PR review burden during the transition. We caught roughly a bug a week that the type system surfaced before runtime. The bugs caught included two that would have shipped to production undetected. We consider that a positive ROI even ignoring the long-term maintenance benefit.
TypeScript is worth migrating to on any codebase you expect to live three more years. It is not worth migrating something you'll deprecate in twelve months. The migration is a project, not a checkbox, and the team needs to be told that upfront. Done well, it's one of the highest-leverage investments you can make in a JavaScript codebase's long-term health.
]]>One server. Many customers. A single Apache or LiteSpeed process. PHP and MySQL preinstalled. cPanel or DirectAdmin or Plesk on top. You SSH in (maybe), you upload files (probably), and your site is online.
The model has obvious downsides: noisy neighbours, no isolation, security only as good as the weakest customer's outdated WordPress install. It also has one large upside: it is the simplest possible product to buy and the easiest possible product to use for non-developers. That hasn't changed.
Cloudflare Pages, Netlify, Vercel — all of which have free tiers that handle a non-trivial site. For static sites, shared hosting is now objectively worse than free. There is no scenario in 2026 where a static-content site benefits from being on cPanel.
WP Engine, Kinsta, Pressable, and now Cloudflare's own WordPress offering have hollowed out the traditional shared host's flagship use case. For $20-30/month you get tuned caching, automatic updates, security scanning, and isolation. The price gap is no longer the deciding factor for most serious WordPress operators.
A 2GB VPS at Hetzner, Vultr, or DigitalOcean costs $5-10/month. With a couple of hours of setup, that's comparable on price to a shared host and meaningfully better in every other dimension. The skill cost has gone down too — managed images, one-click stacks, and AI-assisted devops mean spinning up a VPS is more accessible than it's ever been.
Shared hosting in 2026 is a product for non-developers running small WordPress sites. That is a real market and the better operators serve it well. For anyone else — anyone who reads articles like this one — the answer is almost always somewhere else. A free static host, a managed platform, or a $5 VPS will give you a better product for less money or no money. The shared hosting decision tree in 2026 is short, and most branches lead elsewhere.
]]>Wireframes, color palettes, copy variants, alt text suggestions, microcopy for empty states. The model produces a competent first draft in seconds; the designer's job becomes editorial. The category of work that used to be "stare at a blank Figma" has compressed dramatically.
Color contrast, semantic structure, alt text quality, ARIA correctness — AI tooling catches things a manual review misses, especially on large sites. Pair it with axe-core or a similar deterministic linter for best results.
Hero illustrations, icon sets, placeholder photography. The quality is consistently good enough for marketing surfaces, especially for B2B sites where the visuals don't need to be art. The savings on stock photo licensing alone justify the workflow shift.
The Figma-to-React workflows are usable in 2026. They are not a replacement for a thoughtful engineer, but they are a real accelerant for component scaffolding. Used carefully, you go from design system to working components in a fraction of the time.
The model doesn't know your brand. It doesn't know your last six months of A/B tests. It doesn't know that your design system already has a button variant for this case. Output that ships without a designer in the loop is consistently mediocre and inconsistent with the rest of the product.
"AI generates a unique experience for every visitor" sounds great in a deck and consistently underperforms in production. Most users want what works, not what's clever. Personalization at the variant level is fine; at the layout level it is usually a distraction from the core proposition.
If your AI workflow makes the design pipeline faster by 3x but the development pipeline slower by 5x because the handoff quality dropped, you've made the company slower. The honest measurement is end-to-end, not per-discipline.
AI hasn't replaced web designers. It has changed what work a designer does in a day. The designers thriving in 2026 are the ones who treated the tools as a force multiplier on judgement, not as a replacement for it. The ones who refused to use them at all are quietly less productive. The ones who used them uncritically shipped uncritical work. The boring middle ground turned out to be where the value was.
]]>The entire LLM stack — training, inference, agent frameworks, evaluation — runs on Python. PyTorch, JAX, the Hugging Face ecosystem, LangChain, LlamaIndex, every major agent framework. If you do any work adjacent to AI, you write Python, even if you don't want to.
This is not "Python is a good ML language." This is "Python is the only language where the libraries you need exist with first-class support." That is a Schelling point, and Schelling points are sticky.
Quietly, Python has become the universal solvent of software. Data pipelines, automation scripts, internal tools, prototyping, devops, scientific computing — anything where you need to wire systems together with code that humans can read. The language is a near-perfect fit for that category and very little has emerged to challenge it.
The GIL is finally optional in 3.13's free-threaded build. Sub-interpreters are usable. The JIT lands properly in 3.14. The "Python is slow" complaint, while still partially true for some workloads, is meaningfully less true than it was in 2020.
Five years ago, type hints were a curiosity adopted by serious teams. In 2026 they are table-stakes for any codebase you want to be maintainable past one person. The combination of strict mypy/pyright + Pydantic + FastAPI's patterns has made Python feel like a different language from the duck-typed 2.7 you remember.
Poetry, hatch, uv — the long packaging civil war ended with uv (Astral's package manager) winning most adoption. pyproject.toml is universal. requirements.txt still exists but mostly as an output, not a source of truth.
It is not the right answer for everything. Roughly, in 2026 we don't reach for Python when:
"use strict" won the JavaScript world.Python won the readability argument. It won the "good enough for most things" argument. It won the ML lottery. Languages don't lose those positions easily, and the language is using its time to fix the things that legitimately held it back.
If you are picking a language for a new project in 2026 and you don't have a specific reason not to, Python is rarely the wrong answer.
]]>That trade broke in 2024. By 2026, "web crawler" is a much wider category, and the implicit social contract that used to govern it has fragmented. Here's what changed and what to do about it.
The mechanics haven't changed. A crawler:
robots.txt.What changed is who's running them, and what they want.
Googlebot, Bingbot. Still operate roughly under the original contract: read the site, index it, send users back. Honour robots.txt and crawl-delay directives. We don't block these.
GPTBot, ClaudeBot, PerplexityBot, Anthropic's, OpenAI's, Google's training crawlers, and dozens of smaller ones. They read your site to train or augment language models. Whether they send users back is, depending on the operator, anything from "occasionally with attribution" to "no, the model just absorbed your content."
Most respect robots.txt when explicitly named. Some don't.
Everything else. Price scrapers, content thieves, SEO research tools, security scanners. Often spoof their user agent. Often ignore robots.txt. Often run from rotating residential IPs to evade detection.
A defensible default for a content site:
# Allow established search engines
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /
# Decide consciously about AI training
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: PerplexityBot
Allow: /
# Block the rest by default
User-agent: *
Disallow: /
Sitemap: https://example.com/sitemap.xmlWhether you Allow or Disallow each AI crawler is a judgment about your business model. If you sell content, you probably want to Disallow. If you sell credibility and want to be cited by AI assistants, you probably want to Allow.
Stop a determined scraper. It's a voluntary protocol. The bots that ignore it are the ones you most want to block.
Effective defences in 2026 layer multiple controls:
You probably don't need to fight every crawler. You need to know which ones are valuable, which ones are extracting value without giving any back, and which ones are actively harmful. Make conscious decisions in your robots.txt, then let the edge handle the bad actors. The energy you spend running cat-and-mouse with every new crawler is energy you're not spending on the work that pays.
HTTP, JSON, resource-shaped URLs, and an OpenAPI spec. Boring, well-understood, and supported by every language and tool you can name. For public APIs and most external integrations, REST is what people expect and what tooling supports.
The strengths haven't changed: cacheable on the edge, debuggable with curl, easy to mock. The downsides also haven't changed: chatty for related-resource fetches, schema drift if you're lax, easy to design badly.
The case for GraphQL was always strongest where you have many different consumers (web, mobile, partner apps) that need different shapes of the same underlying data. That case is unchanged in 2026.
What did change:
We still don't reach for GraphQL on small APIs. The setup cost outpaces the benefit until the consumer count justifies it.
If both sides are services you control, gRPC is hard to beat. Protocol buffers are smaller and faster than JSON. Streaming is first-class. Code generation for clients means you can't accidentally diverge schemas.
The catch: gRPC over the public web is awkward. Browsers need gRPC-Web, which means a translation layer. For browser-facing APIs we stick to REST or GraphQL.
The Model Context Protocol — a way for AI agents and applications to expose tools and data to each other. It is not a replacement for REST or gRPC; it is a specific contract for "this thing can be used by an LLM."
If your business is going to be consumed by AI agents (and most of them will be), MCP is becoming the lingua franca for that consumption path. It sits on top of JSON-RPC, has a standard manifest, and is supported by every major AI tooling vendor.
Think of MCP as "OpenAPI but for tools an agent can call" — same problem space (publish your contract), different audience (machines that reason).
Picking a protocol because it's in fashion. We've audited too many architectures where someone introduced GraphQL for a single-client API, or gRPC inside a system that has one browser frontend. The complexity tax is real. The protocol should serve the integration, not the other way around.
Interoperability is mostly a contract problem, not a transport problem. The conversation with your counterparty about how the contract evolves is more important than the wire format you choose to send it over.
]]>If you publish a number nobody else has, journalists and other operators will link to it. State of X surveys, benchmarks, internal data presented honestly. The link economy hasn't found a substitute for "I measured this and here's what I found."
A free calculator that does one job well — a colour-contrast checker, a JSON-to-CSV converter, a tax-aware mortgage tool — accumulates links indefinitely because it is genuinely useful and easy to reference. The bar is "would I bookmark this myself."
The "best resource on the internet for X" page. These take months to write, are kept updated, and earn links the way a textbook earns citations. Most blogs aren't willing to invest in one. The ones that are see compounding returns.
Other people's audiences. Show up on someone else's show with something worth saying and the link comes free. Difficult to scale; very effective when it lands.
In 2026 a meaningful share of discovery happens inside AI assistants rather than search engines. Whether your content gets cited by a large model when someone asks about your topic is the new "page one of Google" — and the optimisation for it is somewhere between SEO and trust signals.
What we observe:
Stop thinking about "link building" as a discrete activity. Think about being worth linking to. If your site is the best resource on a given topic, links will follow without manual outreach. If your site is the fifth-best, no amount of outreach campaigns will change that durably.
The work of building authority and the work of "doing SEO" have converged. That is mostly good news for honest businesses. It is bad news for people whose business model assumed a market for cheap, manipulated authority.
]]>A serious visitor management system in 2026 covers four things, in roughly this order of importance:
An iPad on a stand and an off-the-shelf SaaS tool is genuinely the right answer. Don't over-engineer. The total cost of ownership of a custom-built system here is many multiples of the SaaS subscription.
This is where most of our consulting work sits. You need integration with your IdP for hosts, your facility management system for room booking, and your security badge system for access control. The off-the-shelf SaaS works but has to be configured and integrated thoughtfully. Plan for a quarter of integration work, not a week.
Off-the-shelf still wins, but the buying process is two years long and the deployment is bespoke. The decisive factor is rarely the visitor flow itself — it is data residency, retention policy, and the audit log's compatibility with the legal team's comfort.
The shift we see this year is that "visitor management" is converging with "identity and access management." Modern systems issue short-lived credentials tied to a real identity provider (a Microsoft Entra guest account, a Google Workspace external user) rather than a self-attested name on a tablet. The implication: who somebody is, what they signed, and when they entered are now one record, verifiable cryptographically. That changes what is possible downstream — automated compliance reports, cross-site identity, single-pane-of-glass for security teams.
Buy something. Don't build it. Spend your budget on the integration and the policy work, not on rewriting the badge printer driver. The interesting differentiation for your business is almost never the front desk.
]]>Still the default. Still the right call for the majority of enterprise Java work. The ecosystem is unmatched, the documentation is exhaustive, and a junior engineer arriving on a Spring Boot codebase has a head start. The downside — boot time, memory footprint, runtime reflection — has been substantially mitigated by GraalVM native images and Spring 6's AOT processing. We use it for almost every long-lived enterprise service.
The serious challenger. Built around the assumption that you might compile to a native binary and run on Kubernetes with millisecond startup. Sub-100ms cold starts, low memory ceilings, sensible defaults. For greenfield microservices where deployment density matters, Quarkus is now our first thought.
The third major framework in this space. Compile-time DI rather than reflection. Smaller community than Quarkus but equally credible technology. We reach for it when an existing team has experience with it.
Oracle's offering. Two flavours: SE (programmatic) and MP (declarative MicroProfile). Solid technology that doesn't get enough attention because Oracle's brand makes some teams nervous. If you need MicroProfile compliance, it's worth considering.
GraalVM native compilation is no longer the exotic option. We ship Quarkus and Spring Boot apps as native binaries by default for anything serverless-shaped. The build time penalty is real but the runtime profile — fast start, low memory — pays for itself within weeks.
Java 21 virtual threads (Project Loom) mean you can write blocking code without paying the thread-per-request memory cost. Whole categories of "we have to go reactive" decisions can now be revisited. Reactive frameworks like WebFlux or Vert.x are still valid choices, but they are no longer the only path to high concurrency.
Domain modelling in Java circa 2026 looks more like Kotlin or Scala than the JavaBeans of the 2010s. Records, sealed types, and pattern matching cover most of what you used to reach for Lombok or third-party libs to provide.
XML configuration. Container vendor lock-in. Six-month deployment cycles. Setting up a CI pipeline that requires a 4GB Docker image. The Java stack is meaningfully better in 2026 than it was a decade ago, and most of the criticism aimed at it now is criticism of a Java that no longer exists.
If you have not looked seriously at the Java ecosystem since 2019, look again. The frameworks haven't just iterated — they've repositioned.
]]>If you take on PHP contract work this year, you will almost certainly be working on one of three stacks. Anything else is a curiosity, a legacy maintenance gig, or a red flag.
Still the dominant choice for new PHP apps. The ecosystem (Forge, Vapor, Nova, Livewire) has converged on a coherent story for the full lifecycle of an app — build, deploy, scale, observe. Most agencies default to it for a reason: hiring is easy, the docs are first-rate, and the framework keeps shipping pragmatic features.
Where Laravel optimises for developer happiness, Symfony optimises for boring, durable, enterprise correctness. The component model means you can pull in just the routing or just the messenger queue. We reach for it on long-lived projects where five years of stability matters more than five days of velocity.
For genuinely small services — internal tools, glue APIs, single-purpose endpoints — a micro framework or just a PSR-15 middleware stack is the right size. Don't reach for Laravel to expose three routes.
Some advice that mattered in 2018 has aged badly:
For a typical client conversation in 2026:
The hardest part of contract PHP work in 2026 is not picking a framework. It is convincing a client whose project is on a pre-7.4 PHP version and an abandoned framework that the cost of staying is now higher than the cost of moving. We see this conversation every quarter. The numbers usually win, eventually.
If you are inheriting a project: spend a day inventorying the framework version, the PHP version, the dependency lockfile and the test coverage before you commit to a delivery date. That single day saves the next twelve.
]]>