CODERCOPS — Blog

How to Hire a Full-Stack Developer in 2026: What the Job Actually Requires

Anurag Verma — Thu, 18 Jun 2026 00:00:00 GMT

Every agency and startup I have talked to says they are looking for a full-stack developer. Almost none of them have written down what that means for their specific context, which is why the search takes so long and the wrong hires happen so often.

Full-stack is not a skill set. It is a claim about coverage. It means “this person can work on both ends of the system without handing off.” But coverage levels vary enormously. A developer who is 90% frontend and 10% backend is technically full-stack. So is someone who is evenly split. So is someone who started as a backend engineer and picked up React for a product-focused role. These are very different hires, and the gap only shows up after the offer letter is signed.

The fix is to define the role before you start screening, and then to design a screen that reveals real capability on both ends rather than accepting a candidate’s self-assessment.

What full-stack means in 2026

In practice, most full-stack job listings in 2026 mean some combination of:

Frontend: React, Next.js, or occasionally Vue or Svelte. TypeScript is assumed. Styling via Tailwind or CSS Modules. State management via TanStack Query for server state, Zustand or React context for client state. Familiarity with component libraries like shadcn/ui.

Backend: Node.js (Express, Fastify, or Hono) or Python (FastAPI, Django). A SQL database, usually Postgres. ORM or query builder (Prisma, Drizzle, SQLAlchemy). Basic authentication, often via a third-party library. Some familiarity with deployment to a managed platform.

The connective tissue: TypeScript types shared between frontend and backend. REST or tRPC for the contract. Environment configuration. CI/CD basics. Some understanding of the runtime environment.

If your stack diverges significantly from this, say so in the job description. A developer who has built React and Node.js apps for three years may have zero experience with a mobile frontend, a Go backend, or a GraphQL API. Assuming otherwise wastes everyone’s time.

The most common hiring mistake

Teams hire someone who is excellent on one end and genuinely mediocre on the other. The candidate presents as full-stack, and nothing in the standard interview process contradicts that because the interview is not designed to test both ends independently.

The frontend-heavy candidate builds beautiful, responsive UIs and then writes backend code that returns 200 for validation errors, uses unbounded database queries, and has no error handling. The first production incident teaches the team what they missed.

The backend-heavy candidate builds rock-solid APIs and then writes frontend code with no loading states, no error boundaries, no accessibility, and inline styles everywhere. Users complain. The UX degrades.

Neither of these is a bad developer. They are well-suited for one role and miscast in the other. The problem is not the candidate; it is the screening process.

What to screen for

The most reliable screen is a combined task. Give the candidate a prompt that requires both ends: build a feature that stores and retrieves data, with a backend endpoint and a frontend component that calls it.

A good prompt: “Add a simple todo list. There should be a GET endpoint that returns items and a POST endpoint that adds one. The frontend should show the list, handle loading, and show an error message if the request fails. TypeScript throughout.”

This task is intentionally small. You are not looking for production-grade code. You are looking for what the candidate thinks about when left to their own devices.

On the backend, watch for:

Basic input validation (does a POST with an empty body crash the server or return a 400?)
Appropriate status codes
Some form of error handling, even minimal
Code that would not fail silently in production

On the frontend, watch for:

A loading state, even a simple one
An error state when the API call fails
Types for the data structure
Reasonable component structure (not everything in one giant file)

Most candidates will do the task they are more comfortable with well and cut corners on the other. The way they cut corners tells you where their depth actually is.

The interview questions that matter

Beyond the take-home, a live conversation can fill in context.

For a senior full-stack candidate, ask: “Walk me through a time you owned an end-to-end feature, from data model to UI. What decisions did you make that you would change now?” This reveals how they reason about the full system and whether they have thought about their own tradeoffs.

For any level, ask: “If the API is down, what does the user experience in your frontend?” A frontend-first thinker will describe error states and retry logic. A backend-first thinker will often describe the API not being down rather than answering the frontend question. Pay attention to which end they naturally think from.

Ask: “How do you handle a database schema change that breaks a deployed frontend?” This tests whether they understand the deployment contract between the two halves of a full-stack system.

When not to hire full-stack

Full-stack generalists have a real limitation: the breadth comes at the cost of depth. This is fine for most situations, and actively valuable in small teams where one person needs to ship features without coordination overhead. It is a problem when one end of the stack is where most of your product complexity lives.

If your product’s competitive edge is a complex data visualization layer, a high-performance real-time UI, or a deeply accessible interface, a specialist frontend engineer will outperform a full-stack hire. They will write better accessibility code, make better performance tradeoffs, and understand the browser rendering model at a level most full-stack developers do not.

If your edge is in processing complex data at scale, running background jobs with high reliability, or building an API that dozens of clients depend on, a specialist backend engineer is the right call. The full-stack hire will reach the limits of their backend depth at exactly the moment the product gets interesting.

Connecting to the hiring cluster

The other hiring guides in this series cover the specialized roles. If you need React specifically, the React developer screen goes deeper on frontend signals. For backend Node.js specifically, the Node.js developer hiring guide covers the async and TypeScript screens.

For the total cost of each hiring model, including the cost of getting it wrong, what it costs to hire a developer in 2026 breaks down the math. For alternatives to in-house hiring when the full-stack need is project-based, the agency vs freelancer vs in-house framework covers when each model makes sense.

A practical note on salary

Full-stack developers cost more than specialists at the same seniority level, because the combination is rarer. Budget 10-20% above what you would pay a strong specialist on either end. The market reflects the real difficulty of finding someone who is genuinely capable on both sides, not just self-described that way.

If you find a candidate who is strong on both ends, do not lose them on offer. The screening process to get there is long enough that starting over costs more than the delta.

How to Hire a Node.js Developer in 2026: The Screen That Finds Real Backend Engineers

Prathviraj Singh — Thu, 18 Jun 2026 00:00:00 GMT

Most Node.js hiring goes wrong at the job description. The team writes “Node.js developer,” posts it, and then spends two weeks screening candidates who all claim the same credential but differ wildly in what they can actually do.

Part of this is the ecosystem’s fault. Node.js in 2026 spans several distinct skill profiles. There are Express developers who have been shipping CRUD APIs since 2017 and whose mental model is largely unchanged. There are Fastify engineers who care deeply about throughput and plugin lifecycle. There are NestJS teams who bring Java-style patterns to JavaScript. There are people building on Hono for Cloudflare Workers or Bun runtimes who would not call themselves Node.js developers at all. They all fit under one label.

The screen has to do the disambiguation work the job description cannot.

What the event loop question is actually testing

Ask every candidate: “What is the Node.js event loop, and why does it matter for an HTTP server?”

This question sounds like trivia. It is not. A developer who cannot answer it cannot diagnose a slow API. They cannot explain why a synchronous operation inside a request handler is dangerous. They will not understand why Promise.all with 100 concurrent database queries causes different problems than 100 sequential awaits.

A passing answer for a mid-level engineer: they know the event loop is single-threaded, that I/O operations are offloaded to libuv’s thread pool and callbacks are queued, and that CPU-heavy synchronous work blocks the entire process. They do not need to know libuv internals, but they need to know the implication.

A passing answer for a senior: all of the above, plus something about worker threads or child processes for CPU work, mention of the microtask queue and how it differs from the macrotask queue, and a real example from their own work where this caused a production problem.

A failing answer: anything that treats Node.js concurrency as roughly equivalent to multi-threading.

The TypeScript question is not optional anymore

There was a window where asking for TypeScript in a Node.js role was a nice-to-have. That window closed around 2023. The major frameworks (NestJS, Fastify, Hono) assume TypeScript. The ORMs (Prisma, Drizzle) are built around TypeScript’s type system. New hires who do not know it slow the team down within the first week.

The screen for TypeScript is not “can they write a type.” It is: do they understand what TypeScript actually adds? Can they explain a generic function? Can they write a type-safe error handler that differentiates between a database error and a validation error? Can they set up a project’s tsconfig.json without copying one from StackOverflow?

Watch for candidates who describe TypeScript as “JavaScript with types added on top.” That framing usually means they write any whenever the type gets complicated, which undermines the value entirely.

Frameworks: what they pick and why

The framework question reveals how a candidate thinks about tradeoffs.

Ask them which framework they would use for a new internal JSON API and why. Do not accept “whatever the team uses.” Push for their preference in a greenfield context.

Good answer signals: they have a reason beyond familiarity. They mention performance characteristics, plugin systems, validation, or the trade between boilerplate and flexibility. They can name something they dislike about their preferred choice.

Weaker signals: they can only name Express because it is what they learned first, or they recommend NestJS because “it is enterprise” without being able to say what that means for a two-person team.

The frameworks worth knowing in order of market presence:

Framework	Best fit	Known for
Express	Simple APIs, existing codebases	Minimal, flexible, enormous ecosystem
Fastify	Performance-sensitive services	Plugin lifecycle, schema validation, speed
NestJS	Large teams, enterprise patterns	Decorators, DI, Angular-like structure
Hono	Edge runtimes, Bun, Cloudflare Workers	Tiny footprint, runtime-agnostic
ElysiaJS	Bun-first, end-to-end types	Type-safe ergonomics, Bun runtime speed

A candidate who has used two or three of these and can explain when they would not use their favorite is worth putting through to the technical test.

The practical screen

A take-home task is the most reliable signal. The scope matters: it should be completable in two to three hours for a mid-level engineer and should not require them to build a production-grade system.

A good task: build a small HTTP API with three endpoints. One should retrieve a list of items from a mock database (a local JSON file or an in-memory store works). One should accept a new item with basic validation. One should simulate a dependency that sometimes fails and handle that failure without crashing the process. Require TypeScript. Ask for at least one test.

What you are grading:

Do they handle async errors properly? An unhandled rejection that crashes the server in production is a day-one issue.
Is the code typed or is it effectively untyped TypeScript?
Do they send appropriate HTTP status codes (not 200 for a validation error)?
Is there any graceful shutdown handling?
Do the tests actually test behavior, or do they test that a function was called?

You will see immediately who understands what production-grade means and who does not.

Red flags in Node.js interviews

A few things that reliably predict problems:

Callbacks over promises by preference. Not historical codebases, but greenfield choices. Candidates who actively prefer callback style in 2026 are carrying habits from a much older era and will write code nobody else wants to maintain.

No TypeScript on personal or recent projects. This is not about preference. It is a signal about what the market requires and whether they are keeping up.

Never deployed to any real infrastructure. Heroku shutdown pushed a generation of developers to move. If they have never used Fly.io, Railway, ECS, Render, or Kubernetes for anything, they may not understand what running a Node.js process in production actually looks like.

“I have not needed queues.” Almost every production system that processes more than trivial load eventually needs background jobs. A developer who has never used BullMQ, Inngest, or a similar tool has probably not built systems that run under real conditions.

Green flags worth paying for

Some things indicate a developer who has seen production and learned from it:

They bring up graceful shutdown without prompting. Handling SIGTERM properly, draining in-flight requests, and closing database connections before exit is not something you learn from a tutorial. It is something you learn when a deployment kills active user sessions.

They have used node --inspect or clinic.js to profile memory. Saying “we had a memory leak in production” and having a coherent story about how they found and fixed it is a senior signal.

They know when to leave Node.js entirely. A developer who reaches for worker threads for a CPU-intensive task, or who has stood up a Python service for ML inference alongside a Node.js API, understands that the runtime is a tool, not an identity.

They have opinions on logging. Not just “we use Winston” but a view on structured logging, log levels, and what information belongs in a trace versus a log line. This correlates with having built and debugged things in production.

Connecting the hiring decision to cost

The difference between a mid-level and a senior Node.js hire shows up most clearly in how they handle things that go wrong. Both can build a feature in calm conditions. The senior builds it in a way that makes the next incident easier to diagnose.

The framework for thinking about total hiring cost, including screening time and ramp-up, is in what it costs to hire a developer in 2026. For the mechanics of vetting technical claims before making an offer, the process is in how to hire a vetted software developer.

If you are hiring Node.js alongside DevOps or infrastructure work, the signals to look for on the ops side are in how to hire a DevOps engineer in 2026.

The practical shortcut

If you do not have a senior Node.js engineer in-house who can run a technical screen, the alternative is a structured take-home followed by a review session where the candidate walks through their choices. The review session matters more than the take-home output. Someone who built something imperfect but can clearly articulate why they made each decision, and can identify what they would change, is a much better hire than someone who produced clean code but cannot explain it.

Node.js hiring at the moment rewards specificity. The candidate who says “I work in Fastify with Drizzle and Postgres, mostly on APIs that handle high-frequency reads” is easier to evaluate than one who says “full-stack JavaScript.” Ask for specificity before you run a screen, and save the screen for the candidates who can describe what they have actually built.

Reducing LLM API Costs in Production: Caching, Batching, and Model Routing

Prathviraj Singh — Thu, 18 Jun 2026 00:00:00 GMT

You shipped the AI feature. Usage is growing. Then the API bill arrives.

LLM costs do not scale linearly with users. They scale with tokens, which means a feature that seemed cheap in development gets expensive fast as usage grows, especially if the system prompt is long, users send verbose inputs, or the model is returning longer completions than you expected.

The good news is that most production LLM systems have significant optimization headroom. The techniques below are not speculative. They are available today on every major provider and can reduce bills by 40-80% without changing what the user sees.

The bad news is that you need to measure before you can optimize. If you do not know which features drive cost and what the token breakdown looks like, start there.

Instrument first

Before any optimization, add logging to every LLM call:

interface LLMCallLog {
  feature: string;         // which product surface triggered this
  model: string;
  promptTokens: number;
  completionTokens: number;
  costUSD: number;         // compute from the pricing table at call time
  latencyMs: number;
  cacheHit: boolean;       // fill in once you add caching
  requestId: string;       // for correlation with provider logs
}

Aggregate by feature over 7-day windows. You will usually find that one or two features drive 60-80% of the cost. Those are where you start.

Prompt caching: the highest-leverage change

Prompt caching stores the transformer’s computed key-value pairs for a given input prefix. On subsequent requests that share that prefix, the model reads from cache rather than recomputing, which is faster and costs a fraction of normal input token pricing.

All three major providers support it:

Provider	Cache read cost	Cache write cost	TTL
Anthropic	10% of input token price	25% of input token price	5 minutes (refreshes on hit)
OpenAI	50% of input token price	Full price (first request)	5-10 minutes
Google Gemini	~25% of input token price	Full price	1 hour minimum

The catch: the cached prefix must be static. System prompts, retrieved documents, conversation history, and other fixed context can be cached. The dynamic user message cannot. Most well-structured prompts have a large system prompt and a small user turn, which means caching dramatically reduces the per-request input cost.

On Anthropic, you mark cacheable prefixes explicitly with a cache_control header:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": LONG_SYSTEM_PROMPT,  # could be thousands of tokens
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": user_message}
    ]
)

# Check the usage to confirm cache behavior
print(response.usage.cache_read_input_tokens)    # tokens served from cache
print(response.usage.cache_creation_input_tokens) # tokens written to cache

On a system prompt of 2,000 tokens with 100 daily users each sending 10 messages, moving from no caching to cached system prompt reduces input token cost by roughly 90%. At claude-sonnet-4-6 pricing, that is a meaningful number by month’s end.

Semantic caching for repeated questions

Prompt caching handles identical prefixes. Semantic caching handles near-duplicate user inputs.

Users ask the same question in different words constantly, especially in support, Q&A, and document retrieval features. “What is your return policy?” and “How do returns work?” are different strings that should return the same response. Without semantic caching, both hit the API and pay full price.

Semantic caching works like this: embed the incoming user query, compare it against a vector index of cached (query, response) pairs, return the cached response if similarity exceeds a threshold (typically 0.92-0.95 cosine similarity), and cache the new pair if it misses.

A minimal implementation with Redis and pgvector:

import psycopg2
import numpy as np
from openai import OpenAI

client = OpenAI()
conn = psycopg2.connect(DATABASE_URL)

SIMILARITY_THRESHOLD = 0.93

def embed(text: str) -> list[float]:
    return client.embeddings.create(
        input=text,
        model="text-embedding-3-small"
    ).data[0].embedding

def semantic_cache_get(query: str) -> str | None:
    embedding = embed(query)
    cur = conn.cursor()
    cur.execute("""
        SELECT response, 1 - (embedding <=> %s::vector) AS similarity
        FROM llm_cache
        ORDER BY similarity DESC
        LIMIT 1
    """, (embedding,))
    row = cur.fetchone()
    if row and row[1] >= SIMILARITY_THRESHOLD:
        return row[0]
    return None

def semantic_cache_set(query: str, response: str):
    embedding = embed(query)
    cur = conn.cursor()
    cur.execute("""
        INSERT INTO llm_cache (query, response, embedding)
        VALUES (%s, %s, %s::vector)
        ON CONFLICT DO NOTHING
    """, (query, response, embedding))
    conn.commit()

Cache hit rates after the first week of operation are typically 30-60% for customer-facing features. The embedding call itself costs a small amount, but text-embedding-3-small at $0.02 per million tokens is trivially cheap compared to a full generation call.

One caution: staleness. A cached response that is weeks old may be wrong if the product changed. Include a TTL and an invalidation mechanism for content that changes.

Model routing: right model for the task

Not every request needs your most capable model. A classification task, a short factual lookup, or a simple reformatting job does not need GPT-4 or Claude Opus. It needs something that is correct and fast.

Model routing classifies incoming requests and sends them to the cheapest model that can handle them:

from enum import Enum

class RequestComplexity(Enum):
    SIMPLE = "simple"     # factual lookup, classification, formatting
    MEDIUM = "medium"     # summarization, basic Q&A, code completion
    COMPLEX = "complex"   # reasoning, long-form writing, code generation

MODEL_BY_COMPLEXITY = {
    RequestComplexity.SIMPLE: "claude-haiku-4-5-20251001",
    RequestComplexity.MEDIUM: "claude-sonnet-4-6",
    RequestComplexity.COMPLEX: "claude-sonnet-4-6",  # or claude-opus-4-8 for highest stakes
}

def classify_complexity(user_message: str, context: dict) -> RequestComplexity:
    # Rule-based is often good enough to start
    if len(user_message) < 100 and context.get("task_type") in ("classify", "format", "extract"):
        return RequestComplexity.SIMPLE
    if context.get("requires_reasoning") or len(user_message) > 1000:
        return RequestComplexity.COMPLEX
    return RequestComplexity.MEDIUM

def route_request(user_message: str, context: dict) -> str:
    complexity = classify_complexity(user_message, context)
    return MODEL_BY_COMPLEXITY[complexity]

The cost differences are large. Haiku 4.5 is roughly 20-30x cheaper than Opus 4.8 per token. Even moving 40% of requests from Sonnet to Haiku reduces the blended cost by 20-30%.

The risk is misrouting: sending a complex task to a cheap model and getting a wrong or low-quality response. The mitigation is to start conservative (route only very clearly simple tasks to the cheap model), track quality metrics per model tier, and expand routing as you gain confidence in the classifier.

Existing tools like OpenRouter and LiteLLM have routing built in and support fallbacks when a model is unavailable.

Batch inference for offline workloads

Any task that does not need a real-time response is a candidate for batch inference. The savings are significant and the implementation is simple.

Anthropic’s Batch API and OpenAI’s Batch API both offer 50% cost reduction on batch requests, processed within 24 hours. Google Vertex has similar offerings.

import anthropic

client = anthropic.Anthropic()

# Create a batch for document summarization
batch = client.messages.batches.create(
    requests=[
        {
            "custom_id": f"doc-{i}",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 500,
                "messages": [
                    {"role": "user", "content": f"Summarize this document:\n\n{doc}"}
                ]
            }
        }
        for i, doc in enumerate(documents)
    ]
)

print(f"Batch ID: {batch.id}")
# Poll for completion or use a webhook

Use cases that map well to batch inference: content classification at scale, document summarization pipelines, bulk data extraction, generating product descriptions, batch translation, and any nightly data processing job.

Tasks that do not fit: anything user-facing that needs a response within seconds.

Output token reduction: where the money hides

Input tokens are cheaper than output tokens on every major provider. Long, verbose completions cost more than short, direct ones, and they are slower.

The practical lever is explicit instructions in the system prompt:

Be concise. Use bullet points instead of prose for lists. Do not restate the user's question.
Limit responses to 300 words unless the task genuinely requires more.

On customer-facing features, reducing average completion length from 400 tokens to 150 tokens cuts output cost by 62%. Check your analytics: if the median user reads 150 tokens of a 400-token response, the extra 250 tokens are cost with no value.

For structured data extraction, use JSON output modes (supported on all major providers) rather than asking the model to explain its reasoning first. Structured output produces shorter completions and is easier to parse downstream.

Putting it together

The order of operations matters. Each of these techniques takes time to implement correctly. A reasonable sequencing:

Instrument (one sprint): log model, tokens, cost, latency for every call. No optimization yet.
Identify the hot paths (one week of data): which features drive 80% of cost?
Add prompt caching (one sprint): highest leverage, lowest risk, lowest complexity.
Add model routing for clearly simple tasks (one sprint): conservative routing on well-understood request types.
Add semantic caching for high-volume Q&A features (one to two sprints): more complex, higher reward for the right use cases.
Move eligible offline work to batch (one sprint): straightforward if the feature is already async.
Tune output length (ongoing): iterative, based on real usage data.

Most teams that go through this sequence find that steps 3 and 4 alone cut their bill by 40-60%. Steps 5 and 6 can take it further.

The budget lines that tend to catch teams off guard during AI feature development are covered in what an AI feature actually costs. For observability tooling that makes cost tracking less painful, LLM observability tools covers the options. If you are building AI features for clients and need to explain these cost structures in project scoping, the context is useful for how we structure AI integration projects.

One thing to track that most teams do not

Track cost per unit of user value, not just cost per call.

A feature where each LLM call generates a report that saves a user 30 minutes has a very different economics profile than a feature where each call produces a one-line summary the user ignores. The second feature looks cheap per call but has no return. The first looks expensive but is worth every token.

The optimization work makes more sense, and is easier to prioritize internally, when it is connected to the value the feature delivers. A 50% cost reduction on a feature that should not exist is not an accomplishment.

Statement of Work vs. Time and Materials: Getting the Contract Right Before Work Starts

Anurag Verma — Thu, 18 Jun 2026 00:00:00 GMT

Most disputes between software agencies and their clients come down to a mismatch between what was contracted and what was expected. The technical work is often fine. The relationship breaks over scope creep, payment timing, or a disagreement about what “done” means.

The contract structure is not the cause of those disputes, but it determines how they play out. A well-matched contract type absorbs the normal friction of a software project. A mismatched one amplifies it.

The two main models

Statement of Work (SoW) defines a specific deliverable, a timeline, and a price. The agency agrees to build a described thing by a described date for a described fee. If the client asks for something outside that definition, it requires a formal change order. The risk of underestimating sits with the agency. The risk of having no flexibility sits with the client.

Time and Materials (T&M) bills actual hours worked at an agreed rate. The client pays for the work, not the outcome. Risk of scope expansion sits with the client. Risk of the agency underdelivering for the hours billed sits with the client too, which is why T&M works best when the client has enough technical oversight to know whether the hours are productive.

Both models are complete contracts. Neither is a workaround or a compromise. The choice is about which party should hold which risks given what the project actually looks like.

When SoW is the right call

A fixed-price SoW makes sense when:

Requirements are genuinely stable. The client has a specification, the agency can scope against it, and both parties can agree on acceptance criteria before work starts. This is rarer than it sounds. Most clients think they have stable requirements until the first prototype arrives.

The client cannot carry budget uncertainty. A startup raising its first round, a small business owner, or a non-profit with a fixed grant budget may need to know the total cost upfront to proceed at all. SoW is often the only viable commercial structure in these cases.

The project is a known type. A standard e-commerce build, a marketing site with a defined page count, a mobile app with a clear feature list, an API integration between two documented systems. These are projects where an experienced agency can scope accurately enough that a fixed fee is not a gamble.

The agency has done it before. Fixed-price contracts carry estimation risk. The mitigation is depth of experience with that project type. An agency that has built 50 similar projects can absorb that risk because the unknowns are bounded by prior experience. An agency building in an unfamiliar domain is taking on risk that will cost someone.

When T&M is the right call

Time and Materials is the right structure when:

Requirements will evolve. Products that are being discovered during development, integrations with undocumented legacy systems, or projects where the client needs to see a working version before finalizing the next phase. In these cases, a fixed SoW is a fiction, because neither party knows what to fix it to.

The engagement is ongoing. Retainer relationships, maintenance contracts, and long-term product partnerships are naturally T&M. The value of the relationship is in continuous access to a team that knows the product deeply. Trying to repackage that as a series of SoWs adds administrative overhead without adding clarity.

The client wants to control scope dynamically. Some clients, usually ones with technical leadership, prefer to adjust priorities sprint by sprint. They want to be able to say “skip that feature, do this instead” without filing change orders. T&M lets them do that.

Discovery is required. If you are auditing an existing system, scoping a large project, or doing technical research before committing to a build, T&M is the right structure for that phase. You cannot write a fixed-price contract for work whose output you cannot define yet.

The failure mode: wrong model for the project type

The most common problem is a fixed-price SoW on a project that was never actually well-defined.

It goes like this: the client wants budget certainty, the agency wants to close the deal, and neither party pushes hard enough on “do we actually know what we are building?” The SoW is signed with some ambiguity baked in. Development starts. Scope questions arise. The agency issues a change order. The client is surprised (“we thought that was included”). Tension builds. By the third change order, the relationship is damaged.

This is not a bad-faith problem. Both parties wanted the project to work. The structure was just wrong for the actual project.

The solution is a short discovery phase before any fixed-price contract. Two to four weeks of requirements work, prototyping, and specification writing, billed on T&M. At the end of discovery, both parties know enough to sign a meaningful SoW or to agree that T&M is the right structure for the build phase. The discovery investment pays for itself in avoided disputes.

The hybrid: capped T&M

For most mid-sized projects, neither pure model is ideal. The client wants budget certainty but the scope is not fully defined. The agency wants flexibility but also needs the project to be financeable.

A capped T&M contract addresses both. The work is billed at an hourly rate (T&M), but the total is capped at a maximum figure. The client cannot be surprised with a bill beyond the cap. The agency has flexibility to handle scope evolution within the cap.

The cap is not a free unlimited guarantee. The contract should specify:

What happens when the project is tracking toward the cap (the agency flags it, the parties decide whether to extend, reduce scope, or close out)
What is excluded from the cap (client-caused delays, third-party integration issues, requirements changes)
What happens if the project finishes under the cap (the client does not pay the remainder, or they apply it to a next phase)

The capped T&M model works well when the agency commits to honest forecasting. A project that is 80% through the budget at 40% through the scope is not a surprise at the end. It is a conversation in week four. The contract does not help if the agency does not raise the flag.

Acceptance criteria: the part that makes the contract real

Whatever structure you use, the acceptance criteria are what make the contract enforceable.

A SoW that says “build a mobile app” is not a contract in any meaningful sense. A SoW that says “build iOS and Android applications with the features listed in Appendix A, accepted when the client signs off on a test build that passes the checklist in Appendix B” is a contract.

Acceptance criteria should describe:

What the deliverable does (feature list, user flows, API behaviors)
What environment it is tested in (staging, production-equivalent, real devices)
Who signs off and how (a named role, a written approval)
What happens if feedback arrives after sign-off (change order, or included if it is a bug vs. a new requirement)

Time and Materials contracts need acceptance criteria too. Without them, you cannot tell the client that a phase is complete and billing has moved to the next phase.

Payment structure by contract type

SoW (fixed-price): Milestone payments are standard. A typical structure: 30-50% upfront, 30-40% at a defined midpoint (delivery of a working build, completion of a phase), and the remainder on final acceptance. Never 100% at the end. The agency carries execution risk; the client carries payment risk. Milestone payments balance them.

T&M: Weekly or monthly invoicing against hours logged. Most clients accept 30-day payment terms. Government or enterprise clients may take 45-60 days. Factor this into your cash flow before signing a large T&M engagement.

Capped T&M: Either milestone or periodic billing works, but periodic billing (monthly) is more common because the scope is fluid. The cap means the client is never surprised; the billing frequency means the agency is not carrying the cost for extended periods.

The contracts that make the rest of this work

None of this matters without supporting agreements. Before any work starts, you also need:

A master services agreement (MSA) that covers IP ownership, confidentiality, liability limits, and how disputes are handled. The SoW or T&M addendum lives under it.

An IP assignment clause that is specific about what the client owns (typically the deliverables) and what the agency retains (their tooling, frameworks, methodologies).

A termination clause that specifies what happens if either party walks away. For T&M, this is usually “pay for hours worked.” For SoW, it requires more care around partial completion.

The operational side of client relationships, including how payment terms, SLAs, and retainers work in practice, is covered in detail across agency payment terms and SLA and support contracts. For the proposal stage that happens before any contract is signed, writing a technical proposal covers the process of moving from a client conversation to a written scope.

The one rule that covers most cases

If the client cannot tell you, before work starts, what done looks like and what they will check before they accept it, do not sign a fixed-price SoW. Use T&M or discovery first.

The SoW is a useful structure. It gives the client budget certainty and the agency a clear target. But it only works when both parties can agree on what they are committing to. When they cannot, the paperwork is a formality that delays the inevitable dispute rather than preventing it.

How to Hire a DevOps Engineer in 2026: Kubernetes, IaC, and the Roles That Replaced DevOps

Prathviraj Singh — Wed, 17 Jun 2026 00:00:00 GMT

When a startup says they need a “DevOps engineer,” they usually mean the person who will set up their CI/CD pipeline, manage Kubernetes, write Terraform, handle cloud costs, and be on call when the site goes down. That is four different jobs, and the market has mostly sorted out that they are not the same job.

Before you post a DevOps role, decide which of these you actually need.

The three jobs hiding inside “DevOps”

Platform engineer. Builds and maintains the internal developer platform: Kubernetes clusters, service templates, CI/CD abstractions, developer tooling, deployment frameworks. The customer is other engineers, and the goal is making them faster and more self-sufficient. This role cares deeply about developer experience. If your engineers spend significant time fighting infrastructure or wait 20 minutes for CI to finish, a platform engineer is what you need.

Site reliability engineer (SRE). Owns availability, latency, and production reliability. Writes runbooks. Manages SLOs and error budgets. Conducts postmortems. On call in a structured way. Tends to have more software engineering background than classic ops. The SRE model, as defined by Google’s original book, treats reliability as a software problem. If your team ships features but nobody owns reliability, this is the gap.

CI/CD and toolchain specialist. Builds and maintains the pipeline: GitHub Actions, ArgoCD, GitLab CI, build caching, artifact management, deployment automation. Overlaps heavily with platform engineering but can be narrower. This is often the first DevOps hire at an early startup.

Most “DevOps engineer” job descriptions mix all three. The best hire for an early-stage team is someone who can do all three at a junior or mid level. At a 50+ engineer company, you need specialists, and posting a generalist role will attract the wrong candidates.

What the stack looks like in 2026

Any serious DevOps hire in 2026 needs to be fluent in:

Containers and Kubernetes. Docker is assumed. Kubernetes is now the default for everything above “small app deployed on a single server.” The real question is not “do you know Kubernetes?” but “have you operated it in production under load?”

Infrastructure as Code. Terraform or OpenTofu is the most common choice. AWS CDK is strong for AWS-only teams. Pulumi is used in teams that want TypeScript or Python over HCL. The tool matters less than whether they write IaC like software: modules, state management, code reviews, testing with Terratest or Checkov.

CI/CD. GitHub Actions is dominant. GitLab CI is common in enterprise. ArgoCD or Flux for GitOps deployment to Kubernetes. The candidate should have opinions about when GitOps patterns help and when they add complexity that small teams don’t need.

Observability. OpenTelemetry for instrumentation, Prometheus and Grafana for metrics, a centralized logging stack (ELK, Loki, or a managed service like Datadog or Axiom). The ability to debug a production incident using traces and metrics is the actual skill, not just knowing how to run the tools.

Cloud. AWS is the most common; GCP and Azure have their niches. Multi-cloud experience sounds good on a resume but often means surface-level exposure to each rather than deep expertise in any. For most teams, deep expertise in one cloud is more useful.

What is becoming more important:

FinOps awareness. Cloud bills have become a material cost at any company running serious workloads. Engineers who understand how to read a cloud bill and what drives costs (egress, data transfer, oversized instances, unused resources) are increasingly valuable.

Supply chain security. SBOM generation, container image scanning (Trivy, Snyk), signing images with Cosign, SLSA compliance. Regulation and customer expectations are pushing this into standard practice.

How to screen a DevOps candidate

The portfolio signal for DevOps is harder to evaluate than software engineering. They may not have public GitHub repos. Look for:

Documented postmortems or incident reports (many engineers keep anonymized ones)
Conference talks or blog posts about infrastructure work
Contributions to open-source infrastructure projects or Helm charts
Demonstrated certification (AWS Solutions Architect Professional, CKA, CKAD) as a minimum bar signal, not a hiring criterion

For the technical screen, use a scenario, not an algorithm:

“We have a Node.js service running in Kubernetes that is serving elevated p99 latency (around 2 seconds) during business hours. CPU usage is normal. Memory is stable. The service has 3 replicas. Walk me through how you would investigate this.”

A good answer covers: checking pod-level metrics vs node-level metrics, looking at request traces if available, checking for garbage collection pauses in Node.js (heap dumps, GC logs), looking at whether the p99 is caused by a specific endpoint or all of them, checking if the latency correlates with horizontal scaling behavior, and asking about external dependencies (databases, downstream APIs).

A weak answer goes straight to “I would increase the number of replicas” without diagnosing why the latency is elevated.

The infrastructure review. Share a Terraform configuration (can be from a public repo) and ask them to review it. You are looking for:

Security issues (overly permissive IAM roles, public S3 buckets, hardcoded secrets)
Missing best practices (no remote state, no locking, no variable validation)
Whether they structure feedback clearly or just list problems

The “make developers faster” question. “What is the biggest thing you have done that made other developers more productive?” A platform engineer orientation shows up here. Look for: they reduced CI time, they built a self-service deployment tool, they moved a manual process to automation, they wrote a runbook that eliminated a class of support requests. Operations-only engineers answer this with things like “I set up monitoring.” Platform engineers answer with outcomes for other people.

What to pay

Level	India (annual)	US (annual)	Contract rate
Mid (3-5 yrs)	$30k-$55k	$130k-$170k	$65-$100/hr
Senior (5-8 yrs)	$55k-$80k	$170k-$220k	$100-$150/hr
Staff / Principal	$80k+	$220k-$300k	$150+/hr
Platform engineer (senior)	$60k-$90k	$180k-$250k	$110-$160/hr

Senior DevOps engineers with Kubernetes operator development experience, multi-cloud architecture, or SRE background with strong software skills command a premium over these ranges. Expect to compete aggressively for that tier in any market.

A note on scope: if you are hiring one person to do everything (cloud, CI/CD, Kubernetes, on call, FinOps), you are asking for a senior or staff engineer. Do not post that role at mid-level rates and wonder why you get mid-level candidates.

This post is part of the hiring series. For adjacent roles: How to hire a React developer, How to hire a Python developer, How to hire an iOS developer, and the overview of what developers cost across geographies and experience levels.

How to Hire an iOS Developer in 2026: SwiftUI, Concurrency, and What to Screen For

Anurag Verma — Wed, 17 Jun 2026 00:00:00 GMT

iOS development has shifted faster in the last few years than most hiring managers realize. A candidate pool that looks experienced on paper can contain developers running three years behind the current stack, and unlike web development where the migration paths are gradual, iOS has had a set of genuine break points: Swift Concurrency in 2021, SwiftUI reaching production-readiness around 2022-2023, and the toolchain now requiring Apple Silicon Macs. If your job description still asks for “Objective-C experience preferred,” you are screening for the wrong things.

Here is what to look for, how to screen, and what you will pay.

The current iOS stack

SwiftUI is now the primary way to build new iOS UI. It has been maturing since 2019, but it reached the point where teams could build full production apps in it without constantly hitting missing APIs around 2022. In 2026, a developer who can’t write SwiftUI is behind.

That said, UIKit is not dead. Every team with a pre-2023 codebase has UIKit code, and even new apps hit UIKit through third-party libraries, custom components that SwiftUI still can’t express cleanly, and interop requirements. Strong candidates know both and understand when to reach for which.

Swift Concurrency (async/await, structured concurrency, actors) replaced the old patterns — Grand Central Dispatch, Completion handlers, Combine — as the idiomatic way to handle asynchronous work. Swift 5.5 shipped this in 2021, and by 2023 it was standard in most teams. A candidate who still structures their async code around DispatchQueue.main.async everywhere hasn’t updated their mental model.

SwiftData (2023) is Apple’s modern replacement for Core Data. Not every app needs it, but it is worth knowing, especially if you are building an app with local-first or offline requirements.

The development machine requirement: Xcode now requires Apple Silicon (M-series Mac). Any candidate working on an Intel Mac is working with a degraded toolchain and a significantly slower build cycle. Ask.

What separates good iOS candidates from great ones

The basics any candidate should have:

SwiftUI for new UI, UIKit fluency for existing components
Swift Concurrency for async work (not just “I know async/await” but structured concurrency with task groups, cancellation, actors for state isolation)
Xcode Instruments for profiling: memory leaks, CPU hangs, energy impact
App Store submission, TestFlight, entitlements, and the review process
Dependency management via Swift Package Manager

Depth signals that distinguish strong seniors:

Opinion on architecture patterns (MVVM, TCA, VIPER) and when the complexity is worth it
Experience with push notifications end-to-end (APNs token management, silent vs user-facing, background modes)
WidgetKit or App Clips, which require understanding the iOS extension model
Accessibility — VoiceOver, Dynamic Type, color contrast in SwiftUI — most developers haven’t done this seriously
Localization beyond just wrapping strings in NSLocalizedString

Red flags in portfolios and interviews:

Using DispatchQueue.main.async as the answer to every threading question in 2026
“Expertise” in Objective-C listed prominently as a main skill (fine as a note, worrying as a headline)
Portfolio apps that only show simulators, never real device screenshots or TestFlight links
No mention of testing (XCTest, Swift Testing framework) in any project
Combine as their concurrency answer without mentioning Swift Concurrency at all

The screening process

Step 1: Portfolio and GitHub review. Before any interview, look at their apps on the App Store and their public repos. An iOS developer without a shipped App Store app or an open-source SwiftUI project is a larger risk. It does not disqualify them, but you need something to evaluate.

Step 2: Short take-home (3-5 hours max). The format that works:

Build a simple app that fetches a list from the GitHub repos API (or any public API), displays it in a list, and lets the user tap an item to see a detail view. Use SwiftUI and Swift Concurrency. Include one test.

What you are evaluating:

Architecture choice and whether it was appropriate for the scope
Proper use of async/await and @MainActor (or equivalent actor isolation)
Error handling — does the UI show something meaningful when the network fails?
Whether they wrote a real test or a token one
Code organization and naming

Step 3: Walkthrough call (45-60 min). Not a quiz session. Ask them to walk you through their take-home code. Focus on:

“Why did you structure it this way?”
“What would you do differently if this needed to support 100k users offline?”
“Where do you think this code is weakest?”

The walkthrough reveals communication quality and self-awareness better than any trivia question.

What to avoid: Live algorithmic coding interviews (LeetCode-style) have poor signal for iOS roles. iOS development is UI-heavy and architecture-heavy; sorting algorithms under pressure tells you little about whether someone can ship a well-structured iOS app.

What to pay

Rates vary significantly by location and experience level.

Level	India (annual)	US (annual)	Contract (USD/hr)
Junior (0-2 yrs)	$12k-$25k	$80k-$110k	$25-$45
Mid (3-5 yrs)	$25k-$50k	$110k-$160k	$50-$85
Senior (6+ yrs)	$50k-$90k	$160k-$220k	$90-$140
Staff / Tech Lead	$90k+	$200k-$280k	$140+

These are 2026 market rates for full-time employment. Contract rates run higher to account for the lack of benefits. For agencies and startups hiring in India or Eastern Europe, the best candidates are typically out-competing domestic salaries and have good English, which means you should expect to pay toward the top of the India range for someone you can actually work with asynchronously.

visionOS and spatial computing experience commands a significant premium (20-40% above senior rates). If you need it, budget accordingly — the talent pool is small.

The question to ask in every iOS interview

“Walk me through what happens from the moment a user taps your app icon to the moment your first screen is interactive.”

A junior developer gives a vague answer about app launch. A mid-level developer mentions UIApplicationDelegate or the @main entry point and maybe AppDelegate lifecycle methods. A senior developer talks about app initialization, scene lifecycle in multi-scene apps, the cost of loading the storyboard (or not) vs programmatic setup, what they move off the main thread, and how they instrument that launch time in Xcode Instruments.

The question has no wrong answer format. It just scales clearly with actual depth of experience.

For the other roles in this hiring cluster: How to hire a React developer, How to hire a Python developer, How to hire an Android developer, and what it actually costs across skill levels and geographies.

Svelte 5 Runes in Production: How the New Reactivity Model Changes the Way You Write Components

Abhishek Gupta — Wed, 17 Jun 2026 00:00:00 GMT

When Svelte 5 shipped in October 2024, the most polarizing change was runes. The old Svelte model — every let variable in a component is implicitly reactive, $: marks a reactive statement — was one of the reasons people liked Svelte in the first place. It felt like magic. You wrote normal JavaScript and the framework made it reactive.

The magic also had a cost. The implicit tracking meant the compiler had to make decisions about reactivity that were sometimes surprising. Debugging “why did this rerender” or “why didn’t this update” often meant reading the compiled output or consulting the documentation on which patterns Svelte did and did not track. The mental model was simple until it wasn’t.

Runes trade some of that simplicity for predictability. After using them in production for a year, the tradeoff is worth it.

The runes, one by one

$state

In Svelte 4:

<script>
  let count = 0;

  function increment() {
    count++;
  }
</script>

In Svelte 5 with runes:

<script>
  let count = $state(0);

  function increment() {
    count++;
  }
</script>

The change looks minor. The difference matters when you extract logic into a function or a module, where Svelte 4’s implicit tracking broke down. $state creates a reactive binding that works outside the component compiler context too.

For objects and arrays, $state creates a deeply reactive proxy:

<script>
  let user = $state({ name: 'Alice', age: 30 });

  function birthday() {
    user.age++;  // this triggers an update; no need for user = { ...user, age: user.age + 1 }
  }
</script>

This is a real improvement over Svelte 4, where mutating nested properties required reassigning the whole object or using a special array method pattern.

$derived

$derived replaces the $: reactive declaration for computed values:

<script>
  // Svelte 4
  $: doubled = count * 2;

  // Svelte 5
  let doubled = $derived(count * 2);
</script>

More useful with $derived.by for multi-line derivations:

<script>
  let items = $state([1, 2, 3, 4, 5]);

  let stats = $derived.by(() => {
    const sum = items.reduce((a, b) => a + b, 0);
    return {
      sum,
      average: sum / items.length,
      max: Math.max(...items),
    };
  });
</script>

<p>Sum: {stats.sum}, Average: {stats.average.toFixed(1)}</p>

The key rule: $derived is for pure computations. No side effects inside $derived. If you catch yourself writing $derived and then calling a fetch inside it, stop — that belongs in $effect.

$effect

$effect runs a side effect whenever its reactive dependencies change. The dependencies are inferred, not declared:

<script>
  let query = $state('');

  $effect(() => {
    // Runs whenever `query` changes
    if (query.length > 2) {
      fetchResults(query);
    }
  });
</script>

The cleanup pattern works the same way as React’s useEffect return:

<script>
  let width = $state(window.innerWidth);

  $effect(() => {
    const handler = () => { width = window.innerWidth; };
    window.addEventListener('resize', handler);
    return () => window.removeEventListener('resize', handler);
  });
</script>

The most common mistake in Svelte 5 migrations: replacing $: statements that have side effects with $derived instead of $effect. $derived is for values, $effect is for side effects. Blurring this causes hard-to-debug update loops or effects that do not run when expected.

$props

Props are now explicitly declared with $props:

<script>
  // Svelte 4
  export let name;
  export let age = 25;

  // Svelte 5
  let { name, age = 25 } = $props();
</script>

This might look like a step backward — export let was clean. The advantage is that $props() returns a regular destructured object, and you can use TypeScript more naturally:

<script lang="ts">
  interface Props {
    name: string;
    age?: number;
    onUpdate: (name: string) => void;
  }

  let { name, age = 25, onUpdate }: Props = $props();
</script>

For two-way binding scenarios, $bindable:

<script>
  let { value = $bindable() } = $props();
</script>

$inspect

Debugging reactive state used to mean littering console.log in reactive statements. $inspect is a development-mode-only rune that logs whenever a value changes:

<script>
  let count = $state(0);
  $inspect(count);  // logs to console on every change, dev mode only
</script>

Stripped from production builds automatically. Small thing, genuinely useful.

Extracting logic into stores and utilities

One of the practical gains from runes is that reactive logic can live outside the .svelte file. In Svelte 4, you needed writable stores and the $ prefix to make this work. In Svelte 5, you can write plain TypeScript:

// counter.svelte.ts — note the .svelte.ts extension; runes work in these files
export function createCounter(initial = 0) {
  let count = $state(initial);

  return {
    get value() { return count; },
    increment() { count++; },
    decrement() { count--; },
    reset() { count = initial; },
  };
}

<script>
  import { createCounter } from './counter.svelte.ts';
  const counter = createCounter(10);
</script>

<button onclick={counter.increment}>{counter.value}</button>

The .svelte.ts extension tells the Svelte compiler to allow runes in a TypeScript file. This pattern makes logic testable outside the component and reusable across multiple components without the ceremony of a full Svelte store.

The migration from Svelte 4

The svelte-migrate CLI handles most of the mechanical changes:

npx sv migrate svelte-5

What it handles automatically:

Converting export let to $props() destructuring
Converting let x = ... assignments to $state(x)
Converting most $: statements to $derived or $effect

What needs manual review:

$: statements that have both a computed value and side effects mixed together
Complex reactive chains where the ordering of $: statements mattered
Component lifecycle events (the Svelte 4 onMount, onDestroy, beforeUpdate, afterUpdate all still work, but you may want to convert to $effect)
Custom stores that relied on the Writable<T> pattern from svelte/store

For most well-organized Svelte 4 components, the migration is an afternoon of work per hundred components. For components that leaned heavily on complex reactive statement chains, expect to rewrite some logic.

What changed in practice

After running Svelte 5 runes in production on a mid-size SvelteKit app (about 140 components) for the better part of a year, the honest summary:

Better: TypeScript integration improved substantially. Reactive logic extracted into .svelte.ts utilities is testable with Vitest without mounting a component. The explicit $derived vs $effect distinction has prevented several categories of bugs that were common with $: statements. Debugging rerenders is easier because the reactive dependencies are visible in the code rather than inferred from compiler output.

Worse: More to write. The Svelte 4 feel of “just write JavaScript and it works” is somewhat reduced. New team members who come from React or Vue adapt faster (familiar mental model), but people who came specifically because of Svelte’s minimalism sometimes feel like something was lost.

Neutral: Performance is similar. The compiler still produces efficient JavaScript; the main difference is what you write, not what the browser runs.

The runes model makes Svelte feel more like Vue 3’s Composition API or SolidJS signals. Whether that is a good thing depends on what you liked about Svelte in the first place. If you valued the compiler magic, the runes feel like a step back. If you valued the compilation approach but wanted more explicit reactivity, runes are the right direction.

For new projects, start with Svelte 5 and write runes from day one. For existing projects, the svelte-migrate tool makes the path manageable, and the compatibility mode means you can migrate incrementally rather than all at once.

The broader SvelteKit ecosystem has continued to move fast in 2026, and remote functions (introduced in 5.49) are worth reading about separately — they represent a different kind of change to how you structure data fetching in a SvelteKit app.

The Technical Interview Process That Actually Predicts Job Performance

Anurag Verma — Wed, 17 Jun 2026 00:00:00 GMT

Most companies hire developers the same way: a recruiter screen, a coding challenge, some interviews, maybe a system design question, and a vibe check called “culture fit.” The process feels thorough because it has stages. It is not particularly good at finding the right people.

The problem is almost never dishonesty in the process. It is that the things being measured have a loose relationship to what the job actually requires.

What research says about interview validity

Interview research has been consistent for decades. The factors that most strongly predict job performance:

Work sample tests: having the candidate do tasks representative of the actual job
Structured interviews: consistent questions, consistent scoring criteria, multiple interviewers
Job knowledge tests: assessments of relevant technical knowledge
Peer ratings from past work: references done properly

The factors that have surprisingly low predictive validity:

Unstructured interviews: casual conversations based on whatever the interviewer feels like asking
Graphology, personality tests: low-to-no validity for most professional roles
Years of experience as a primary filter: weakly correlated with performance past about 5 years

Algorithmic coding interviews sit somewhere in the middle. They test a real cognitive skill, but the skill (solving novel graph problems under time pressure) has modest overlap with daily software engineering work. The false negative rate — strong engineers who perform poorly in algorithm interviews because they have not practiced recently — is significant.

This matters because false negatives have a cost you never see. The engineer who failed your coding round and went to your competitor does not appear in your hiring funnel metrics. Your rejection rate looks good. Your team gets worse.

The take-home assignment: how to do it right

Work sample tests are the highest-validity interview format. For software engineers, this means a task representative of what they will actually build.

What works:

A specific, scoped task from your actual problem domain. Not a generic CRUD app, but something that surfaces the kinds of decisions your team makes regularly:

“We need a small service that accepts a list of URLs via a REST endpoint, fetches their content in parallel, and returns a summary of the response codes and content lengths. Add tests. We expect this to take around 3 hours.”

You get to see: their approach to concurrency, error handling decisions, how they structure a small service, their testing patterns, and how they document things.

What to avoid:

Tasks that take longer than 4 hours. Candidates who are currently employed (the ones you most want) have limited time.
Tasks so open-ended that you cannot evaluate them consistently. “Build whatever you think is interesting” produces beautiful portfolios and tells you very little about how someone will fit your specific context.
Tasks that are a thinly veiled request for a working prototype of something you need. If the output has real business value to you, pay for it.

The walkthrough matters more than the code. Schedule a 45-minute call after the take-home where the candidate walks you through what they built. This is where most of the signal is:

Can they explain their decisions clearly?
Do they know the tradeoffs of the approach they chose?
Do they see the weaknesses in their own work?

A developer who writes decent code and explains it articulately is more valuable than a developer who writes excellent code and cannot discuss it. Communication is part of the job.

The structured interview: questions that scale

A structured interview asks every candidate the same questions and scores each answer against a rubric. It sounds bureaucratic. It substantially outperforms the intuition-based alternative.

The question types worth including:

Past behavior questions (best predictor of future behavior):

“Tell me about a production incident you were responsible for diagnosing. Walk me through what happened, how you found the root cause, and what you changed.”
“Describe a technical decision you made that you later regretted. What did you learn?”
“Tell me about a time you pushed back on a technical decision you disagreed with. How did it go?”

The scoring rubric for each: did they take ownership, did they demonstrate actual technical depth in their explanation, did they show they learned something, were they honest about their role vs someone else’s?

Hypothetical technical scenarios (for skills that are hard to infer from past behavior):

“We are seeing elevated p95 latency on a service that we just deployed. Nothing is throwing errors. Walk me through how you would investigate.” (Diagnoses debugging methodology)
“A customer reports their data is missing from a table that you expected to have it. How do you approach this?” (Diagnoses how someone reasons about data consistency)

These are not looking for a specific correct answer. They are looking at the quality of the diagnostic process: do they systematically check hypotheses, do they ask clarifying questions before jumping to conclusions, do they think about rollback or impact while diagnosing?

The one question that works across all roles:

“Walk me through a production problem you debugged. What was it, how did you find it, what did you change?”

This surfaces: real technical depth, ability to narrate a technical story clearly, how they think about root causes vs symptoms, and whether they have worked on systems that actually have production problems. The answer scales exactly with experience. A junior developer will tell you about a bug in their side project. A staff engineer will tell you about a database deadlock that took three days to find and required a schema change.

Where most interview processes go wrong

The culture fit round. Usually the last stage. Usually unstructured. Usually the highest-bias moment in the process. “Culture fit” often encodes “seems like the people we already have,” which is a reliable mechanism for filtering in homogeneity.

Replace it with: a concrete team values conversation. List the 3-4 things that genuinely matter to your team culture (direct feedback, async-first communication, engineers own their services in production). Ask candidates how they handle each in practice. Score it like the other stages.

The “brilliant jerk” trap. Strong technical performance can mask poor collaboration signals in a short interview process. Behavioral questions are specifically good at surfacing this. “Tell me about a time you had a significant disagreement with a colleague about a technical direction. What happened?” is a direct probe. The people who have never had a disagreement they can tell you about are either junior or not being honest.

Asking the same questions as everyone else. If your take-home is the same FizzBuzz variant every other company uses, candidates will have polished answers ready. Novel scenarios — pulled from your actual production codebase or real problems your team has faced — produce much higher-signal conversations.

Skipping reference checks. Reference checks are treated as box-checking in most hiring processes. Done well, they are a work sample of a different kind: talking to people who have seen the candidate work over time. Ask: “Can you describe a project they owned end to end and how it went?” and “If you were hiring for a senior backend role, would you want to work with them again?” The second question is binary and produces very honest answers.

The format in practice

A process that has worked across a range of companies:

Application review + portfolio/GitHub. Not a filter on credentials but on evidence of actual work.
30-minute recruiter screen. Role fit, communication basics, timeline.
Take-home assignment. 3-4 hour scoped task. 48-72 hour window.
Technical walkthrough (45-60 min). The candidate walks through their take-home. Structured questions from the same scoring guide for every candidate.
Structured behavioral interview (45-60 min). Same 4-5 behavioral questions for every candidate, scored against rubric.
Team meet (30 min). Conversational, not evaluative. This is the candidate evaluating you as much as the reverse.
References. Two calls, 20 minutes each. Ask about the work, not the character.

Total candidate time: around 6-7 hours including the take-home. That is realistic for a senior role. For junior roles, skip the take-home in favor of a longer technical walkthrough on a lighter task.

The process takes more preparation than an improvised series of conversations. The payoff is that your decisions are more consistent, more defensible, and more accurate.

For the role-specific screening guides that plug into this framework: React developer technical screen, Python developer screening, iOS developer screening, and DevOps engineer screening.

Background Jobs in 2026: BullMQ, Inngest, or Temporal?

Prathviraj Singh — Tue, 16 Jun 2026 00:00:00 GMT

Every backend eventually needs to run work outside the request-response cycle. Send a confirmation email. Process an uploaded file. Sync data to a third-party system. Retry a failed webhook. The tools that handle this have multiplied enough that picking one is now a real architectural decision.

BullMQ, Inngest, and Temporal are the three I get asked about most. They solve similar problems with very different approaches, and picking the wrong one creates friction you will feel for years. Here is how to choose.

What each tool actually is

BullMQ is a job queue. You push a job onto a queue, workers pick it up and execute it, and the queue tracks success, failure, and retries. It is backed by Redis, which means it is fast and you can inspect queue state directly. You manage the infrastructure (Redis, your worker processes), and you manage the retry and failure logic in your application.

Inngest is an event-driven function runtime. Instead of a queue you manage, you write functions that run in response to events. Inngest handles the scheduling, retry, and observability layer. Your functions are HTTP endpoints; the Inngest platform calls them. There is no queue server to run.

Temporal is a workflow orchestration engine. You write workflows in code (durable, stateful sequences of steps) and Temporal guarantees they will complete correctly even if your servers crash, your dependencies go down, or the workflow takes months. It persists workflow state externally and replays execution history on recovery. It is its own cluster (or a managed service), and it has real operational weight.

When BullMQ fits

BullMQ is the right default for most applications. Use it when:

You are already running Redis (or are willing to add it).
Your jobs are discrete, short-running tasks: sending a notification, generating a PDF, processing a webhook, running a scheduled batch.
Throughput matters: BullMQ handles tens of thousands of jobs per second on a modest Redis instance.
You want simple, inspectable state: Redis data is queryable, job state is visible.

A typical BullMQ setup:

import { Queue, Worker } from "bullmq";
import IORedis from "ioredis";

const connection = new IORedis(process.env.REDIS_URL!);

// Producer — add jobs to the queue
const emailQueue = new Queue("email", { connection });

await emailQueue.add(
  "welcome",
  { userId: "123", to: "user@example.com" },
  {
    attempts: 3,
    backoff: { type: "exponential", delay: 2000 },
  }
);

// Worker — consume and process jobs
const worker = new Worker(
  "email",
  async (job) => {
    await sendEmail(job.data.to, job.data.userId);
  },
  { connection, concurrency: 10 }
);

worker.on("failed", (job, err) => {
  console.error(`Job ${job?.id} failed:`, err.message);
});

The tradeoff: you manage the worker processes and Redis. If your workers crash during a job, BullMQ can retry it (that is what attempts handles), but you have to think about idempotency: if a job runs twice because of a retry, does it do the right thing?

When Inngest fits

Inngest is the right choice when:

You are on a serverless platform (Next.js on Vercel, Remix on Fly, SvelteKit) where managing persistent worker processes is inconvenient.
You want the retry and observability layer managed for you without running a queue server.
Your jobs are event-driven: something happened, trigger a function.
You want step functions — multi-step jobs where each step can be retried independently.

The Inngest model:

import { inngest } from "./client";

export const processSignup = inngest.createFunction(
  { id: "process-signup", retries: 3 },
  { event: "user/signup" },
  async ({ event, step }) => {
    // Each step is retried independently on failure
    await step.run("send-welcome-email", async () => {
      await sendWelcomeEmail(event.data.email);
    });

    await step.sleep("wait-for-activation", "24h");

    await step.run("check-activation", async () => {
      const user = await getUser(event.data.userId);
      if (!user.activated) {
        await sendReminderEmail(event.data.email);
      }
    });
  }
);

What you get: each step is persisted. If check-activation fails, it retries from that step, not from the beginning. The 24h sleep does not consume a running process. Inngest handles the scheduling. You can see every job run, every step, every error in their dashboard.

What you give up: your job handlers must be accessible HTTP endpoints. On a public serverless platform, this is natural. On a private service without a public URL, it requires a tunnel or reverse proxy. You also depend on Inngest’s platform for the coordination layer (they have a self-hosted option, but it adds operational overhead).

When Temporal fits

Temporal is the right choice when your workflow is:

Long-running: hours, days, or longer.
Stateful: you need to remember what happened across multiple steps.
Reliable under arbitrary failures: crashes, restarts, outages should not lose workflow state.
Complex: human approval gates, compensating transactions, parallel fan-out and fan-in.

A Temporal workflow for a document approval process:

import { proxyActivities, defineSignal, setHandler, sleep } from "@temporalio/workflow";

const { sendForReview, applyDocument, notifyRejection } = proxyActivities<
  typeof activities
>({ startToCloseTimeout: "30s" });

export const approvedSignal = defineSignal<[{ approved: boolean }]>("approved");

export async function documentApprovalWorkflow(documentId: string): Promise<void> {
  await sendForReview(documentId);

  let approved: boolean | undefined;
  setHandler(approvedSignal, ({ approved: a }) => {
    approved = a;
  });

  // Wait up to 7 days for approval
  await sleep("7 days");

  if (approved === true) {
    await applyDocument(documentId);
  } else {
    await notifyRejection(documentId);
  }
}

Temporal persists the workflow state as an event log. If your server crashes while waiting for approval, the workflow resumes on restart. The 7 days sleep does not hold a thread; it is stored in Temporal’s state and fires when the time comes.

The cost: Temporal is its own distributed system. You need to run the Temporal server (or use Temporal Cloud, which is managed but adds cost). The development model requires understanding replay semantics — your workflow code runs in a deterministic execution engine with specific restrictions. The learning curve is real.

The comparison in one table

	BullMQ	Inngest	Temporal
Infrastructure	Redis	None (or self-hosted)	Temporal server
Job duration	Seconds to minutes	Seconds to days	Seconds to months
State persistence	Redis	Inngest platform	Temporal history
Steps / multi-stage	No (manual chaining)	Yes (built-in)	Yes (core model)
Serverless-friendly	Moderate	Yes, native	Moderate
Operational burden	Low-medium	Low	High
Best for	High-throughput queues	Serverless multi-step	Long, stateful workflows

The decision

If you are uncertain, start with BullMQ. It is the simplest option with the most predictable operational behavior. Add Inngest if your environment is serverless and you want managed retries and multi-step support. Add Temporal when BullMQ or Inngest cannot express what you need — specifically, when long-running stateful workflows with recovery guarantees are the requirement.

Most applications only ever need BullMQ. A smaller number benefit from Inngest’s model. Temporal is for the workflows where losing state on a crash is genuinely not an option.

The existing posts on Inngest and Temporal go deep on each tool’s patterns. Read those after deciding which direction fits your system.

How to Hire an Android Developer in 2026: What to Screen For

Aman Chaudhary — Tue, 16 Jun 2026 00:00:00 GMT

I have been doing Android development since the days when RecyclerView was the new thing and XML layouts were the only option. The platform looks nothing like that now. Jetpack Compose changed the UI model. Coroutines and Flow changed how we handle async and state. Architecture patterns solidified around a small set of well-tested approaches. The developer who learned Android in 2018 and has not kept up is a different hire than someone who shipped a Compose app last year.

This creates a specific problem for teams hiring Android developers: the job description and the CV do not always reveal which kind of candidate you are looking at. Here is how to tell.

What modern Android looks like in 2026

Any hire for a new project or maintained modern codebase should be comfortable with these:

Kotlin is the primary language. Coroutines and Flow are how you handle async work and reactive state. A candidate who cannot explain the difference between launch, async, and runBlocking in a coroutine context is not current.

Jetpack Compose is now the standard UI framework. It replaced XML-based layouts for most new development. Someone who can only work with Views and XML can maintain old code but will be slow and frustrated on any team moving forward.

Architecture patterns, specifically MVVM or MVI with a clear data layer, are the expected baseline. Candidates should be able to explain how they structure a feature, what belongs in the ViewModel vs the repository vs the data source, and how they manage UI state.

Dependency injection. Hilt (Google’s supported DI library) or Koin. Candidates who manage dependencies manually in a large codebase are working harder than they need to.

Navigation. The Jetpack Navigation component, and increasingly Compose Navigation. How screens communicate, how deep links work, and how back-stack management is handled.

None of this is exotic. It is the current standard. A candidate who has shipped an app in the last two years with a team using modern practices will have all of it. The screen exists to confirm this, not to quiz them.

The technical conversation that reveals the most

The most informative Android screen is not a whiteboard problem. It is asking a candidate to describe, in detail, how they would build a specific feature from scratch.

Pick something representative of your app: a list screen that loads paginated data, a form with validation, a screen that reacts to real-time updates. Ask them to walk through the architecture: where does data come from, how does it move through the layers, how does the UI consume it, what happens when the network fails?

Listen for:

Do they mention a repository layer, or do they call APIs directly from the ViewModel?
How do they represent loading and error states?
Do they mention testing? What would they test and how?
Do they think about configuration changes (rotation, process death)?

Configuration changes are a reliable litmus test. An experienced Android developer has been bitten by them. A candidate who has not thought seriously about what happens to the UI state when the user rotates the device has not shipped a real app to real users.

Lifecycle understanding is the real dividing line

Android’s activity and fragment lifecycle is one of the platform’s most notorious difficulties. Senior developers understand it deeply because they have debugged its failures. Ask:

“Can you describe a lifecycle-related bug you have encountered and how you fixed it?”
“How do you handle work that should survive a screen rotation but not an explicit back press?”
“What is the difference between viewModelScope and lifecycleScope, and when do you use each?”

A candidate who stumbles on these questions either has not shipped production Android or has worked exclusively on simple, non-lifecycle-sensitive screens. Both are worth knowing going in.

Reading the CV

Before the screen, look for these in the CV:

Good signals:

Shipped apps on the Play Store with real user counts (even modest ones).
Compose mentioned prominently, not buried at the bottom.
Coroutines and Flow, not RxJava as the primary async library (RxJava is fine for maintenance, but it is not how new Android is written).
Architecture terms that match current practice: Repository, ViewModel, Clean Architecture, or MVI.
Tests mentioned, ideally with instrumented tests or a Compose UI test framework.

Worth asking about:

Only Java, no Kotlin.
AsyncTask anywhere (deprecated in API 30, removed in 33). Any live codebase still using it is carrying maintenance debt.
No shipped apps, only tutorials or personal projects.
Cross-platform tools only (Flutter or React Native) if the role is native Android.

None of these are automatic disqualifiers, but each warrants a direct conversation about currency and transferability.

Where cross-platform fits

Flutter and Kotlin Multiplatform are real options, not consolation prizes. If you are building a new product that needs iOS and Android parity and your app’s main value is in the business logic and UI, not deep platform integration, Flutter can deliver both platforms faster than two native codebases.

Kotlin Multiplatform is worth considering when you want shared business logic and offline-first data handling but genuinely want native UIs on each platform for feel and accessibility.

Native Android wins when you need precise performance, hardware access (camera, Bluetooth, NFC, sensors), or tight integration with Android system features. It also wins when your users expect a premium, platform-native feel that cross-platform tools do not yet fully deliver.

That decision should happen before the hiring process, because “Android developer” and “Flutter developer” are different roles with different candidate pools.

Where to find strong Android candidates

Android talent is globally available. The constraint is Compose fluency combined with a production delivery record. Freelance marketplaces that pre-screen are faster than a cold job post; the hiring guides in this series cover how to evaluate which option fits your situation.

If your team is technical enough to run a 30-minute screen, a marketplace gives you pre-filtered candidates and you add the final technical judgment. If you want the screening handled, a managed engagement delivers a shortlist with the vetting already done.

A note on AI tooling in Android development

Android Studio’s built-in Gemini integration, Copilot, and Cursor have all made writing boilerplate Compose code faster. This matters for hiring in one direction: the bar for generating working Compose layouts has dropped, and the bar for architecture judgment, performance, and production debugging has risen. Your screen should weight toward the latter. Ask candidates to explain why they made a specific architecture decision, not just write a Compose composable on demand.

The developers worth hiring understand when AI-generated code is correct and when it is subtly wrong. That judgment comes from production experience, not from prompt skill.

If you are building out a mobile team, what it costs to hire a developer is a useful frame for comparing full-time, contractor, and agency options before you commit to a hiring model.

How to Hire a Python Developer in 2026: A Practical Screening Guide

Anurag Verma — Tue, 16 Jun 2026 00:00:00 GMT

Python is the most popular programming language by several measures, which makes “I need a Python developer” one of the least informative hiring requests I hear. The language spans data science, web backends, automation, machine learning, DevOps scripting, and scientific computing. The person who writes your ETL pipelines and the person who builds your Django API are both Python developers. They are not the same hire.

This post is a guide for getting specific: how to define the role accurately, what to screen for, and how to avoid the most common mismatch.

Start with what your Python actually does

Before writing the job description, answer these questions:

Is the Python running in a web server, a data pipeline, a machine learning training job, or a scheduled script?
What frameworks are already in use? (Django, FastAPI, Flask, Celery, Airflow, PySpark?)
Does the role interact with databases, ML models, external APIs, or all three?
How much of the work is greenfield vs maintaining existing code?

The answers determine who you need. A FastAPI-and-Postgres backend role has almost nothing in common with a PySpark data pipeline role, even though both are “Python.”

The four main Python developer types

Backend web developer. Builds APIs and services. Familiar with Django or FastAPI, relational databases, authentication patterns, async programming with asyncio, and deployment. Tests their code. Thinks in HTTP and SQL.

Data engineer. Builds and maintains pipelines that move and transform data. Familiar with Airflow, dbt, Spark, and the data warehouse your company uses. Cares about schema, data quality, and backfill logic. Tests for correctness over time, not just at startup.

ML/AI engineer. Trains, evaluates, and serves machine learning models. Familiar with PyTorch or TensorFlow, model deployment patterns (ONNX, TorchServe, vLLM for LLMs), data preprocessing, and evaluation frameworks. Overlaps with data engineering but the work is different.

Automation and tooling developer. Writes scripts and internal tools. Comfortable with subprocess, CLI frameworks like Typer, file I/O, and integrating with vendor APIs. Often the generalist who knows “enough Python” to connect things.

Most job descriptions collapse all four into one posting. That produces candidates who are strong at one type and weaker at others, then fail to deliver on the work you actually need.

What a strong screen looks like

A useful Python screen takes 30 to 45 minutes and focuses on real problems from your stack, not textbook exercises. Here’s a structure that works:

Ten minutes: the conversation. Ask them to walk through a production system they built or significantly improved. What was the context, what problem did they solve, and what would they do differently now? You learn how they think about tradeoffs, how they communicate technical decisions, and whether they have shipped real things.

Twenty minutes: the task. Give a short, scoped problem from your actual domain. If you have a data pipeline, ask them to write a small transformation function and explain how they would test it. If you have an API, ask them to design a simple endpoint with error handling. The point is not to complete the full task; it is to watch how they approach an ambiguous problem with partial information.

Ten minutes: depth questions. Ask about Python-specific concepts that matter for your stack. If you are using async, ask how they structure async code and what mistakes they have made. If you are using type annotations, ask what tools they use and why they find them useful or annoying. If data correctness is critical, ask how they have handled schema drift in a live system.

What you are looking for is not cleverness. It is clarity of thought, comfort with ambiguity, and evidence that they have shipped similar work before.

Green flags in senior Python candidates

Senior Python skill shows up in specific ways. Look for:

They reach for types (mypy, Pydantic) in production code, not just tutorials.
They can explain the Global Interpreter Lock and when it matters (and when it does not).
They know the difference between threads, multiprocessing, and async, and can reason about which to use.
They have opinions about dependency management (uv, poetry, or pip-tools) and can explain why.
Their test code looks like production code: organized, readable, with test fixtures that make sense.
They have thought about observability: how do you know when a Python service is misbehaving in production?

The last point trips up a lot of candidates. Anyone can write Python that runs locally. Fewer have shipped it to production and been responsible for it at 2 am.

Red flags worth acting on

They cannot name the Python version they have most recently shipped.
Their test strategy is “I ran it and it worked.”
They treat requirements.txt without pinned versions as normal.
They have only used Python in Jupyter notebooks and cannot describe a deployment.
They conflate asyncio with parallelism and believe it makes code faster across all workloads.

None of these are disqualifiers on their own for a junior candidate learning on the job. For a senior role where you are paying for judgment, they are real signals.

Where to find Python talent

Python developers are among the most abundant in the global remote market. The practical constraint is not supply; it is knowing what you want specifically enough to filter.

If you have a technical person who can run a short screen, marketplace options like Toptal alternatives let you source pre-screened candidates and add your own final check. If you want to define the role and hand off the screening, a managed engagement handles the funnel and gives you a shortlist.

The hiring cluster we have built out covers what the total cost really looks like and what a strong technical job description contains, which are worth reading before you post anything.

The job description trap

Most Python job descriptions ask for everything: Django, FastAPI, Flask, Pandas, NumPy, PyTorch, Spark, Airflow, SQL, and three years of “AI/ML experience.” This signals that the team has not decided what the role actually is. Strong candidates read it and move on. Junior candidates who match the keyword list apply.

Write the job description after you have answered the four questions at the top of this post. Then list the three to five frameworks and libraries the person will actually use in the first 90 days. Everything else is a “nice to have” that you train or hire for later.

A note on AI-assisted Python development

Python is one of the most AI-augmented development environments right now. Copilot, Cursor, and similar tools generate competent Python quickly. This is worth knowing in a screen: the bar for syntactically correct code has dropped, and the bar for good design, maintainability, and production judgment has gone up. Screen for the latter. A candidate who can write clean Python fast with AI assistance and explain why each decision makes sense is better than one who can recite library APIs from memory.

The Python developers worth hiring are the ones who know what the tools get wrong, not just what they get right.

OpenFeature in 2026: Feature Flags Without Vendor Lock-in

Abhishek Gupta — Tue, 16 Jun 2026 00:00:00 GMT

Feature flags are one of those practices that teams discover when they get burned. A big-bang release that went wrong, a rollback that took two hours instead of two minutes, a hotfix that required a late-night deploy because there was no way to turn a feature off without one. After the incident, feature flags become standard.

The second discovery happens later: you are tightly coupled to whatever flag service you chose first, and changing it means touching every evaluation call in the codebase. OpenFeature is the solution to that second problem.

What OpenFeature solves

Every feature flag service ships its own SDK with its own API. Switching from LaunchDarkly to Unleash means finding every call to launchDarkly.variation('flag-name', user, false) and rewriting it to unleash.isEnabled('flag-name'). In a large codebase, that is weeks of work and a non-trivial test surface.

OpenFeature defines a single evaluation API that all compliant providers implement. Your application code calls:

import { OpenFeature } from "@openfeature/server-sdk";

const client = OpenFeature.getClient();
const isEnabled = await client.getBooleanValue("new-checkout-flow", false);

Behind that call can be LaunchDarkly, GrowthBook, Unleash, Flagsmith, or your own flat-file flag definitions. Changing the backing provider is a configuration change at startup, not a code change in your features.

Setting up OpenFeature with GrowthBook

GrowthBook is the most commonly self-hosted option and has an official OpenFeature provider. A minimal setup in Node.js:

import { OpenFeature } from "@openfeature/server-sdk";
import { GrowthBookProvider } from "@growthbook/openfeature-node";
import { GrowthBook } from "@growthbook/growthbook";

// Initialize GrowthBook — fetches flags from your self-hosted instance
const growthbook = new GrowthBook({
  apiHost: process.env.GROWTHBOOK_API_HOST!,
  clientKey: process.env.GROWTHBOOK_CLIENT_KEY!,
  enableDevMode: process.env.NODE_ENV !== "production",
});

await growthbook.loadFeatures({ autoRefresh: true });

// Register the provider with OpenFeature — one line
OpenFeature.setProvider(new GrowthBookProvider(growthbook));

// Use OpenFeature's standard API everywhere in your app
const client = OpenFeature.getClient();

Now any part of your application that needs to check a flag uses the OpenFeature client, not the GrowthBook SDK directly. If you later switch to Unleash or LaunchDarkly, the provider line at startup changes; nothing else does.

Evaluation context: targeting without coupling

The power beyond simple booleans is targeting: a flag that is on for 10% of users, or on for all users in the “beta” group, or on only for a specific tenant ID. OpenFeature handles this through an evaluation context that you set per request:

import { OpenFeature, EvaluationContext } from "@openfeature/server-sdk";

// In your middleware or request handler
const context: EvaluationContext = {
  targetingKey: user.id,
  email: user.email,
  plan: user.plan,        // "free" | "pro" | "enterprise"
  region: req.region,
};

// This evaluation respects whatever targeting rules you defined in GrowthBook
const client = OpenFeature.getClient();
const showNewPricing = await client.getBooleanValue(
  "new-pricing-page",
  false,
  context
);

The targeting rules live in your flag provider’s dashboard. You can change who sees a feature without a deploy and without touching the code.

Hooks: what makes OpenFeature more capable than manual checks

OpenFeature hooks let you attach behavior to every flag evaluation without cluttering your feature code. The most useful patterns:

Logging hook. Record every flag evaluation for debugging:

import { Hook, HookContext, EvaluationDetails } from "@openfeature/server-sdk";

const loggingHook: Hook = {
  after(hookContext: HookContext, evaluationDetails: EvaluationDetails<boolean>) {
    logger.debug("Flag evaluated", {
      flagKey: hookContext.flagKey,
      value: evaluationDetails.value,
      reason: evaluationDetails.reason,
      userId: hookContext.context.targetingKey,
    });
  },
};

OpenFeature.addHooks(loggingHook);

Analytics hook. Send an event every time a feature is evaluated for A/B testing attribution:

const analyticsHook: Hook = {
  after(hookContext, details) {
    analytics.track("feature_evaluated", {
      flag: hookContext.flagKey,
      value: details.value,
      userId: hookContext.context.targetingKey,
    });
  },
};

These hooks apply globally, so you write them once and every flag evaluation in the application is automatically instrumented.

Choosing a provider

Provider	Hosted	Self-hosted	A/B testing	Pricing
LaunchDarkly	Yes	No	Yes	Enterprise ($)
GrowthBook	Yes	Yes	Yes	Free / $200+
Unleash	Yes	Yes	Limited	Free / Enterprise
Flagsmith	Yes	Yes	Limited	Free / $45+
Statsig	Yes	No	Yes	Free / $150+

For most small-to-mid teams, GrowthBook self-hosted covers feature flags and basic A/B testing at no infrastructure cost beyond the server you run it on. The UI is clean, the SDK coverage is good, and OpenFeature support is first-class.

If you are in enterprise and need SSO, audit logs, and SLAs, Unleash Enterprise or LaunchDarkly are the serious options. Both have OpenFeature providers, so you are not locked in.

What this looks like in a full-stack app

The pattern that works well across a full-stack app:

Server-side evaluations (API routes, middleware) use the OpenFeature Node.js SDK directly, as above.
Client-side feature flags for UI only (show/hide a component, toggle a layout) use the OpenFeature Web SDK with a browser-compatible provider. These are evaluated after hydration, so account for the flash of wrong content if you are gating layout.
Feature flags for AI model routing or prompt changes work the same way. See the feature flags for AI features post for the specific patterns around non-deterministic outputs.

When a flat file is enough

Not every application needs a feature flag service. If you are shipping weekly and deploying cleanly, environment variables cover the use case. A JSON file checked into the repo with your flag defaults, loaded at startup, is fine for small teams.

The right time to graduate to a proper flag system is when you want runtime changes without a deploy, when you want targeting by user attribute, or when your release cadence is fast enough that a flag rollback is faster than a hotfix deploy.

OpenFeature makes that graduation cheaper: you write against the standard API from the start, and the provider behind it can be a flat file in development and GrowthBook in production. The calling code never knows the difference.

Feature flags are a deployability decision more than a tooling decision. The goal is the ability to ship code before it is “on,” to decouple deploy from release. OpenFeature just makes sure that whichever tool you back that with, you can change your mind without rewriting half the codebase. For the broader architectural context, the monorepo tooling post covers how feature flag configuration fits into a multi-package setup.

Web Scraping in 2026: Playwright, Puppeteer, and the Legal Line

Abhishek Gupta — Tue, 16 Jun 2026 00:00:00 GMT

Someone on your team needs to pull data from a website that does not have an API. Maybe it is competitor pricing, maybe it is a public government data source that only has a web interface, maybe it is product listings from a marketplace. Web scraping is the answer. The question is how to do it cleanly, reliably, and without stepping into legal or ethical problems.

This is a practical guide. It covers tool choice, the patterns that work, the patterns that get you blocked, and the legal and ethical situation you need to understand before you ship anything commercial.

Playwright vs. Puppeteer vs. everything else

Playwright is the right default for new projects in 2026. The quick comparison:

Tool	Language	Browser support	Maintained by
Playwright	JS/TS, Python, Java, .NET	Chromium, Firefox, WebKit	Microsoft
Puppeteer	JS/TS	Chromium (Firefox experimental)	Google
Selenium	JS, Python, Java, Ruby, C#	All major browsers	Selenium Project
Scrapy	Python	N/A (HTTP only)	Open source

Playwright wins on most dimensions for browser-based scraping: cross-browser, automatic waiting for elements, better async API, and first-class Python support. Selenium is worth considering when you need Java or Ruby and the project is large enough to have settled on those languages. Scrapy is the right tool when you are scraping at scale and the target site is mostly HTML-rendered (no JavaScript needed). It is faster and more efficient for that workload.

Puppeteer is still used, particularly in Node.js projects where switching would be costly. But for greenfield work, there is no reason to choose it over Playwright.

A minimal working Playwright scraper

Here is what a clean Python scraper looks like in 2026:

import asyncio
from playwright.async_api import async_playwright, Page


async def scrape_listing(url: str) -> dict:
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        context = await browser.new_context(
            user_agent=(
                "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
                "AppleWebKit/537.36 (KHTML, like Gecko) "
                "Chrome/124.0.0.0 Safari/537.36"
            ),
            viewport={"width": 1280, "height": 800},
        )
        page: Page = await context.new_page()

        await page.goto(url, wait_until="domcontentloaded")
        # Playwright auto-waits; you should still be explicit about what you need
        await page.wait_for_selector(".product-title", timeout=10_000)

        title = await page.text_content(".product-title")
        price = await page.text_content(".product-price")

        await browser.close()
        return {"title": title, "price": price}


asyncio.run(scrape_listing("https://example.com/product/1"))

A few notes on this pattern:

Always set a realistic user_agent. A headless browser with the default Playwright agent is easy to fingerprint.
wait_until="domcontentloaded" is faster than networkidle and sufficient when your target content is in the DOM rather than loaded by a subsequent fetch.
wait_for_selector is more reliable than wait_for_timeout. An explicit time delay is fragile; an element wait adapts to the actual page state.

Patterns that prevent blocks

Anti-bot systems fingerprint several signals. Here are the practical countermeasures:

Rate limiting. Add delays between requests. One to three seconds between pages is the range most sites consider human. Machine-speed requests (hundreds per minute) will get you blocked everywhere.

import asyncio
import random

async def polite_fetch(page, url):
    await page.goto(url)
    # jitter the wait so it does not look robotic
    await asyncio.sleep(random.uniform(1.5, 3.5))

IP rotation. A single IP hitting a site repeatedly at any speed is detectable. For larger-scale work, use a rotating proxy service or accept that your scrape will be blocked and throttled.

Request headers. Rotate User-Agent strings, set Accept-Language and Accept headers to plausible browser values, and do not send headers that headless browsers omit by default (like Sec-CH-UA).

Session management. Logged-in sessions are more complex. If a site requires login, that is a clear signal that scraping it may violate the ToS, and you should read the legal section below carefully.

Handling JavaScript-rendered content

Sites that load content via JavaScript after page load need a headful or headless browser (Playwright or Puppeteer, not a plain HTTP fetcher like requests). The Playwright pattern above handles this. Two specific cases worth knowing:

Infinite scroll. The content loads as you scroll. Simulate this:

# Scroll to the bottom incrementally to trigger loading
for _ in range(5):
    await page.evaluate("window.scrollTo(0, document.body.scrollHeight)")
    await asyncio.sleep(1.5)

Waiting for network responses. Sometimes you want to intercept the API call the page makes rather than parse the rendered HTML. Playwright’s page.expect_response() lets you wait for a specific URL and parse the JSON directly, which is cleaner and more stable than HTML parsing:

async with page.expect_response(lambda r: "/api/products" in r.url) as resp_info:
    await page.goto(url)
response = await resp_info.value
data = await response.json()

This is worth checking: many sites that do not have a public API do have internal API calls. Intercepting those is simpler and more stable than scraping the HTML.

The legal and ethical lines

The legal picture shifted with the 9th Circuit’s ruling in hiQ v. LinkedIn (upheld in 2022), which held that scraping publicly accessible data does not automatically violate the Computer Fraud and Abuse Act. Public data, accessible without authentication, is generally scrapeable under US law.

That said, three things can create real legal exposure:

Terms of Service violations. Scraping in violation of a site’s ToS is a contract issue, not a criminal one under most readings of the CFAA, but it can result in civil action and account termination. Read the ToS before scraping commercially.

Personal data. If the data you are collecting contains personal information about EU residents, GDPR applies. If it contains California residents’ personal data, CCPA applies. “It’s public” is not a defense if you are building a database of personal information at scale.

Competitive misappropriation. Some courts have found scraping to create liability under state unfair competition law, particularly when it harms the business being scraped. The lines here are less clear.

The practical rule: check robots.txt, honor the Crawl-delay if it is set, do not scrape behind authentication without permission, and if you are building a commercial product on scraped data, talk to a lawyer before you launch.

When to use a managed scraping service

For personal projects and internal tooling, running your own Playwright scraper is fine. For commercial products where the scraping is core to the value proposition, managed services are usually the better investment:

Apify. Orchestration layer, actor-based jobs, runs at scale.
Bright Data. Residential proxy network, web unlocker, structured data products.
Oxylabs. Similar to Bright Data, strong enterprise support.
ScrapingBee. Simpler API, good for teams that want a service without managing the infrastructure.

These services handle residential IP rotation, browser fingerprinting challenges, and CAPTCHA solving. If your target site uses Cloudflare or Akamai Bot Manager, you will spend weeks building and maintaining bypass logic that a managed service has already solved. That time cost is real.

Storing and using scraped data

The scraping is usually the easy part. Think about these before you start:

How often do you need to refresh? Run your scrape on a schedule (Airflow, Prefect, even a cron job on a VPS) rather than on demand.
Where does the data land? Postgres with a scraped_at timestamp column is a sensible starting point. Add source_url so you can debug which page a row came from.
How do you handle change? Structure evolves. Name your selectors clearly, write tests against the structure, and get notified when a scrape yields zero results.

The most common failure mode is a scraper that silently stops working because the site changed a class name. An empty result is not an error the way a thrown exception is, so you have to build that check explicitly.

Web scraping is a legitimate tool for gathering data that is otherwise unavailable. Done well (with rate limiting, legal awareness, and a clear data storage strategy) it works reliably for years. Done without those considerations, it is a fragile script that gets blocked and creates liability. The gap between the two is mostly planning, not sophistication.

For related reading on automation tooling at the project level, GitHub Actions in 2026 shows how scheduled scraping jobs fit into a larger CI/CD workflow.

Developer Onboarding in 30 Days: Getting Engineers Productive Without the Chaos

Abhishek Gupta — Mon, 15 Jun 2026 00:00:00 GMT

The most common onboarding story I hear from developers joining new teams goes like this: day 1 is meeting people and waiting for accounts to be provisioned, day 2 is reading a README that was last updated 18 months ago, day 3 is unclear, and somewhere in week 2 they are handed a ticket with no context and told to figure it out.

This is not malicious. It is what happens when no one owns onboarding as an engineering concern. HR owns the paperwork. IT owns the accounts. The engineering lead is busy. The new developer has context debt that compounds with every day they spend trying to parse the codebase without a guide.

A month of that costs more than the setup time for a real onboarding process. Here is the one we use.

Before day 1

The biggest onboarding speedup is not something you do in the first week — it is setup you do before the developer arrives.

Create a single “start here” document. Not a list of links to Confluence pages — a document that tells the developer in plain text what the product does, what tech stack they will work in, who does what on the team, and what a good first week looks like. One page is enough. The goal is to give them enough context to ask useful questions rather than open-ended “where do I start?” ones.

Provision access before day 1. GitHub, the cloud environment, the deployment pipeline, the communication tools, the password manager. Waiting for IT requests to clear on day 2 is unnecessary friction and signals disorganization from the first impression.

Pick a first task in advance. Not a large feature — a small, real, code-touching task. A failing test to fix, a small UI bug with a clear reproduction path, a documentation gap. The first task is not about productivity. It is about getting the developer into the real workflow so they can ask specific questions.

Week 1: environment, first PR, first feedback loop

The goal for week 1 is narrow: get the developer’s development environment working, get them comfortable navigating the codebase, and get a PR merged.

Day 1 and 2 are setup and orientation. Pair them with whoever knows the codebase best — not for a formal walkthrough, but to answer questions in real time as they hit them. A codebase tour where someone just explains every file in order is not useful. A session where the developer runs the app locally, breaks something, and the pair helps them diagnose it is.

Day 3 is the first task. They know enough to start something. Let them struggle with it a bit before offering help — the struggle is where they learn what they do not know.

By end of week 1, the PR should be in review. The review matters as much as the code. This is the first time the developer gets a real signal about code standards, comment culture, and how the team communicates disagreement. Review it the same way you would review any PR, not more leniently because they are new. Overly gentle reviews do not help — they just delay the moment when real feedback arrives.

Week 2 and 3: expand scope, establish norms

The developer can now navigate the codebase and has been through the deploy pipeline. Week 2 is about broadening context.

Assign something slightly larger. Still scoped — not a month-long feature, but something that requires understanding more than one file or system. Notice where they get stuck. Those are your documentation gaps.

Run a reverse code review in week 2. Ask the developer to review someone else’s PR. This is underused as an onboarding tool. Reviewing code forces you to understand what you are looking at and reveals what you do not know. It also tells you a lot about how the new developer thinks. Do they look at tests? Do they ask about edge cases? Do they comment or stay quiet?

The end of week 2 is also when async communication norms need to be explicit, if they have not been. How does the team expect questions to be asked? Slack in a specific channel? A GitHub comment? Direct messages? Teams with undocumented norms create confusion that persists for months.

Week 4: solo task, performance conversation

By week 4, the developer should be working mostly independently. Assign something they own end to end: specification, implementation, tests, and the deploy. Watch what questions they bring and what they resolve themselves.

The end-of-month conversation is not a performance review. It is a two-way check-in. What is unclear? What would have helped? What is working? The developer has just spent 30 days forming opinions about the codebase, the team, and the processes. Those opinions are cheap to act on now and expensive to ignore for a year.

This conversation also surfaces onboarding debt. If they had to ask the same question twice because the answer was not documented, write it down. If something about the dev environment setup wasted two days, fix it before the next hire.

What to skip

Some things that end up in onboarding schedules and should not:

Day-long system tours. A three-hour walkthrough of every service in a distributed system on day 1 is not retained. Show the developer the parts they will touch in their first task. They will learn the rest as they need it.

Reading documentation without a task. Documentation is useful as a reference, not as a substitute for doing. Give them a task and point them at the docs that support it.

Isolated “training” work. Toy tasks built specifically for onboarding, like “build this feature in a throwaway branch,” are less effective than real tasks in the real codebase. The feedback loop is artificial and the stakes are wrong.

Onboarding a contractor versus a full-time hire

Contractors — whether through an agency or a marketplace — often have more context-switching experience and will get oriented faster on their own. They have usually seen more codebases than full-time engineers at the same experience level.

What contractors need that full-time hires also need but more urgently: explicit task definition, a clear deliverable for week 1, and access to whoever makes decisions about requirements. A contractor without access to that decision-maker is blocked every time they hit an ambiguous spec, and that compounds into expensive delays fast.

If you are hiring a contractor through a studio or agency, the handoff to your team is part of what you are paying for. Ask how they structure it — a studio that cannot describe their onboarding process is one that has not thought hard about how their developer will work in your environment. Our services page covers how we handle integration with existing client teams.

The metric that tells you if it is working

There is one leading indicator of a good onboarding process: does the developer make a meaningful commit in the first five working days?

Not a commit to a side branch nobody sees — a commit that goes through real review. That single event means the environment works, the developer understands what the codebase needs, and the feedback loop is running. Everything after that is about expanding scope.

If week 1 passes without that commit, something is blocked. Find it and remove it. The blockage is almost always documentation, access, or ambiguity in the first task — not developer skill.

For the hiring side of getting to that first onboarding, the full process for vetting and selecting a developer is in how to hire a vetted software developer.

How to Hire a React Developer in 2026: The Technical Screen That Finds Real Skill

Anurag Verma — Mon, 15 Jun 2026 00:00:00 GMT

Most teams screen React developers the wrong way. They pick a number of years of experience, run a coding challenge lifted from LeetCode, and then wonder why the hire who passed the screen can’t maintain a production codebase six months in.

The problem is usually a spec-to-screen gap: the company needs someone who can own a component library and debug rendering issues, but the screen tests algorithm fluency. Those are different skills.

This guide is for hiring managers and CTOs who want a screen that actually predicts job performance, not just interview performance.

Start with what your codebase actually needs

Before writing a job description, spend 30 minutes with whoever runs the React codebase. Ask three questions:

What is the most painful class of bug we deal with?
What does a new component need to satisfy before it gets merged?
What skill gap has caused the most incidents or delays?

The answers should drive your screen. A team that primarily writes data-heavy dashboards has different needs than one shipping a design system. Screening for the generic “React developer” instead of the specific role you need is how you end up paying for expertise you won’t use.

What good React skill actually looks like

React’s learning curve flattens early and then gets steep again. Getting hooks to work is fast. Understanding why a component re-renders six more times than expected, how to architect state that doesn’t turn into spaghetti at scale, or how to write tests that survive refactors — that takes longer and doesn’t come from tutorials.

The things that predict job performance are not the same as the things that are easy to test:

Rendering mental model. Can the candidate explain what triggers a re-render without being prompted? Do they know why React.memo is not always the right fix? This is the foundation. Without it, performance problems pile up invisibly.

State architecture instincts. At what point does co-located component state belong in a context? When does a context become a performance liability? Senior engineers have opinions on this. They will describe a tradeoff without being asked.

Testing discipline. Does the candidate write tests that verify behavior or tests that just cover lines? The difference shows up immediately when you ask them to walk through a test file.

Accessibility awareness. Not deep expertise — just knowing that a button should be a button, that interactive elements need focus states, and that screen reader support is a real requirement for most production apps.

Opinion about tooling. A senior React developer has worked with enough state management libraries, data-fetching strategies, and bundler configs to have genuine preferences. Blank indifference is a signal.

A three-stage screen

A single-stage process catches single failure modes. Here is a structure that has worked for us:

Stage 1 — Async exercise (2 hours target)

Send a take-home with a realistic but contained scope. A good prompt for most React roles:

Build a small component that:

Fetches a list of items from a public API
Handles loading and error states explicitly
Lets the user filter the list by a field of your choosing
Includes at least one test

Give candidates 48 hours. Make clear the 2-hour guidance is real — you are not looking for a polished app, and effort beyond that signals the candidate is anxious rather than thorough.

What you are evaluating:

Does the loading and error path actually work, or was it bolted on?
Is state in the right place, or is data living in components that don’t need it?
Does the test check behavior or just call a function and assert it exists?
Is the component readable by someone who did not write it?

You do not need TypeScript, a perfect file structure, or a production deployment. You need to see how they think.

Stage 2 — Live session (45 minutes)

Walk through their take-home together. The goal is not to critique it — it is to see how they reason when someone is watching.

Start with an open-ended question: “Walk me through the decisions you made on the state structure here.”

Listen for: confidence with tradeoffs, willingness to say “I would do this differently if I had more time,” and the ability to defend a choice without being defensive about it.

Then ask one debugging question. Introduce a simple bug or pull in something from your real codebase. How they approach it tells you more than the take-home did.

Finish with one performance question. “If this list had 10,000 items, what would break and what would you do about it?” Good answers mention virtualization or lazy loading. Great answers also question whether you need 10,000 items in the DOM at all.

Stage 3 — Values and async conversation (30 minutes)

This is a call with whoever the developer will work closest with. Not a technical round — a conversation about how they work.

Useful questions:

How do you decide when a PR is ready for review vs. when you need more time?
Tell me about a time you disagreed with a technical decision. What did you do?
How do you document work that is going to live in the codebase for years?

This catches a class of problems that technical screens miss entirely: people who are technically strong but write unreadable code, merge without reviews, or disappear when a deadline slips.

Red flags that compound

Some things that seem minor in a screen are expensive in production:

No opinion on testing. “I test when there is time” means there is never time. Good developers understand that untested code is debt that gets called in at the worst moment.

Reaching for a library before understanding the problem. Suggesting Redux for a contact form, or reaching for SWR when a single useEffect is fine, suggests the candidate navigates by pattern-matching rather than reasoning. That works until the project is unusual.

Inability to explain their own take-home. If a candidate used a pattern they read about but cannot explain why, the code review cycle will be expensive.

Confidence without curiosity. Senior engineers ask clarifying questions. The ones who don’t tend to build what they imagined, not what was needed.

The seniority question

The Stack Overflow Developer Survey 2025 found that React remains the most-used web framework for the fifth year running, which means the market is saturated with self-described “experienced React developers.” Seniority means something specific:

A mid-level developer makes it work. A senior developer makes it not break. The difference shows up in code reviews (do they catch issues before they ship?), in meetings (do they flag problems before they become blockers?), and in architecture discussions (do they think three decisions ahead?).

For most product teams, a strong mid-level developer with good instincts is a better hire than a technically senior developer with poor communication. Screen for both.

Before you post the job

Check what you actually need against what you are about to pay for. If the work is a defined project — an MVP, a new feature, a frontend rebuild — an agency or studio may be a better fit than a hire. We walk through the decision in how to hire a software development agency, and the cost comparison across models is in what it costs to hire a developer.

If you do need a dedicated seat, the full vetting process for any developer hire — not just React — is in how to hire a vetted software developer.

The screen above is a starting point, not a complete answer. Every team ships something slightly different. The best interview process is the one built around the specific problems your codebase actually has.

How to Get Hired as a Remote Developer in 2026

Abhishek Gupta — Mon, 15 Jun 2026 00:00:00 GMT

I have been on both sides of the remote hiring conversation: applying for contracts, and screening other developers for them. The thing that surprised me most is how rarely the strongest engineer wins. The developer who gets hired is usually the one who was easiest to say yes to.

That is good news, because being easy to evaluate is a skill you can build deliberately. Here is how.

Stop competing on skill alone

The instinct is to grind more LeetCode and add more frameworks to your resume. It rarely moves the needle. The person hiring you is not trying to find the best coder on earth. They are trying to confirm, quickly and with low risk, that you can do their specific job and will be easy to work with.

That reframing changes everything you do next. Your job is not to be the strongest. It is to be the clearest. Make the yes obvious.

If you want to understand exactly what the person on the other side is checking, read how teams actually screen developers. When you know what the screen tests, you can build the evidence it looks for.

Ship one thing, deeply

A profile with ten repos that are each two commits deep tells me nothing. One project that is real, deployed, and that you can walk me through tells me almost everything.

Pick something and take it further than feels necessary. Deploy it so it actually runs at a URL. Write a paragraph on what it does, what was hard, and one decision you would now make differently. That last part is the tell that you have shipped and learned, not just followed a tutorial.

Depth is the signal. A hiring manager can evaluate one deep project in three minutes. Ten shallow ones take longer and say less.

Make a profile that does the filtering for you

The developers who get inbound are the ones who are findable and legible. When someone lands on your page, three questions should answer themselves in the first few seconds: what do you do, what have you shipped, and are you available.

State your specialty in plain words. List the skills you would actually want to be hired for, not every technology you have touched. Link the one deployed project. Say whether you are open to work. A profile that does this filters out the wrong roles and pulls in the right ones without you doing anything.

This is the whole reason we let developers publish a profile in a few minutes and become discoverable to companies hiring through us. A clear public page is leverage. If you want one, you can build yours and read more about how the platform works.

Write about your work

You do not need a big audience. You need a small body of evidence that you think clearly.

One short post explaining a real decision you made, the constraint, the options, and why you chose what you chose, is worth more than another generic tutorial. It shows the exact judgment that companies are screening for and cannot test from a resume. It also keeps working while you sleep. Months later, someone finds it, and the conversation starts warm.

Be specific about rate and availability

This is where a lot of strong developers quietly lose work. Asked their rate, they say “it depends.” Asked when they can start, they hedge.

Vagueness reads badly. It signals either that you do not know your worth or that you are not really available. State a clear rate. Anchor it on what comparable developers in your stack charge, not on what you think you can get away with. Say plainly when you can start. You can always negotiate from a clear number. You cannot negotiate from a shrug.

Put it together

None of this requires you to be a stronger engineer than you are today. It requires you to package what you already are so a busy person can evaluate it fast.

Ship one real thing. Put up a page that answers the three questions. Write one honest post. Name your rate. Do that and you stop being a resume in a pile and start being an easy yes. If you want a place to publish that page and get in front of companies that are hiring, start here.

How to Hire a Software Development Agency in 2026

Anurag Verma — Mon, 15 Jun 2026 00:00:00 GMT

I run a software studio, which makes this an awkward post to write, because the honest version of “how to hire an agency” includes the things agencies prefer you did not scrutinize. I am going to write the honest version anyway, because the clients who know what to look for are better clients, and the agencies that fear an informed buyer are the ones you should avoid.

First, decide if you even want an agency

The most expensive mistake is hiring the right agency for the wrong kind of work.

Agencies are built for projects: a thing with a shape and a deadline. An MVP. A redesign. A feature your team has never built and does not want to learn once. You bring in a team that has shipped that shape before, they ship it, and you are not managing individuals day to day.

Agencies are the wrong tool for an ongoing seat. If what you actually need is a developer embedded in your team indefinitely, a direct hire or a long-term contractor is cheaper and closer to your context. The thinking behind that tradeoff is the same one in our breakdown of the hiring options: seat versus project decides more than brand or price.

Sort this out before you take a single sales call. It tells you whether you are even in the right aisle.

The proposal tells you most of what you need

You learn more about an agency from how it scopes than from how it sells.

A good proposal writes the work down. Not “we will build your platform,” but the specific systems, the phases, what is included and what is explicitly not. That document is doing real work: it is the thing you both point at when a disagreement happens, and disagreements always happen. Vagueness at the proposal stage is not a small thing to fix later. It is a dispute at the invoice stage, pre-loaded.

If an agency resists writing down scope and wants to keep things loose and trust-based until you have paid a deposit, that is information. The way we scope and price is laid out on our services page precisely because the document should come before the money.

Ask who actually builds it

The oldest move in this trade is senior-sells, junior-builds. The impressive person on the sales call is not the person who will write your code. You meet the principal, you sign, and your project lands with a team you never spoke to.

So ask directly: who specifically will do this work, and can I talk to them before I commit? A confident agency introduces the team. An evasive one talks about “our process” and “our bench.” You are allowed to want names.

References are weak, post-mortems are strong

Reference calls are theater. No agency hands you an unhappy client. You will hear three glowing stories that tell you nothing about the failure modes.

Ask a better question: tell me about a project that went wrong, and what you did about it. Every real agency has them. The ones worth hiring will answer honestly, because they have a system for when things break and they are a little proud of it. The ones to avoid will insist nothing has ever gone wrong, which means either they have not shipped much or they are lying to you in the first hour. Our own case studies exist alongside the messier lessons, and the messier lessons are the ones I would actually probe.

The counterintuitive green flag

Here is the signal I trust most, and it is the opposite of what you would expect from a sales conversation: a good agency will sometimes talk you out of building something.

A vendor says yes to everything because every yes is revenue. A partner tells you when a feature is premature, when your scope is too big for your stage, when you would be better served by a smaller build or a different approach. It costs them money in the short term and it is the clearest sign they are optimizing for your outcome instead of their invoice.

Start small

Whatever else you do, do not hand a stranger your whole project on day one. Start with a small, paid first phase: a discovery sprint, an architecture document, one slice of the build. You learn how they communicate, whether they hit dates, and whether the people who sold you are the people building. A good agency welcomes this because they are confident the small phase will earn the big one.

Hiring an agency well is mostly about refusing to skip these steps when you are in a hurry. The hurry is exactly when they matter. If you want to talk through whether your project is even an agency-shaped problem, tell us about it and we will give you a straight answer.

How to Hire a Vetted Software Developer in 2026

Prathviraj Singh — Mon, 15 Jun 2026 00:00:00 GMT

The word “vetted” has been worn smooth. Every platform, agency, and marketplace uses it, and it has stopped meaning anything specific. So before you hire anyone described that way, the useful move is to translate the word back into a process and ask what the process was.

I screen developers for a living. Here is what I actually look for, in the order it matters.

Vetting is a process, not a property

A developer is not vetted the way a diamond is certified. There is no universal test they passed once. Someone, somewhere, ran a screen and decided they cleared a bar. Your only real question is what that screen tested and whether it tested the thing that will break your project.

A resume read is a screen. So is a four-hour system design interview. Both produce a “vetted” developer and they are not remotely the same. When a vendor or a candidate uses the word, the right response is one question: what did the screen check? If the answer is fuzzy, the screen was fuzzy.

This is also the throughline in our comparison of hiring options: the platforms differ less in quality than in what they screen for and how much of it they let you see.

The three things a real screen tests

When we screen, we are answering three separate questions, and a strong candidate has to clear all three.

Can they build it? Not in the abstract. Can they build the kind of thing you need built. A backend specialist who has never shipped a React app is not a weak engineer, they are the wrong engineer for a frontend role. Test against the actual work.

Can they reason about tradeoffs? Code is the easy part now. AI writes a lot of it. The value a senior developer adds is judgment: choosing among three working approaches, knowing which one will hurt in six months, spotting the requirement nobody wrote down. You test this by asking them to defend a decision, not just produce an answer.

Have they shipped and lived with it? Anyone can build a feature. Fewer have maintained one after it broke in production at 2 a.m. Ask about something that went wrong. The depth of the answer tells you how much real ownership they have carried.

Run the screen that mirrors the work

The single best change most teams can make is to throw out the puzzle interview and replace it with a small, paid take-home that looks like your real work.

Give them a scoped task, a few hours, and pay them for it. Then sit down and have them walk you through it. You learn three things at once: whether they can build, how they think while building, and whether they communicate clearly about their own choices. A whiteboard reversal-of-a-binary-tree question tells you none of that.

The walk-through matters as much as the code. The signal I trust most is a candidate who points at their own work and says, “I did this, but if I were starting again I would do it differently, and here is why.” That sentence is impossible to fake and it is the clearest marker of someone who learns from what they ship.

Red flags that should end the conversation

A few patterns are reliable enough to act on.

A resume that lists twenty technologies at “expert” level. Real depth is narrow. Breadth that wide is usually a centimeter deep.

An inability to talk about failure. Everyone who has shipped real software has shipped real bugs. A candidate with only triumphs has either not done much or is not being honest.

Vagueness about their specific contribution. “We built a platform that served millions” is a team’s accomplishment. What did this person do? If they cannot draw a clean line around their own work, be careful.

A vendor that will not describe its vetting. If you are hiring through a platform and they answer “what do you test?” with a marketing figure instead of a method, you are buying a black box. Sometimes that is fine. Know that you are doing it.

If you cannot screen deeply yourself

Most teams hiring their first few engineers do not have someone who can run a rigorous technical screen. That is the honest reason vetted-talent services exist, and it is a good reason.

The thing to demand is transparency. The service worth paying for shows you what each candidate was tested on and why they made the shortlist. That is exactly the gap we set out to close: a structured screen you can actually see, with three to five candidates and the reasoning behind each. If that is what you need, describe the role or look at how we scope engagements first.

Hiring well is not about finding mythical top-percentile talent. It is about running a screen that matches your work and being honest with yourself about which parts of it you can run and which parts you should hand to someone who will show you theirs.

LLM Evaluation Platforms in 2026: LangSmith, Braintrust, and Weave

Prathviraj Singh — Mon, 15 Jun 2026 00:00:00 GMT

At some point in every LLM product build, the team realizes they cannot tell if the last prompt change was actually better. They made it because something looked worse in a few examples. They shipped it because something else looked better in a few other examples. Now they are not sure what they have.

This is what LLM evaluation is for: replacing “looks about right to me” with a measurement that holds up as the application grows.

The three platforms I have used seriously in production are LangSmith, Braintrust, and Weights & Biases Weave. They solve the same fundamental problem in meaningfully different ways, and the right choice depends on what your team already uses and what kind of evaluator you want to write.

What an eval platform actually does

Every platform in this space does three things, with varying depth:

Tracing. Capture every call to an LLM — the prompt, the model, the parameters, the response, the latency, the cost — so you can debug failures and understand what your application actually sent and received. This is the most basic feature and the one that every platform does reasonably well.

Evaluation. Run a set of inputs through your application, score the outputs against expected behavior, and surface which cases pass and which fail. The hard part is the scorer: what makes an output “good”? Some platforms let you write that logic as a function. Others rely on LLM-as-judge, where a second model scores the output of the first. Both have failure modes.

Dataset management. Store and version the test cases you care about so you can run them consistently as your prompts and models change. This is the unglamorous part that determines whether your evals are actually useful six months from now.

LangSmith

LangSmith is LangChain’s observability and evaluation product. If you are building with LangChain or LangGraph, the tracing integration is close to zero-configuration — you set an environment variable and your chain runs show up in the UI.

The tracing UI is genuinely good. You can see every node in a chain execution, the intermediate steps, where latency accumulated, and the token counts. For debugging “why did the agent take the wrong path,” it is the fastest tool I have used.

The evaluation layer is where you feel the seams. LangSmith gives you the structure — datasets, runs, evaluators — but the evaluator logic is something you write yourself or delegate to an LLM-as-judge. The built-in evaluators cover basic things like trajectory correctness for agents and string similarity, but any domain-specific correctness logic is yours to implement.

For teams already using LangChain, LangSmith is the obvious default. For teams that are not, the tracing setup requires more work and the advantages narrow.

Braintrust

Braintrust is framework-agnostic and has, in my experience, the best ergonomics for writing custom eval functions. The workflow feels closer to writing unit tests: you define a function that takes an input and an output and returns a score, you register your dataset, and the platform runs everything and shows you the results in a clean table.

from braintrust import Eval

def correctness_scorer(output, expected):
    # Your logic here — exact match, fuzzy match, LLM judge, whatever
    return 1.0 if output.strip().lower() == expected.strip().lower() else 0.0

Eval(
    "my-project",
    data=lambda: [
        {"input": "What is 2+2?", "expected": "4"},
        # more test cases
    ],
    task=lambda input: my_llm_function(input),
    scores=[correctness_scorer],
)

The results UI is the clearest of the three: you see a score per case, per run, and per version of your prompt. Regression tracking — “did this change make things worse on cases that used to pass?” — is a first-class feature rather than something you build yourself.

Braintrust’s weakness is tracing. It is less complete than LangSmith’s chain-level view, and for debugging multi-step agents the visibility is thinner. It is strongest as an evaluation-first tool with tracing as a secondary concern.

Weights & Biases Weave

Weave is W&B’s LLM observability product. If your team uses W&B for ML experiment tracking — training runs, hyperparameter sweeps, model versioning — Weave adds LLM tracing and evaluation to the same workspace.

The pitch is unification: your model training experiments and your deployed LLM application quality metrics live in the same tool. For teams that do both traditional ML and LLM work, this is real value. You can correlate a fine-tuning experiment with its downstream application performance without switching contexts.

For teams that are purely in the LLM application space with no ML training work, the W&B tooling can feel like more surface area than you need. The eval SDK is solid, the tracing is good, but there is no obvious reason to choose it over Braintrust unless you already have a W&B account and want to keep everything together.

Platform comparison

Feature	LangSmith	Braintrust	W&B Weave
Tracing	Excellent (LangChain-native)	Good	Good
Custom evaluators	Requires setup	First-class	Solid
LLM-as-judge	Yes	Yes	Yes
Dataset management	Good	Excellent	Good
ML experiment integration	No	No	Excellent
Framework dependency	LangChain preferred	None	None
Free tier	Yes	Yes	Yes

Building a minimum viable eval pipeline

A platform is infrastructure. Before you connect to any of them, you need test cases. Here is the sequence that avoids buying the tooling before you have anything to put in it:

Week 1: log everything. Add logging to every LLM call in production. Store the input, the output, the model, the prompt version, and any user feedback signal you have. You are building a dataset of real behavior before you decide what to evaluate.

Week 2: tag your failures. Go through a week of logs and tag 20 to 50 cases that produced wrong, unhelpful, or risky output. These are your first eval cases. The specifics depend on your application — for a customer support bot, “wrong” might mean off-topic or factually incorrect. For a code completion tool, it might mean code that does not compile.

Week 3: write the scorer. Define what passing looks like for your tagged cases. This forces you to articulate what “good” means for your application, which most teams have not done explicitly. A scorer does not have to be complex — a simple keyword check or LLM judge call is enough to start.

Week 4: connect the platform. Now you have a dataset and a scorer. Connect to whichever platform matches your stack, run your eval against the current production prompt, and save that as your baseline. Every prompt change from here gets measured against it.

The most valuable thing you can do after that baseline is routine: run evals on every prompt change, expand the dataset as new failure modes appear, and treat a regression in any category the same way you would treat a failing test in CI.

The practical guide to testing LLM features more broadly — including how to write evals without a dedicated platform — is in LLM evals in practice.

A word on LLM-as-judge

All three platforms support using a second LLM to score the output of the first, which solves the hard problem of “how do I write a function that captures quality for open-ended text?” The catch is that the judge is itself a language model — it can be wrong, biased by the model it is using, or inconsistent across runs.

LLM-as-judge is useful for dimensions that are hard to specify programmatically: coherence, helpfulness, tone. It is unreliable for factual correctness, security properties, or anything that requires reasoning about external context. Build a portfolio of scorers rather than relying on a single LLM judge for everything, and calibrate your judges by checking their scores against human ratings on a sample.

The platforms let you ship a product you can reason about at scale. The eval cases and scorers are what make those platforms useful. Start building them before you start evaluating tools.

Offshore vs Nearshore vs Onshore Software Development in 2026

Anurag Verma — Mon, 15 Jun 2026 00:00:00 GMT

The offshore-vs-onshore question never really gets easier, because the right answer keeps depending on things that are specific to your project, your team, and your tolerance for particular kinds of pain.

What I can give you is a framework that is not a sales pitch for any one model. I run a studio that works with global clients from India, so I have a stake in being honest about what offshore actually is and what it is not. The clients who’ve had good experiences knew what they were buying. The ones who didn’t usually believed they were buying something the model does not provide.

What the labels mean

Offshore means contracting work to a team in a significantly different timezone — typically 8 to 12 hours from your location. For US and European companies, offshore usually means India, Eastern Europe, Southeast Asia, or the Philippines. The talent pools are large, the rate differential is substantial, and the timezone gap is real.

Nearshore means contracting to a team in a closer timezone — within 3 to 5 hours. For US companies, that means Latin America. For European companies, it often means Eastern Europe or Turkey. Rates are lower than onshore but higher than offshore. The key selling point is that you can run a morning standup and get same-day responses to questions.

Onshore means working with a team in your own country. The rates are highest. The advantages are no timezone gap, the same regulatory and legal context, and often simpler compliance for regulated industries.

The real cost comparison

Hourly rates are not the comparison that matters. Total cost of a shipped project is.

If you hire an offshore team at 40% of an onshore rate but the project takes twice as long due to communication friction, the cost advantage has evaporated. If you hire an onshore team and the project ships in half the time because the team can walk over and ask a question, the premium was worth paying.

What actually drives total cost:

Specification quality. The more explicit your requirements, the less the timezone gap matters. A team that can build from a fully-written brief with edge cases documented does not need to call you when they hit an ambiguous case — they have the answer in the spec. This is true for any geography, but it penalizes offshore models more when skipped because the feedback loop is slower.

Number of decision cycles. Discovery-phase work — building something where you expect to change direction based on user feedback — burns through async communication overhead fast. Work with a stable spec that is mostly execution has a much better match with offshore.

Overlap hours. Most offshore arrangements include 2 to 4 hours of daily overlap by design, usually early morning for the offshore team and late afternoon for the US team. What that looks like in practice matters more than what it says in the proposal. Ask specifically: how does a developer flag a blocker when one appears?

Where each model works

Offshore works well for:

Execution-heavy projects with stable requirements
Backend and infrastructure work where questions are mostly technical and documentable
Teams with strong technical project management who can write good briefs
Long-term relationships where the team builds context over time — the first month is always the hardest

Offshore works poorly for:

Early-stage products where the spec changes every two weeks
Work that is highly collaborative and conversation-heavy
Teams without a technical person who can review work daily
Short-burst projects where there is not enough time to build shared context

Nearshore works well for:

Teams that need daily sync but cannot afford or staff onshore
Projects with moderate spec stability that still benefit from regular iteration
US companies building out digital product teams on a startup budget

Onshore works well for:

Highly regulated industries (finance, healthcare) where data residency and compliance conversations need to happen frequently
Products where customer insight needs to move into the build cycle very quickly
Teams where the communication model is inherently synchronous and that is not going to change

The India question specifically

India produces more English-speaking software engineers than any other country, the talent quality at the top is genuinely high, and the rate differential compared to the US and Western Europe is real. It is also, for most US and European companies, a 9-to-11-hour timezone gap, which is not a nearshore arrangement by any stretch.

Working across that gap well requires process investment that most teams underestimate. You need written handoffs, documented decisions, and a rhythm where the offshore team’s end-of-day and the US team’s start-of-day actually connect. Teams that treat it as “we’ll figure it out” usually pay for that in misaligned builds and slow iteration cycles.

When we work with US clients from our studio, we’re explicit about this upfront — the red flags and green flags to watch for when evaluating any India-based agency are covered in hiring a tech agency in India. The short version: process maturity matters more than portfolio.

The question under the question

Most teams asking about offshore vs. onshore are really asking: “how do I get good work done for less?” That is a reasonable question with more than one answer.

An alternative worth considering is not picking a geography at all, but picking a model. If the work is a scoped project — an MVP, a new feature, an integration — an agency arrangement (offshore, nearshore, or onshore) that owns delivery may cost less in total than hiring a contractor of any geography and managing them line by line. The comparison between models is in how to hire a software development agency.

If you are hiring a permanent seat, the geography decision matters more than for project work. But the principles for vetting a developer are the same regardless of where they are: good work sample, coherent problem-solving process, clear communication, and references you actually call.

A practical decision framework

Before picking a model:

Write one page describing the project. If you cannot get it onto one page with enough specificity that a developer who has never met you could start work, you are not ready to offshore.
Identify what “done” looks like for the first milestone. If you can’t define it now, nearshore or onshore will save you money on rework.
Count the decisions per week. High-decision work with frequent direction changes needs overlap. Low-decision execution work can run async.
Check your technical review capacity. Offshore requires someone on your side who can review code and catch problems early. If that person does not exist, budget for an onshore or nearshore technical lead.

The model that fits those constraints is usually obvious once the constraints are written down.

Writing a Technical Job Description That Attracts Senior Developers

Anurag Verma — Mon, 15 Jun 2026 00:00:00 GMT

Senior developers do not read job descriptions to get excited. They read them to find reasons to move on. By the time someone with 8 years of production experience opens your posting, they have read hundreds of others, and they can clock a generic description in about 30 seconds.

Most technical job descriptions fail for the same reasons: they are written by HR from a template, contain requirements that are obviously a wishlist rather than a real list, say nothing specific about what the developer will actually do, and bury the salary three clicks deep in an application form if they include it at all.

Here is what to do instead.

Start with what you are building, not who you are

The instinct is to open with a company description. “We are a fast-growing SaaS company on a mission to…” This is the part senior developers skip. They can read that later.

Open with the problem:

“We’re rebuilding our data pipeline from a fragile Python monolith into a service architecture. You’d own the migration plan and most of the implementation, working directly with our data team and one other backend engineer.”

That is a sentence a developer can evaluate. They know immediately whether this is a problem they find interesting, whether they have done something like it before, and whether the scope sounds right.

Compare it to: “We are looking for a passionate backend engineer to join our growing team and help us scale our platform.”

The second version is not wrong. It is just useless.

The technology section should be honest, not aspirational

Requirements lists are where job descriptions become fiction. A team that uses TypeScript, Postgres, and Docker will write a requirements list that also includes Kubernetes, Kafka, Redis, Elasticsearch, and strong familiarity with GraphQL. Those may be things you want to adopt someday. They are not what the developer will touch in their first year.

Senior developers know the difference between a real requirement and a wishlist. The wishlist is a signal that the role is not thought through, or that the team is fishing for a unicorn rather than a capable engineer who can learn what they do not know.

Write what they will actually work with on week one. Note what is planned or preferred but not required. Note what you are willing to teach.

You will work with: TypeScript, Postgres, Node.js, Docker, GitHub Actions Nice to have: Kubernetes, Redis, familiarity with stream processing

That is more useful than a 20-bullet requirements list and signals that you are serious about finding someone who fits, not someone who checked every box.

Five to seven requirements, maximum

Any requirements list past seven items is telling candidates something you probably do not mean to tell them: that the role is sprawling, the team has not decided what they actually need, or the hiring manager wrote the list without thinking about whether any one person could plausibly have all of it.

Five specific requirements that match the actual job beats fifteen generic requirements every time. “3+ years with React and strong understanding of rendering performance” is more useful to a candidate than “Strong experience with modern JavaScript frameworks.” The first one they can evaluate themselves. The second one means nothing.

On years-of-experience requirements: be careful. “10+ years of React experience” is a phrase that appeared in real postings in 2023 for a framework that shipped in 2013. Senior developers notice this. It signals either careless copy-paste or a genuine misunderstanding of the landscape. If you want someone with deep expertise, say what the expertise looks like, not how many calendar years it covers.

The 90-day question

One paragraph that describes what the developer will own in the first 90 days is worth more than a full “responsibilities” section of generic bullets.

“In the first three months, you would take over ownership of our authentication service — it needs a security audit, some performance work on the session management, and better test coverage before we expand it to support multi-tenancy. After that, you’d roll into our main roadmap, which for Q3 is focused on the API that our mobile clients use.”

A developer reading that knows what they are walking into. They can calibrate whether they have done something like it. They can ask specific questions in an interview. They cannot do any of that from “responsible for maintaining and improving our backend systems.”

What not to waste words on

Perks sections. “We offer unlimited PTO, a pet-friendly office, team lunches, and a $500 home office stipend.” These are not wrong, but they are not differentiating. Every tech company offers some version of this. Experienced candidates know perks lists do not tell you what it is actually like to work there.

Mission statements. One sentence is enough. More than that is the company’s marketing copy inserted into a document where someone is trying to make a practical decision.

“Team player” and similar. Any phrase that means “we want someone who does not cause problems” is not useful information. Everyone says this. If there is something specific about collaboration style that matters for the role, say that specifically.

The compensation question

Include it. A range is better than nothing. A specific number is better than a range if you actually have a budget in mind.

The argument against including it is usually about “flexibility” — you want to hire the right person regardless of where they land in a range. The argument for including it is that everyone is going to find out what the number is anyway, and filtering out candidates whose expectations are far outside your range is better done at the posting stage than after three interview rounds.

A developer who would have been excited about a $160,000 role but discovers in week four that the budget is $120,000 is now a developer who feels their time was wasted. That candidate tells other developers. Do not optimize the posting for candidates you cannot close.

The process section

One paragraph at the bottom describing the hiring process takes two minutes to write and reduces a lot of candidate anxiety. What are the stages? Who will they talk to? How long does it typically take? Is there a take-home?

Candidates who do not know what to expect will either drop off or spend interview energy on “what is going to happen next” instead of on the actual conversation. Transparency about process is also a real signal about the team’s organization.

For the screening and evaluation side of the process — how to run a technical screen that actually predicts job performance — we have written specific guides for hiring a React developer and the general framework for vetting any software developer. The job description is the first filter. The screen is what you learn after they apply.

Toptal Alternatives in 2026: How to Hire Vetted Developers

Anurag Verma — Mon, 15 Jun 2026 00:00:00 GMT

Someone on your team needs a senior React developer, the project started two weeks ago, and you do not have a month to run a hiring funnel. So you type “Toptal alternatives” into a search box, or more likely you ask an AI assistant for a shortlist. This post is the answer I wish that search returned.

I run a dev studio. We hire contractors, we get hired as one, and we have watched clients work through every option on this list. None of them is bad. They are good at different things, and the gap between them is rarely about quality. It is about what they screen for, how much they mark up, and how much of the work they take off your plate.

What Toptal actually sells

Toptal’s pitch is “top 3% of talent,” fast. The real product is risk reduction. You pay a premium and in exchange you do not interview ten people to find one who can do the job. For a non-technical founder hiring their first engineer, that is worth a lot.

The two honest complaints: the markup is steep, and the vetting is a black box. You are told the person passed a screen. You do not see the screen. When a placement does not work out, you cannot tell whether the vetting missed something or the role was just a bad fit.

If budget is not your constraint and you value speed over everything, Toptal is a reasonable default. For most of the teams I talk to, one of the options below fits better.

The marketplaces

Turing, Lemon.io, Arc, and Gun.io sit in roughly the same category: a vetted pool, a matching layer, lower markup than Toptal. They differ in the details.

Turing leans toward longer-term, full-time-equivalent remote engineers and global supply. Lemon.io is startup-friendly and moves quickly on contract roles. Arc and Gun.io sit closer to a curated freelance marketplace. The vetting is real but lighter than Toptal’s, which is exactly why the price is lower.

The tradeoff to go in with eyes open about: lighter vetting means more variance. You will get strong people and you will occasionally get a mismatch, so keep your own short technical screen in the loop. If you have someone technical who can spend 30 minutes checking fit, marketplaces give you most of Toptal’s benefit at a real discount.

Hiring an agency or studio

This is the option people forget. Instead of one contractor, you bring in a small team that has shipped together. You trade the lower hourly rate of a solo freelancer for delivery you do not have to manage line by line.

Agencies make sense when the work is a project, not a seat: an MVP, a feature with a deadline, an integration nobody on your team has done before. We wrote up how to evaluate one because the failure modes are specific and avoidable. If you want the short version of what good looks like, our services page lays out how we scope and price.

Where it is wrong: if you genuinely need a person embedded in your team for a year, an agency seat is more expensive than a direct hire.

The newer option: an AI-managed shortlist

The model we have been building toward is different from all of the above. You describe the role in a conversation. An agent gathers the requirements in detail, sources matching developers, runs a structured screen, and hands you three to five vetted candidates. You only run the final decision interview.

The reason this matters is not novelty. It is that the screening is explicit. You can see what was tested and why each candidate made the shortlist, which is the exact thing the black-box vendors will not show you. It sits between “hire a marketplace contractor and screen them yourself” and “pay Toptal to screen for you,” and it is cheaper than the second because no human recruiter runs the funnel.

If that is the shape of what you want, tell us about the role and you will see how the shortlist comes together.

How to actually choose

Forget the brand names for a second. The decision comes down to three questions.

How much risk can you carry? Less technical buyers should pay for heavier vetting. Teams with a strong engineer who can screen can go lighter and save money.

Is this a seat or a project? A seat, meaning ongoing and embedded, favors marketplaces or a direct hire. A project, meaning scoped with a deadline, favors an agency or a managed engagement.

Can the vendor describe their vetting? This is the filter that matters most. Any serious option, Toptal included, should be able to tell you exactly what they test. If the answer is vague, the vetting is vague.

The thing I want you to take away is that “vetted” is not a property a developer has. It is a process someone ran, and processes vary enormously. Ask to see it. The vendor worth hiring will be glad you did, and if you want a second opinion on a role you are filling right now, reach out. We will tell you honestly which path fits, even when it is not us.

What It Costs to Hire a Developer in 2026

Shashikant Gupta — Mon, 15 Jun 2026 00:00:00 GMT

People ask me what it costs to hire a developer and expect a number. The honest answer is that the number they are picturing, the salary or the hourly rate, is the least important figure in the calculation. I look at hiring costs for a living, and the teams that overspend almost always did it by comparing rates instead of totals.

So this is not a rate card. Rates move too much by region, seniority, and stack for a single figure to mean anything. This is a framework for budgeting the total cost of each model, so you can choose the one that is actually cheapest for your situation.

The salary is the down payment, not the price

When you hire a developer full time, their pay is the visible cost. The real cost is meaningfully higher, and the gap is not a rounding error.

Add employer taxes and benefits. Add equipment and software licenses. Add the recruiting cost to find them and the weeks of reduced output while they onboard. Add the management time their work requires from someone more senior. Across all of that, the loaded cost of a full-time engineer runs well above their salary, and the multiplier is large enough that ignoring it wrecks a budget.

Full-time hiring is still the right call when the work is core and permanent. You are buying not just output but continuity, context, and ownership that compounds over years. Just budget for the loaded cost, not the offer letter.

Freelance: cheapest per hour, not always per project

A freelancer’s hourly rate is usually the lowest number you will see, and that is exactly why it is easy to misread.

The hidden costs sit around the rate. You spend time screening, because an unvetted freelancer is a real risk. You spend time managing, because they are not embedded in your context. And you carry the cost of a mismatch, which on a tight timeline can be larger than the entire contract. The path that controls this is to pair a marketplace contractor with a short screen of your own, which we walk through in how teams screen developers.

Freelance wins on total cost when the work is well defined, your own technical oversight is strong, and the relationship is ongoing enough to amortize the screening.

Agencies: more per hour, often less per outcome

An agency’s blended rate is higher than a freelancer’s, and people stop the comparison there. That is the mistake.

What you are buying with the higher rate is delivery risk moving off your plate. A team that has shipped your kind of project before needs less management, makes fewer expensive architecture mistakes, and is accountable for the outcome as a unit. For a scoped project with a deadline, that frequently costs less in total than a cheaper-per-hour arrangement that you have to manage closely and that might miss the date.

The way to keep an agency honest on cost is a written scope and a small first phase, which is the same discipline in how to hire an agency. Our services page shows how we structure scope so the price is a fixed quantity, not a meter running.

Managed: a fee to skip the funnel

The last model is the one we build. You pay a fee and in exchange you skip the most expensive thing of all, which is your own team’s time spent running a hiring funnel.

Sourcing, screening, and shortlisting consume senior hours that could be spent building. A managed engagement absorbs that and hands you three to five vetted candidates with the screening shown. Whether the fee is worth it comes down to one question: is your team’s time the scarce resource? For a small team where every senior hour matters, paying to skip the funnel is usually cheaper than the funnel.

Budget for the total, compare to the outcome

The single habit that fixes hiring budgets is to stop comparing rate to rate and start comparing total cost to outcome.

A freelancer at a low hourly rate who needs heavy management and might miss the deadline can be the most expensive option in the building. An agency at a higher rate that ships the project on time and off your plate can be the cheapest. The rate told you almost nothing. The total cost against the value of the result told you everything.

Decide whether you are buying a seat or a project. Estimate the full cost of that model, overhead and risk included. Then weigh it against what the outcome is worth to your business. If you want help running that math for a specific role, tell us about it and we will give you an honest read, even when the cheapest answer is not us.

How to Price Projects When AI Wrote Half the Code

Anurag Verma — Sun, 14 Jun 2026 00:00:00 GMT

A developer on your team spends three hours building a feature that would have taken eight hours a year ago. The client gets the same outcome. Do you charge for three hours or eight?

Most agencies are quietly answering this question right now without having answered it out loud. The choices being made by default will define margins, client relationships, and competitive positioning for the next few years.

There’s no universally correct answer. But there are wrong ways to handle it, and some approaches hold up much better under pressure than others.

The Problem With Time-Based Billing in an AI World

Time and materials pricing made sense when developer time was the primary input into software. You hired skilled people, they worked hours, and the client paid for those hours. The relationship between time spent and value delivered was close enough that billing for time as a proxy for value was defensible.

AI tools have broken that proxy. A developer with strong AI tool skills might deliver work in two hours that another developer (or the same developer a year ago) would have needed twelve. The output is similar. The input is not.

If you’re billing hourly, you’re now in a position where:

Being good at AI tools lowers your revenue
Being slow (or avoiding AI) pays better per project
Clients with any insight will notice the pattern

That’s a bad dynamic. The business model punishes competence.

Fixed-price projects have the opposite problem. If you quoted based on eight-hour assumptions and now complete the work in three, you pocketed the difference, which is the normal business logic of fixed-price work. Except clients are becoming aware that AI changes completion times significantly, and some are starting to ask about it in proposal conversations.

What Clients Are Actually Asking

Client awareness varies widely, but a consistent pattern is emerging: sophisticated buyers ask directly, while smaller clients often don’t think to ask until after they’ve had a few projects.

Questions that have started appearing in RFPs and proposal conversations:

“What percentage of your development work uses AI assistance?”
“How does AI change your pricing vs a year ago?”
“If AI writes the code, what are we paying you for?”

That last question isn’t hostile. It’s fair. And it has a good answer that most agencies haven’t yet learned to articulate.

What clients are paying for isn’t keystrokes. It’s:

Judgment: which of the three AI-generated approaches is actually right for their system
Architecture: decisions that don’t show up in any single file but shape everything downstream
Review: catching what AI got wrong before it ships
Context: knowing the client’s constraints, team, and technical history
Accountability: being the party responsible when things go wrong

AI handles the mechanical parts of software production. The parts that require experience, client knowledge, and professional judgment remain human work. That’s worth paying for, and pricing should reflect it.

Three Models That Work

1. Value-Based Pricing

Price based on the outcome, not the inputs. What is this feature worth to the client’s business? A checkout flow that converts 2% better for a $5M annual revenue business is worth real money regardless of how long it took to build.

Value-based pricing requires you to understand the client’s business well enough to quantify the outcome, and to have the confidence to charge accordingly. Most agencies are uncomfortable with this model because it requires negotiating on business value rather than scope, and it means some projects will generate excellent margins while others are thin.

Where it works: clients with measurable revenue outcomes (e-commerce, SaaS, lead generation sites) where you can connect your work to business results. It’s harder to apply to internal tools or branding projects where ROI is diffuse.

2. Output-Based Pricing

Charge per feature, per component, or per deliverable. Scope the project in terms of what will be built, not how long it takes.

“$4,000 for the user authentication system (registration, login, password reset, email verification, social OAuth).”

This is easier to defend than hourly billing because you’re quoting on what the client gets, not how long you take. If AI lets you build the auth system in two days instead of five, that’s your efficiency to keep.

The catch: scope definition is harder than it sounds. “User authentication system” means different things to different clients. Good output-based pricing requires detailed specifications, which you should be writing anyway.

Where it works: established agencies with good discovery processes who can define scope accurately. It fails for projects where requirements are fuzzy or change frequently.

3. Retainer with Defined Capacity

Monthly fee for a defined amount of capacity: a set number of developer-days or story points per month. The client uses that capacity on whatever matters most, and unused capacity doesn’t roll over.

AI efficiency doesn’t directly affect this model because you’re selling access to skilled judgment over time, not a fixed block of time itself. You scope what can realistically be done in a month with AI-assisted development, price the month accordingly, and deliver against that scope.

This model works well for ongoing product development relationships where requirements evolve and the value of predictability (for both parties) is high.

Where it works: long-term relationships with sophisticated clients who want a development partner rather than a project vendor.

The Transparency Question

Some agencies are preemptively addressing AI efficiency in their proposals. Something like:

“We use AI coding tools on all projects, which lets us move faster and catch more edge cases. Our pricing reflects what the work is worth and what it takes from us in skill and judgment, not raw hours.”

This is honest and positions the agency well. It turns AI from something to hide into something to be proud of.

A small number of clients will push back and ask for hourly billing specifically. This is a compatibility signal. Clients who only want to pay for hours are betting against your efficiency. That’s a relationship that will struggle as AI tools improve.

Clients who understand they’re paying for outcomes and judgment tend to be better partners. Proactively framing your pricing this way acts as a filter.

What to Do With the Efficiency Dividend

The honest answer: keep most of it, pass some of it on.

Trying to maintain exactly the same billing on projects that now take half the time is a path to client resentment. If a client knows a project type well and sees your quote go up year-over-year while the timeline goes down, the math is visible.

A reasonable approach: price AI-assisted projects somewhere between what you’d have charged in 2024 and what pure hourly billing would give you now. You’re faster and more capable than you were. Charge accordingly, modestly less than the pre-AI equivalent, not dramatically less.

More importantly, reinvest efficiency gains into quality: more thorough review, better testing, more careful architecture conversations. Clients don’t need to know this is happening. They’ll feel it in fewer bugs and better delivered work.

Proposals That Hold Up Under Scrutiny

If your pricing model changes, your proposal documents need to support it.

A proposal that used to say “200 hours at $150/hour = $30,000” needs to become something different. Options:

Scope-based: “User authentication system, product catalog with search, checkout with Stripe, order management dashboard: $28,000.”

Phase-based: “Phase 1: Discovery and architecture ($4,000). Phase 2: Core feature development ($18,000). Phase 3: QA, performance optimization, and launch ($6,000).”

Outcome-based: “A fully functional e-commerce platform capable of handling your projected 500 orders/day at launch, with a two-week onboarding period and 30 days of post-launch support — $30,000.”

All three are harder to argue with on a per-hour basis, because they’re not quoting per hour.

One Concrete Change to Make Now

If you’re still billing hourly and this post is resonating, the single highest-leverage change is: stop quoting projects as time estimates.

Instead, quote total project fees based on scope. When clients ask how many hours it will take, answer: “Our projects are priced based on what we’ll deliver, not how long we take. We commit to the outcome at the price we’ve quoted.”

Some clients will push back. The right clients won’t.

The underlying point is this: AI has changed what goes into building software, not what software is worth. Pricing should reflect the value to the client and the skill it takes to deliver, not the computational work of generating code. Agencies that make this shift explicitly will have cleaner relationships and better margins than those still waiting for the right moment to have the conversation.

AI Search Is Eating Web Traffic: What Developers and Agencies Need to Do About It

Anurag Verma — Sun, 14 Jun 2026 00:00:00 GMT

The deal web publishers had with Google was simple: create content, get traffic. Google indexed it, ranked it, and sent visitors. That deal is changing.

Google AI Overviews answer informational queries directly in search results, pulling from indexed pages without necessarily sending traffic to them. Perplexity builds answers from cited sources but keeps users inside its interface. ChatGPT’s web search mode answers questions with brief citations at the bottom. The query gets answered, but the click that used to follow doesn’t always happen.

This isn’t speculation anymore. Publishers across verticals have reported meaningful changes in referral traffic from search for informational content. The pattern is specific: tutorial-style content (“how to do X”), definition content (“what is X”), and listicle content (“best tools for X”) are seeing the sharpest impact. Opinionated takes, case studies, and data-backed analyses are holding better.

For agencies and developers who run content programs, this is a shift worth understanding clearly.

What’s Actually Happening

Three separate things are happening simultaneously, and it helps to separate them.

AI Overviews in Google Search appear above organic results for queries Google classifies as informational. They’re generated from web content but don’t always trigger a click through to the source. Google has stated it prioritizes sources for overviews, but citation doesn’t guarantee traffic.

Perplexity and ChatGPT Search are alternative search interfaces that a growing slice of users choose over Google for research queries. These tools typically cite sources more explicitly than Google AI Overviews, and some portion of their users do click through, though the user base is smaller than Google’s.

Zero-click rates were already rising before AI Overviews, driven by featured snippets, Knowledge Panels, and People Also Ask. AI Overviews accelerate an existing trend rather than starting a new one.

The net effect is concentrated on the middle of the funnel: informational content that used to drive awareness and early consideration is generating fewer visits from organic search.

What Still Works

Not all traffic is declining equally. Content that doesn’t get swept up in AI-generated answers still drives visits.

Specificity defeats the overview. AI Overviews handle general questions well. “How does JWT authentication work?” gets summarized. “How do I configure Auth.js v5 with Drizzle ORM and a Next.js App Router project?” is specific enough that a direct, detailed answer exists in one place, and a user with that problem will click through to find it.

The practical implication: go narrower. Instead of “how to optimize a PostgreSQL query,” write “how to diagnose an n+1 query in Django with django-debug-toolbar.” The specific answer doesn’t fit in a summary box.

Opinion, experience, and case studies. AI tools can summarize claims, but they can’t generate original experience. A post titled “We migrated from Prisma to Drizzle and here’s what we learned” contains first-person data that doesn’t exist anywhere else. It can’t be replaced by a synthesis.

Recency for fast-moving topics. A post published the week Bun 2.0 ships, or the day a framework releases a security patch, is faster than any AI knowledge cutoff. Time-sensitive content gets traffic before the AI tools catch up.

Tool comparisons with current pricing. AI Overviews use training data with cutoff dates. Pricing tables, benchmark comparisons, and feature matrices go stale. A detailed comparison of Vercel vs Cloudflare Pages pricing from last week isn’t in any AI’s training data.

Content that readers want to save, share, or reference. Long-form guides, checklists, and reference materials get bookmarked and linked. That link signal still matters for rankings, and bookmarked content gets revisited regardless of search.

How AI Search Decides What to Cite

Understanding how Perplexity and ChatGPT Search select sources helps you write content that gets cited rather than ignored.

Structured, factual claims. AI citation algorithms favor content with clear, specific claims stated directly. “Fastify handles approximately 70,000 requests per second on a standard Node.js benchmark” is more citeable than “Fastify is very fast.”

Clean HTML structure. AI crawlers parse your page the same way screen readers do: headings, paragraphs, lists, and tables. Dense prose with few semantic markers is harder to extract. Use <h2>, <h3>, <ul>, and <table> deliberately.

Authoritative signals. Domain authority still matters. Being cited once by a high-authority source creates a feedback loop. If Perplexity cites you in an answer, users who click through to your site may link to you, which improves your ranking in traditional search results, which improves your chance of being cited again.

Freshness. AI search tools crawl frequently and often prioritize recent content. Dates in your frontmatter matter. A post with a 2024 publish date loses to a 2026 equivalent on queries where recency matters.

Structured Data for AI Discoverability

Schema.org markup doesn’t directly affect AI Overviews, but it improves how Google understands and classifies your content, which indirectly affects which pages get included in AI-generated answers.

For technical blog posts, Article schema is the baseline:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Fastify in 2026: The Node.js API Framework That Stayed When Everyone Left",
  "datePublished": "2026-06-14",
  "dateModified": "2026-06-14",
  "author": {
    "@type": "Person",
    "name": "Anurag Verma"
  },
  "publisher": {
    "@type": "Organization",
    "name": "CoderCops"
  },
  "description": "..."
}
</script>

For FAQ-style content, FAQPage schema makes the Q&A structure explicit:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "When should I use Fastify instead of Express?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use Fastify when you need schema-based validation, automatic OpenAPI documentation generation, or are building a high-throughput API where JSON serialization speed matters."
      }
    }
  ]
}
</script>

Note: Google’s documentation explicitly states that FAQ schema doesn’t guarantee a featured snippet or AI Overview inclusion. It’s one signal among many.

What to Track Now

The standard metric, organic sessions from Google, is becoming a lagging indicator. It captures clicks but not impressions or citations.

Add to your tracking:

Google Search Console impressions (not just clicks). If impressions hold but clicks drop, that’s an AI Overview pattern: your content is being seen in summaries but not clicked.
Referral traffic from Perplexity, ChatGPT, and other AI search tools. These show up as referral sources in your analytics when users do click through.
Direct traffic changes. Some AI-cited content drives brand searches and direct visits, not tracked as organic.
Branded search volume. If your brand name appears in AI answers as a citation, branded search typically increases.

Stop optimizing for:

Keyword density. AI Overviews don’t care about keyword repetition; they care about clear, accurate answers.
Exact-match anchor text. The link graph still matters, but anchor text optimization is increasingly irrelevant.
Thin pages targeting long-tail keywords. These were already losing to featured snippets; AI Overviews accelerate that.

The Agency Angle

For agencies running content programs for clients, the conversation is shifting from “get on page one” to “get cited in AI answers.”

Those are related but different goals. Page one requires backlinks and authority at scale. Getting cited in an AI answer requires being the clearest, most specific, most structured source on a topic.

That means:

Depth over breadth. Ten well-researched, specific posts beat a hundred thin ones. The specific posts get cited; the thin ones get absorbed.

Update discipline. A post with accurate current information beats a better-written post with stale facts. Building in a quarterly review of high-traffic posts to update pricing, version numbers, and statistics is now table stakes.

Original data. Surveys, benchmarks, case studies, and analysis of proprietary data are the formats least replaceable by AI summaries. If your agency runs a survey of 200 clients about their AI budgets, that data exists nowhere else and will get cited.

The underlying point: the content that’s always worked (genuinely useful, specific, authoritative, kept current) works better than ever. What’s changing is that generic SEO content, written to rank rather than to help, is getting competed away by AI systems that are very good at generic answers. The bar for what earns traffic has moved up.

That’s uncomfortable for content programs built on volume. It’s straightforward for teams that were already writing things worth reading.

Cloudflare Durable Objects: Stateful Edge Computing That Actually Works

Anurag Verma — Sun, 14 Jun 2026 00:00:00 GMT

Cloudflare Workers are stateless by design. Each request handler starts fresh, processes, and exits. That’s what makes them fast and infinitely scalable, but it also means you can’t hold mutable state in memory. The moment you need something like “how many active connections are in this chat room right now?” you’re stuck reaching for a database. Now your edge function has a latency floor set by the database round trip.

Durable Objects are Cloudflare’s answer to that problem. They’re stateful, strongly consistent, and single-threaded. Each object instance runs in exactly one location at a time, processes requests one at a time, and persists its state to Cloudflare’s storage. You get the coordination guarantees of a single-process system with the global reach of edge infrastructure.

The Core Model

A Durable Object is a JavaScript class that Cloudflare instantiates and keeps alive. The key properties:

Single-instance per ID: For a given ID, there’s exactly one running instance, somewhere in Cloudflare’s network.
Location pinning: The instance migrates to be close to where requests originate. If most requests come from Mumbai, the instance runs near Mumbai.
Serialized request handling: Requests to the same instance are queued. No concurrent execution, no race conditions.
Built-in storage: Each instance has access to a transactional key-value store. Data persists across hibernation periods.

Here’s the minimal definition:

export class Counter implements DurableObject {
  private count: number = 0;
  private state: DurableObjectState;

  constructor(state: DurableObjectState, env: Env) {
    this.state = state;
    // Restore from storage on startup
    this.state.blockConcurrencyWhile(async () => {
      this.count = (await this.state.storage.get('count')) ?? 0;
    });
  }

  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);

    if (url.pathname === '/increment') {
      this.count++;
      await this.state.storage.put('count', this.count);
      return Response.json({ count: this.count });
    }

    if (url.pathname === '/value') {
      return Response.json({ count: this.count });
    }

    return new Response('Not found', { status: 404 });
  }
}

And the Worker that routes requests to the right instance:

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    
    // Extract a namespace from the URL — each unique ID gets its own object
    const counterId = url.searchParams.get('id') ?? 'global';
    
    // Get or create the Durable Object stub
    const id = env.COUNTER.idFromName(counterId);
    const stub = env.COUNTER.get(id);
    
    // Forward the request to the object
    return stub.fetch(request);
  }
};

The wrangler.toml binding:

[[durable_objects.bindings]]
name = "COUNTER"
class_name = "Counter"

[[migrations]]
tag = "v1"
new_classes = ["Counter"]

Why This Is Different From KV

Cloudflare KV is a global distributed key-value store. It’s eventually consistent: a write in one region takes a few seconds to propagate everywhere. For most reads, that’s fine. For counters, leaderboards, inventory, and anything where the current value matters before you write, it’s a serious problem.

With KV, two simultaneous increments on the same counter will both read the old value, both add 1, and both write back the same new value. You lose an increment.

Durable Objects don’t have that problem. Because all requests to a given object are serialized, the second increment request waits until the first completes. No lost updates.

	Cloudflare KV	Durable Objects
Consistency	Eventual	Strong
Read latency	~1ms (from cache)	~10ms (round trip to instance)
Concurrent writes	Race conditions	Serialized, safe
Best for	Config, cached data	Coordination, counters, sessions
Pricing (storage)	$0.50/GB-month	$0.20/GB-month
Pricing (reads)	$0.50/million	$0.20/million

Real-Time Collaboration: A Chat Room

The most common Durable Object use case is real-time coordination. Here’s a WebSocket chat room where the Durable Object tracks connected clients and broadcasts messages:

export class ChatRoom implements DurableObject {
  private sessions: Map<WebSocket, { name: string }> = new Map();
  private state: DurableObjectState;

  constructor(state: DurableObjectState, env: Env) {
    this.state = state;
    // Accept WebSocket connections from hibernated state
    this.state.getWebSockets().forEach((ws) => {
      const meta = ws.deserializeAttachment() as { name: string };
      this.sessions.set(ws, meta);
    });
  }

  async fetch(request: Request): Promise<Response> {
    if (request.headers.get('Upgrade') !== 'websocket') {
      return new Response('Expected WebSocket', { status: 426 });
    }

    const url = new URL(request.url);
    const name = url.searchParams.get('name') ?? 'anonymous';

    const pair = new WebSocketPair();
    const [client, server] = Object.values(pair);

    // Accept and register with Cloudflare's WebSocket hibernation API
    this.state.acceptWebSocket(server);
    server.serializeAttachment({ name });
    this.sessions.set(server, { name });

    this.broadcast({
      type: 'system',
      text: `${name} joined`,
      time: Date.now(),
    }, null);

    return new Response(null, { status: 101, webSocket: client });
  }

  async webSocketMessage(ws: WebSocket, message: string | ArrayBuffer): Promise<void> {
    const session = this.sessions.get(ws);
    if (!session) return;

    const text = typeof message === 'string' ? message : new TextDecoder().decode(message);

    this.broadcast({
      type: 'message',
      name: session.name,
      text,
      time: Date.now(),
    }, ws);
  }

  async webSocketClose(ws: WebSocket, code: number): Promise<void> {
    const session = this.sessions.get(ws);
    this.sessions.delete(ws);
    if (session) {
      this.broadcast({
        type: 'system',
        text: `${session.name} left`,
        time: Date.now(),
      }, null);
    }
  }

  private broadcast(data: object, exclude: WebSocket | null): void {
    const message = JSON.stringify(data);
    this.sessions.forEach((_, ws) => {
      if (ws !== exclude && ws.readyState === WebSocket.READY_STATE_OPEN) {
        ws.send(message);
      }
    });
  }
}

The getWebSockets() call in the constructor is the hibernation API at work. Cloudflare can pause the object when no requests are active and wake it up when a new message arrives, without losing the WebSocket connections. You pay for compute only when processing messages, not for idle connections.

Rate Limiting Per User

Rate limiting is another classic Durable Object use case. A global rate limiter that’s actually accurate (no race conditions) across any number of Worker instances:

export class RateLimiter implements DurableObject {
  private state: DurableObjectState;

  constructor(state: DurableObjectState, env: Env) {
    this.state = state;
  }

  async fetch(request: Request): Promise<Response> {
    const now = Date.now();
    const windowMs = 60_000; // 1 minute window
    const limit = 100; // requests per window

    const windowStart = now - windowMs;
    
    // Get existing request timestamps for this window
    const timestamps: number[] = (await this.state.storage.get('timestamps')) ?? [];
    
    // Remove expired entries
    const active = timestamps.filter((t) => t > windowStart);
    
    if (active.length >= limit) {
      const oldestActive = Math.min(...active);
      const resetIn = Math.ceil((oldestActive + windowMs - now) / 1000);
      
      return Response.json(
        { allowed: false, resetIn },
        { status: 429, headers: { 'Retry-After': String(resetIn) } }
      );
    }

    active.push(now);
    await this.state.storage.put('timestamps', active);

    return Response.json({
      allowed: true,
      remaining: limit - active.length,
    });
  }
}

In your Worker:

async function checkRateLimit(userId: string, env: Env): Promise<boolean> {
  const id = env.RATE_LIMITER.idFromName(userId);
  const limiter = env.RATE_LIMITER.get(id);
  
  const response = await limiter.fetch('https://rate-limiter/check');
  const { allowed } = await response.json();
  return allowed;
}

Each user gets their own Durable Object instance. The rate limiter for user A and user B never touch the same storage or contend with each other. And unlike a Redis-based rate limiter, this one doesn’t require a separate infrastructure component.

Storage Patterns

The Durable Object storage API is transactional and supports batching:

// Atomic multi-key operations
await this.state.storage.transaction(async (txn) => {
  const balance = await txn.get<number>('balance') ?? 0;
  if (balance < amount) throw new Error('Insufficient funds');
  
  await txn.put('balance', balance - amount);
  await txn.put('lastDebit', { amount, time: Date.now() });
});

// List keys with prefix
const entries = await this.state.storage.list({ prefix: 'session:' });

// Delete a range
await this.state.storage.deleteAll(); // Use carefully

Storage limits to know: each object can hold up to 128 KB per value, and the total storage per object isn’t capped in the pricing documentation (you pay per GB stored). Individual operations have a 1 MB payload limit.

The Alarm API: Scheduled Work per Object

Each Durable Object can schedule a future callback via the alarm API. This is useful for cleanup tasks, expiry logic, and delayed processing:

export class SessionManager implements DurableObject {
  constructor(private state: DurableObjectState, env: Env) {}

  async fetch(request: Request): Promise<Response> {
    // Create a session that expires in 24 hours
    const sessionId = crypto.randomUUID();
    await this.state.storage.put(`session:${sessionId}`, {
      created: Date.now(),
      data: await request.json(),
    });

    // Schedule cleanup
    const alarm = await this.state.storage.getAlarm();
    if (!alarm) {
      await this.state.storage.setAlarm(Date.now() + 86_400_000); // 24h
    }

    return Response.json({ sessionId });
  }

  async alarm(): Promise<void> {
    // Called by Cloudflare when the alarm fires
    const cutoff = Date.now() - 86_400_000;
    const sessions = await this.state.storage.list({ prefix: 'session:' });

    const toDelete: string[] = [];
    for (const [key, value] of sessions) {
      if ((value as { created: number }).created < cutoff) {
        toDelete.push(key);
      }
    }

    if (toDelete.length > 0) {
      await this.state.storage.delete(toDelete);
    }

    // Reschedule if there are still active sessions
    const remaining = await this.state.storage.list({ prefix: 'session:' });
    if (remaining.size > 0) {
      await this.state.storage.setAlarm(Date.now() + 3_600_000); // check again in 1h
    }
  }
}

When Not to Use Durable Objects

Durable Objects fit a specific niche. They’re not a general-purpose database replacement.

Skip Durable Objects when:

You need to query across many objects. Each DO only knows its own state. Cross-object queries don’t exist; you’d need a separate index layer.
Your state is read-heavy with infrequent writes. KV with its caching is cheaper and faster for that pattern.
You need full SQL queries, joins, or aggregations. Use D1 (Cloudflare’s SQLite) instead.
Object count will be enormous but most objects are inactive. Durable Objects are priced on active usage, but the coordination overhead adds up if you’re waking objects constantly.

Use Durable Objects when:

You need a single authoritative state that multiple clients or Workers might update simultaneously.
You’re building real-time features: collaborative editing, live presence, shared counters, game state.
You need per-tenant rate limiting, per-room coordination, or per-session state without an external service.
You want to avoid an external state layer (Redis, Postgres) just for coordination logic.

The pricing is reasonable for the use cases it fits: $0.20 per million requests, $12.50 per million GB-seconds of CPU time. Most coordination objects use very little CPU and receive bursts of requests. For a chat room with 100 active users sending occasional messages, the cost is negligible.

Where Durable Objects stand out is the operational simplicity. No Redis cluster to manage, no connection pooling, no failover configuration. The object lives wherever Cloudflare decides, migrates as needed, and wakes up when it gets traffic. The coordination complexity that typically requires careful distributed systems work is handled by the platform.

Expo Router in 2026: File-Based Navigation That Makes React Native Feel Modern

Anurag Verma — Sun, 14 Jun 2026 00:00:00 GMT

React Native navigation has always been the part of mobile development that web developers struggle with most. React Navigation works, but it’s explicit: you define a navigator, list the screens, configure transitions, wire up deep linking, and handle the stack state manually. After building a few apps, it becomes manageable. For the first few projects, it’s genuinely confusing.

Expo Router treats navigation like a file system, which is the pattern web developers already know. A file at app/profile/[id].tsx is the screen at /profile/:id. A file at app/(tabs)/home.tsx is a tab screen. Deep links, URL structure, and navigation state follow from the file structure rather than configuration.

This post covers how Expo Router actually works, what the file structure means for navigation, and where the approach still has rough edges.

The Setup

Expo Router is part of the Expo ecosystem and works with the managed workflow (Expo Go, EAS Build) or bare React Native projects:

npx create-expo-app@latest my-app --template tabs
cd my-app
npm install
npx expo start

The tabs template starts you with a working tab navigation setup. The project structure looks like:

app/
  (tabs)/
    _layout.tsx    — defines the tab bar
    index.tsx      — first tab (Home)
    explore.tsx    — second tab
  _layout.tsx      — root layout, wraps everything
  +not-found.tsx   — 404 screen
assets/
components/
constants/

Every file inside app/ that exports a default React component becomes a navigable screen. The file path is the route.

File Conventions

Expo Router uses a few special filename patterns:

_layout.tsx — defines a layout that wraps all screens in the same directory. Use this for tab bars, drawer navigators, stack headers, and shared providers.

(group)/ — parenthesized folder names create route groups. The group name doesn’t appear in the URL. (tabs)/home.tsx maps to /home, not /(tabs)/home.

[param].tsx — dynamic segments. app/users/[id].tsx matches /users/123, /users/abc, etc.

[...rest].tsx — catch-all segments. app/docs/[...path].tsx matches /docs/getting-started, /docs/api/components, etc.

+not-found.tsx — shown when no other route matches.

+html.tsx — for web-specific HTML customization (Expo Router supports web targets).

Building a Tabbed App

Here’s a complete tab layout with two tabs:

// app/(tabs)/_layout.tsx
import { Tabs } from 'expo-router';
import { Ionicons } from '@expo/vector-icons';

export default function TabLayout() {
  return (
    <Tabs
      screenOptions={{
        tabBarActiveTintColor: '#007AFF',
        headerShown: false,
      }}
    >
      <Tabs.Screen
        name="index"
        options={{
          title: 'Home',
          tabBarIcon: ({ color, size }) => (
            <Ionicons name="home" color={color} size={size} />
          ),
        }}
      />
      <Tabs.Screen
        name="profile"
        options={{
          title: 'Profile',
          tabBarIcon: ({ color, size }) => (
            <Ionicons name="person" color={color} size={size} />
          ),
        }}
      />
    </Tabs>
  );
}

// app/(tabs)/index.tsx
import { View, Text, Pressable } from 'react-native';
import { Link } from 'expo-router';

export default function HomeScreen() {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text>Home</Text>
      {/* Link component works like <a> on the web */}
      <Link href="/users/123" asChild>
        <Pressable>
          <Text>Go to User 123</Text>
        </Pressable>
      </Link>
    </View>
  );
}

The Link component handles navigation without needing access to a navigation object. Same API as Next.js’s Link.

Dynamic Routes and Params

// app/users/[id].tsx
import { View, Text } from 'react-native';
import { useLocalSearchParams } from 'expo-router';

export default function UserScreen() {
  const { id } = useLocalSearchParams<{ id: string }>();
  
  return (
    <View>
      <Text>User ID: {id}</Text>
    </View>
  );
}

Navigate programmatically using the router object:

import { router } from 'expo-router';

// Navigate to a route
router.push('/users/123');

// Replace (no back stack entry)
router.replace('/login');

// Go back
router.back();

// Navigate with typed params
router.push({ pathname: '/users/[id]', params: { id: '123' } });

The typed version catches typos at build time if you use TypeScript with Expo Router’s generated types. Run npx expo-env to generate types for your route structure.

Nested Layouts: Stack Inside a Tab

A common pattern is a tab bar with multiple screens per tab (a stack inside each tab). Here’s how that nests:

app/
  (tabs)/
    _layout.tsx           — tab navigator
    (home)/
      _layout.tsx         — stack navigator inside "home" tab
      index.tsx           — home feed
      post/[id].tsx       — individual post detail
    profile.tsx           — profile tab (no nested stack)

// app/(tabs)/(home)/_layout.tsx
import { Stack } from 'expo-router';

export default function HomeStackLayout() {
  return (
    <Stack>
      <Stack.Screen name="index" options={{ title: 'Feed' }} />
      <Stack.Screen name="post/[id]" options={{ title: 'Post' }} />
    </Stack>
  );
}

Now tapping “Back” from the post detail screen returns to the feed, and the tab bar stays visible throughout. The nesting handles the state automatically.

Authentication Gates

A common need: redirect unauthenticated users to a login screen. Expo Router handles this with a root layout and conditional rendering:

// app/_layout.tsx
import { useEffect } from 'react';
import { Stack, useRouter, useSegments } from 'expo-router';
import { useAuth } from '../hooks/useAuth';

export default function RootLayout() {
  const { user, isLoading } = useAuth();
  const router = useRouter();
  const segments = useSegments();

  useEffect(() => {
    if (isLoading) return;
    
    const inAuthGroup = segments[0] === '(auth)';

    if (!user && !inAuthGroup) {
      // Not signed in, redirect to login
      router.replace('/(auth)/login');
    } else if (user && inAuthGroup) {
      // Signed in, redirect to app
      router.replace('/(tabs)');
    }
  }, [user, isLoading, segments]);

  return (
    <Stack>
      <Stack.Screen name="(tabs)" options={{ headerShown: false }} />
      <Stack.Screen name="(auth)" options={{ headerShown: false }} />
    </Stack>
  );
}

app/
  _layout.tsx           — root: handles auth redirect
  (tabs)/               — protected screens
    _layout.tsx
    index.tsx
  (auth)/               — public screens
    _layout.tsx
    login.tsx
    signup.tsx

The useSegments() hook gives you the current route path as an array of segments, which you use to determine which group the user is in.

Deep Linking Without Configuration

One of Expo Router’s genuine advantages over manual React Navigation setup is deep linking. In React Navigation, you write a linking config object that maps URL patterns to screen names. It’s tedious for anything more than a few screens.

With Expo Router, deep links work automatically because the URL structure is the file structure. Configure the scheme in app.json:

{
  "expo": {
    "scheme": "myapp"
  }
}

Then myapp://users/123 opens the app/users/[id].tsx screen with id="123". Universal links (HTTPS URLs that open the app) require an associated domain setup, but the routing configuration is already done.

For web targets (npx expo start --web), the same routes work as real URLs. The same app file renders in the browser with proper URL structure.

What’s Still Rough

Expo Router is genuinely useful, but there are places where the abstraction leaks.

Complex navigation flows are harder to trace. When navigation logic is spread across _layout.tsx files and useEffect hooks, debugging “why is the app navigating to X” requires tracing through multiple files. React Navigation’s explicit configuration is verbose but centralized.

Typed routes have caveats. The generated expo-env types help, but route parameters passed via useLocalSearchParams are always strings. A param like id=123 gives you "123", not 123. This bites TypeScript users who forget to parse.

Modals and sheets. Presenting a modal (a screen that slides up, has its own header, can be dismissed) works via presentation: 'modal' in screen options, but the interactions with the routing state can feel awkward when you want modal-like navigation that doesn’t add to the URL.

Performance on deep stacks. Expo Router renders all screens in a navigator at startup (for performance), which means complex apps need to be thoughtful about heavy initialization in screen components.

Expo Router is built on React Navigation. They’re not alternatives in the sense that one replaces the other; Expo Router is an opinionated layer on top that handles routing configuration automatically.

	React Navigation	Expo Router
Config style	Explicit navigator + screen definitions	File system
Deep linking	Manual linking config	Automatic from file structure
Web support	Limited (community packages)	First-class
Universal links	Separate config	Same routing, scheme config in app.json
Escape hatches	Full API access	Full React Navigation API underneath
Best for	Complex app-specific navigation flows	Standard app structures, universal apps

If your app has unusual navigation requirements (non-linear flows, branching onboarding, game-like navigation), React Navigation’s explicit API gives you more control. If you’re building a standard app (tabs, stacks, modals) or want native + web from the same codebase, Expo Router’s defaults get you there faster.

Expo Router and React Navigation coexist. You can migrate one section of your app at a time by adopting Expo Router for new screens while keeping existing React Navigation code intact. The Expo Router documentation has a migration guide, but the short version:

Add Expo Router to your project
Move new screens into the app/ directory with Expo Router structure
Keep existing React Navigation navigators for parts you haven’t migrated
Gradually move existing screens into app/ as you touch them

It’s not a weekend migration for a large app, but the incremental path is real.

For new projects in 2026, Expo Router is the default unless you have specific reasons to go with raw React Navigation. The conventions it provides are the same ones web developers already know, and the deep linking and web support you’d otherwise configure manually comes for free.

Fastify in 2026: The Node.js API Framework That Stayed When Everyone Left

Anurag Verma — Sun, 14 Jun 2026 00:00:00 GMT

The JavaScript backend ecosystem has fragmented a lot in the last two years. Bun ships its own web framework. Deno has its own standard library. Edge runtimes run Workers, not Node.js. Meanwhile, the question of “what do I use for a production Node.js API?” has a quieter, less hyped answer: Fastify.

Fastify isn’t new. It launched in 2016. But it’s been compounding improvements methodically, and in 2026 it handles a genuinely compelling combination: performance close to the theoretical Node.js ceiling, a schema-based validation system that generates OpenAPI docs automatically, a plugin architecture that scales from a single file to a hundred-module system, and TypeScript support that actually works without ceremony.

This isn’t an argument that Fastify beats Hono or Bun’s built-in server on benchmarks. For edge deployments or maximum raw throughput, those tools have their place. This is about building a maintainable, well-documented API that runs on Node.js and needs to serve production traffic for years.

The Basics

Install and the simplest possible server:

import Fastify from 'fastify'

const fastify = Fastify({ logger: true })

fastify.get('/health', async () => {
  return { status: 'ok', time: new Date().toISOString() }
})

await fastify.listen({ port: 3000, host: '0.0.0.0' })

That’s it. No separate listen callback, no req/res ceremony. Routes return values or promises, and Fastify serializes them.

Schema Validation

The biggest practical difference from Express is schema-first route definitions. You define the shape of request and response, and Fastify validates incoming requests and serializes responses using fast-json-stringify (which pre-compiles JSON serialization for each schema, typically 2-5x faster than JSON.stringify).

import Fastify, { FastifyRequest, FastifyReply } from 'fastify'

const fastify = Fastify()

// Define schema shapes inline using JSON Schema
const createUserSchema = {
  body: {
    type: 'object',
    required: ['email', 'name'],
    properties: {
      email: { type: 'string', format: 'email' },
      name: { type: 'string', minLength: 1, maxLength: 100 },
      role: { type: 'string', enum: ['admin', 'member', 'viewer'], default: 'member' },
    },
    additionalProperties: false,
  },
  response: {
    201: {
      type: 'object',
      properties: {
        id: { type: 'string', format: 'uuid' },
        email: { type: 'string' },
        name: { type: 'string' },
        role: { type: 'string' },
        createdAt: { type: 'string', format: 'date-time' },
      },
    },
  },
} as const

fastify.post(
  '/users',
  { schema: createUserSchema },
  async (req: FastifyRequest<{ Body: { email: string; name: string; role?: string } }>, reply: FastifyReply) => {
    const { email, name, role = 'member' } = req.body

    // req.body is already validated — email is a valid email, name is within length limits
    const user = await db.users.create({ email, name, role })
    reply.status(201)
    return user
  }
)

Invalid requests (missing required fields, wrong types, values outside enum) get a 400 response with a structured error automatically. No validation middleware to write.

The response schema does double duty: it strips any fields not listed in the schema (preventing accidental data leaks) and enables fast serialization.

TypeBox for TypeScript Integration

Writing JSON Schema by hand gets tedious in TypeScript. TypeBox generates JSON Schema from TypeScript types:

import { Type, Static } from '@sinclair/typebox'
import Fastify, { FastifyRequest } from 'fastify'
import { TypeBoxTypeProvider } from '@fastify/type-provider-typebox'

const fastify = Fastify().withTypeProvider<TypeBoxTypeProvider>()

const CreateProductBody = Type.Object({
  name: Type.String({ minLength: 1, maxLength: 200 }),
  price: Type.Number({ minimum: 0 }),
  sku: Type.String({ pattern: '^[A-Z]{3}-\\d{4}$' }),
  categoryId: Type.Optional(Type.String({ format: 'uuid' })),
})

const ProductResponse = Type.Object({
  id: Type.String({ format: 'uuid' }),
  name: Type.String(),
  price: Type.Number(),
  sku: Type.String(),
  createdAt: Type.String({ format: 'date-time' }),
})

fastify.post(
  '/products',
  {
    schema: {
      body: CreateProductBody,
      response: { 201: ProductResponse },
    },
  },
  async (req) => {
    // req.body is typed as Static<typeof CreateProductBody>
    // TypeScript knows the shape without extra type assertions
    const { name, price, sku, categoryId } = req.body
    const product = await db.products.create({ name, price, sku, categoryId })
    return product
  }
)

With TypeBoxTypeProvider, TypeScript infers request body types directly from your schema. No separate interface declarations, no casting.

The Plugin System

Fastify’s plugin system is where it scales beyond a single file. Plugins are functions that extend the Fastify instance with routes, decorators, and hooks, with scope isolation.

A typical structure for a medium-sized API:

src/
  server.ts          — creates and configures the Fastify instance
  plugins/
    db.ts            — database connection, registers env.db on fastify instance  
    auth.ts          — registers preHandler hook for JWT verification
    swagger.ts       — registers @fastify/swagger for OpenAPI docs
  routes/
    users/
      index.ts       — registers user routes
      schema.ts      — TypeBox schemas for user routes
    products/
      index.ts
      schema.ts

// src/plugins/db.ts
import fp from 'fastify-plugin'
import { drizzle } from 'drizzle-orm/node-postgres'

declare module 'fastify' {
  interface FastifyInstance {
    db: ReturnType<typeof drizzle>
  }
}

export default fp(async (fastify) => {
  const db = drizzle(process.env.DATABASE_URL!)
  fastify.decorate('db', db)
})

// src/routes/users/index.ts
import { FastifyInstance } from 'fastify'
import { CreateUserBody, UserResponse } from './schema'

export default async function userRoutes(fastify: FastifyInstance) {
  fastify.post('/', {
    schema: { body: CreateUserBody, response: { 201: UserResponse } },
  }, async (req) => {
    return fastify.db.insert(users).values(req.body).returning()
  })

  fastify.get('/:id', {
    schema: {
      params: Type.Object({ id: Type.String({ format: 'uuid' }) }),
      response: { 200: UserResponse },
    },
  }, async (req) => {
    return fastify.db.query.users.findFirst({
      where: eq(users.id, req.params.id)
    })
  })
}

// src/server.ts
import Fastify from 'fastify'
import dbPlugin from './plugins/db'
import authPlugin from './plugins/auth'
import userRoutes from './routes/users'
import productRoutes from './routes/products'

const fastify = Fastify({ logger: { level: process.env.LOG_LEVEL ?? 'info' } })

await fastify.register(dbPlugin)
await fastify.register(authPlugin)

// Route prefix scoping
await fastify.register(userRoutes, { prefix: '/users' })
await fastify.register(productRoutes, { prefix: '/products' })

export default fastify

The fastify-plugin wrapper (fp) breaks scope isolation deliberately. It makes the database decorator available to all routes. Routes registered with fastify.register() without fp get an isolated scope: decorators registered inside that scope don’t leak out.

Auto-Generated OpenAPI Docs

Add @fastify/swagger and @fastify/swagger-ui:

import swagger from '@fastify/swagger'
import swaggerUI from '@fastify/swagger-ui'

await fastify.register(swagger, {
  openapi: {
    info: { title: 'My API', version: '1.0.0' },
    components: {
      securitySchemes: {
        bearerAuth: { type: 'http', scheme: 'bearer', bearerFormat: 'JWT' },
      },
    },
  },
})

await fastify.register(swaggerUI, {
  routePrefix: '/docs',
  uiConfig: { deepLinking: true },
})

Every route with a schema definition shows up in /docs automatically. The OpenAPI spec is generated at runtime from the same TypeBox schemas that validate your requests. No separate spec file to maintain.

Hooks

Fastify’s hook system gives you lifecycle points without middleware stacks:

// Run before every route handler — authentication check
fastify.addHook('preHandler', async (request, reply) => {
  const auth = request.headers.authorization
  if (!auth?.startsWith('Bearer ')) {
    reply.status(401).send({ error: 'Missing token' })
    return
  }
  try {
    request.user = await verifyToken(auth.slice(7))
  } catch {
    reply.status(401).send({ error: 'Invalid token' })
  }
})

// Run after response is sent — logging, cleanup
fastify.addHook('onSend', async (request, reply, payload) => {
  fastify.log.info({
    method: request.method,
    url: request.url,
    statusCode: reply.statusCode,
    responseTime: reply.elapsedTime,
  })
  return payload // Must return payload
})

The hook chain is explicit and ordered. You know exactly when each hook runs relative to route handlers.

Error Handling

Fastify’s error model separates framework errors from application errors cleanly:

// Custom error class
class AppError extends Error {
  constructor(
    public statusCode: number,
    message: string,
    public code?: string
  ) {
    super(message)
  }
}

// Global error handler
fastify.setErrorHandler((error, request, reply) => {
  if (error instanceof AppError) {
    reply.status(error.statusCode).send({
      error: error.message,
      code: error.code,
    })
    return
  }

  // Fastify validation errors
  if (error.validation) {
    reply.status(400).send({
      error: 'Validation failed',
      details: error.validation,
    })
    return
  }

  // Unexpected errors
  fastify.log.error(error)
  reply.status(500).send({ error: 'Internal server error' })
})

Choosing Between Fastify, Hono, and NestJS

These three cover most production Node.js (and beyond) use cases in 2026:

	Fastify	Hono	NestJS
Runtime	Node.js primarily	Any (Bun, Deno, Workers)	Node.js
Schema validation	JSON Schema / TypeBox	Zod / Valibot	class-validator
Learning curve	Low-medium	Low	High
Boilerplate	Low	Very low	High
Plugin ecosystem	Mature	Growing	Mature
OpenAPI generation	Built-in	Add-on	Add-on
Best for	Node.js APIs needing performance	Edge deployments, multi-runtime	Enterprise apps with Spring-like patterns

Fastify wins when you’re committed to Node.js, want automatic OpenAPI generation, and need a mature plugin ecosystem. Hono wins when you might deploy to Workers or Bun and want maximum portability. NestJS wins when your team comes from a Java/Spring background and wants decorators and dependency injection.

Deploying

Fastify runs anywhere Node.js runs. One note: the listen call should bind to 0.0.0.0 in containers, not 127.0.0.1:

await fastify.listen({ port: Number(process.env.PORT ?? 3000), host: '0.0.0.0' })

For graceful shutdown in Kubernetes or similar:

const shutdown = async (signal: string) => {
  fastify.log.info(`Received ${signal}, shutting down`)
  await fastify.close()
  process.exit(0)
}

process.on('SIGTERM', () => shutdown('SIGTERM'))
process.on('SIGINT', () => shutdown('SIGINT'))

fastify.close() calls the onClose hooks (where you’d close database connections) and waits for in-flight requests to complete before returning.

The case for Fastify in 2026 isn’t novelty. It’s reliability. The schema-first design catches bugs at the boundary, the OpenAPI generation keeps documentation honest, and the plugin system keeps complexity manageable as projects grow. It’s not flashy, but it’s a tool that keeps working.

Phoenix LiveView: Real-Time Web Features Without Writing a Line of JavaScript

Anurag Verma — Sun, 14 Jun 2026 00:00:00 GMT

Most real-time web features follow the same pattern: a React frontend, a WebSocket server, some state management library, and a lot of code synchronizing what the server knows with what the browser shows. It works, but there’s a lot of surface area: two runtimes, two state models, coordination logic.

Phoenix LiveView takes a different path. The server renders HTML, sends it over a persistent WebSocket connection, and patches the DOM when state changes. You write Elixir on the server, and the browser handles the DOM diffing. For the right use cases, it cuts the complexity down significantly.

This post is for developers already comfortable with React or another frontend framework who want to understand what the LiveView model offers and where it falls short.

What Elixir and Phoenix Are

Before LiveView, a quick orientation:

Elixir is a functional language built on the Erlang VM (BEAM). It inherits Erlang’s concurrency model: lightweight processes, message passing, and fault tolerance built into the runtime. A typical Elixir application runs millions of processes concurrently. Each process has its own memory and fails independently. One process crash doesn’t bring down others.

Phoenix is Elixir’s web framework. It’s fast (handling hundreds of thousands of WebSocket connections per server is routine), and it uses channels as the abstraction for persistent connections. LiveView is built on top of Phoenix Channels.

The LiveView Model

When a user loads a LiveView page, this happens:

The server renders the initial HTML and sends it in the HTTP response (fast first paint, crawlable content).
The page loads a small JavaScript client (~50KB) that opens a WebSocket back to the server.
The server keeps a process alive for this connection. This process holds the UI state.
When state changes (user clicks a button, a database record updates, a timer fires), the server re-renders just the changed parts and sends a minimal diff to the client.
The JavaScript client applies the diff to the DOM.

From the developer’s perspective, you write one template and one Elixir module. The framework handles the WebSocket, the diffing, and the DOM updates.

# lib/my_app_web/live/counter_live.ex
defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0)}
  end

  def handle_event("increment", _params, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end

  def handle_event("decrement", _params, socket) do
    {:noreply, update(socket, :count, &(&1 - 1))}
  end

  def render(assigns) do
    ~H"""
    <div class="counter">
      <button phx-click="decrement">-</button>
      <span class="value"><%= @count %></span>
      <button phx-click="increment">+</button>
    </div>
    """
  end
end

The phx-click attribute tells LiveView to send the "increment" event to the server when clicked. The server handles it, updates the socket state, and the framework sends a diff back. No JavaScript written.

A Live Search Example

A more practical case: a search input that filters results in real-time as the user types.

defmodule MyAppWeb.SearchLive do
  use MyAppWeb, :live_view
  alias MyApp.Products

  def mount(_params, _session, socket) do
    {:ok, assign(socket, query: "", results: [], loading: false)}
  end

  def handle_event("search", %{"query" => query}, socket) do
    socket = assign(socket, query: query, loading: true)
    # In a real app, use Task.async or Phoenix.PubSub for async search
    results = Products.search(query)
    {:noreply, assign(socket, results: results, loading: false)}
  end

  def render(assigns) do
    ~H"""
    <div>
      <input
        type="text"
        value={@query}
        phx-input="search"
        phx-debounce="300"
        placeholder="Search products..."
      />

      <%= if @loading do %>
        <div class="spinner" />
      <% else %>
        <ul>
          <%= for product <- @results do %>
            <li>
              <strong><%= product.name %></strong>
              <span><%= product.price %></span>
            </li>
          <% end %>
        </ul>
      <% end %>
    </div>
    """
  end
end

The phx-debounce="300" attribute delays sending the event until the user stops typing for 300ms. The debouncing is handled client-side by the LiveView JavaScript library. No custom debounce code.

Real-Time Updates via PubSub

LiveView integrates tightly with Phoenix PubSub. When a record changes anywhere in the system (another user’s action, a background job, an external event), you can push the update to all subscribers:

defmodule MyAppWeb.OrdersLive do
  use MyAppWeb, :live_view
  alias MyApp.Orders
  alias Phoenix.PubSub

  def mount(_params, %{"user_id" => user_id}, socket) do
    if connected?(socket) do
      # Only subscribe after the WebSocket is open (not during HTTP render)
      PubSub.subscribe(MyApp.PubSub, "orders:#{user_id}")
    end

    orders = Orders.list_for_user(user_id)
    {:ok, assign(socket, orders: orders, user_id: user_id)}
  end

  # Called when a PubSub message arrives
  def handle_info({:order_updated, order}, socket) do
    updated_orders =
      socket.assigns.orders
      |> Enum.map(fn o -> if o.id == order.id, do: order, else: o end)

    {:noreply, assign(socket, orders: updated_orders)}
  end

  def render(assigns) do
    ~H"""
    <table>
      <tbody>
        <%= for order <- @orders do %>
          <tr id={"order-#{order.id}"}>
            <td><%= order.id %></td>
            <td><%= order.status %></td>
            <td><%= order.total %></td>
          </tr>
        <% end %>
      </tbody>
    </table>
    """
  end
end

When a background job updates an order status and broadcasts to "orders:user_123", every LiveView connected for that user gets the update and re-renders the row. The browser sees a targeted DOM patch, not a full page reload.

Forms and Validation

LiveView has built-in form handling that gives you live validation feedback without submitting the form:

defmodule MyAppWeb.RegistrationLive do
  use MyAppWeb, :live_view
  alias MyApp.Accounts
  alias MyApp.Accounts.User

  def mount(_params, _session, socket) do
    changeset = Accounts.change_user(%User{})
    {:ok, assign(socket, form: to_form(changeset))}
  end

  def handle_event("validate", %{"user" => params}, socket) do
    changeset =
      %User{}
      |> Accounts.change_user(params)
      |> Map.put(:action, :validate)

    {:noreply, assign(socket, form: to_form(changeset))}
  end

  def handle_event("save", %{"user" => params}, socket) do
    case Accounts.create_user(params) do
      {:ok, _user} ->
        {:noreply, push_navigate(socket, to: "/dashboard")}

      {:error, changeset} ->
        {:noreply, assign(socket, form: to_form(changeset))}
    end
  end

  def render(assigns) do
    ~H"""
    <.form for={@form} phx-change="validate" phx-submit="save">
      <.input field={@form[:email]} type="email" label="Email" />
      <.input field={@form[:password]} type="password" label="Password" />
      <.button type="submit">Create account</.button>
    </.form>
    """
  end
end

phx-change="validate" sends the form values to the server on every change. The server runs the changeset validation and sends back the errors. The form shows inline error messages as the user types. No client-side validation code, no synchronization between client and server validation rules.

What LiveView Gives Up Compared to React

LiveView is compelling for the use cases it fits, but the tradeoffs are real.

Network round-trip on every interaction. Every click, input, and event goes to the server. If the user is on a slow connection, interactions feel sluggish. React can handle most interactions offline and sync later.

JavaScript ecosystem access is limited. You can add JavaScript hooks for things LiveView can’t do (rich text editors, file uploads with previews, canvas drawing), but you’re working against the grain. A complex drag-and-drop or animation-heavy interface is genuinely harder in LiveView.

Server resources per connection. Each connected LiveView is a running Elixir process. The BEAM handles millions of processes, so this isn’t a concern in most cases, but it’s a different mental model from stateless HTTP endpoints.

Smaller ecosystem. Phoenix and Elixir have good libraries, but they’re a fraction of what the Node.js ecosystem offers. If you need a specific third-party integration, you’ll check if an Elixir library exists before choosing LiveView.

Learning curve. Elixir’s functional style, pattern matching, and process model take a few weeks to get comfortable with if you’re coming from JavaScript.

Where LiveView Wins

Admin interfaces and internal tools. Data tables, form editing, real-time dashboards. These don’t need the full power of React and benefit from LiveView’s simplicity.

SaaS dashboards with real-time data. Order status pages, analytics views, notification feeds. LiveView’s PubSub integration makes these straightforward.

Collaborative features. Shared whiteboards, multi-user forms, live presence indicators. The process model maps naturally to “who is connected and what are they doing.”

Teams with Elixir expertise. If your backend team already knows Elixir, adding LiveView means one language instead of two. That’s a significant advantage for small teams.

HTMX vs LiveView

Both approaches use server-rendered HTML updates instead of a JavaScript SPA, but they’re meaningfully different.

HTMX is a JavaScript library you add to existing HTML. It works with any backend: Rails, Django, FastAPI. It enhances specific elements with dynamic behavior via attributes. It’s simpler and easier to adopt incrementally.

LiveView is a framework with its own opinions about state management and process lifecycle. It’s more opinionated and more capable for complex real-time scenarios. The persistent connection and server-side process model enable patterns that HTMX can’t do cleanly.

If you have an existing Ruby or Python backend, HTMX is the more practical path. If you’re starting fresh and want real-time-first, LiveView with Elixir is worth evaluating seriously.

Getting Started

The quickest way to try it:

# Install Elixir (macOS)
brew install elixir

# Install Phoenix project generator
mix archive.install hex phx_new

# Create a new project with LiveView
mix phx.new my_app --live

cd my_app
mix deps.get
mix ecto.create
mix ecto.migrate
mix phx.server

Visit http://localhost:4000 and you’ll see the default Phoenix welcome page. The generated app includes a LiveView counter at /dev/dashboard you can inspect.

The Phoenix documentation is genuinely excellent. The LiveView guides walk through the programming model clearly. The official HexDocs for Phoenix.LiveView are worth reading even before you start a project, just to understand what the framework handles for you and what you’re responsible for.

For teams evaluating it: build a small internal tool before committing to LiveView for a customer-facing product. The model clicks after a couple of days of hands-on work in a way it doesn’t from reading about it.

Turning Agency Work Into Products: The IP Playbook

Anurag Verma — Sat, 13 Jun 2026 00:00:00 GMT

After a few years of client work, most agencies have built the same thing four or five times. A multi-tenant authentication system. A CMS integration layer. A notification pipeline. An e-commerce checkout that’s actually been tested in production. Each time, it gets rebuilt from scratch or copied between projects in ways that create maintenance headaches.

The code exists. The patterns exist. The lesson learned from the thing that broke in production on project three exists. The question is whether any of it becomes a business asset or just stays in a folder labeled “old client projects.”

Productization is the process of taking repeatable agency work and packaging it as something with standalone value: a SaaS tool, an internal library, a starter template, a productized service, a plugin. Done well, it creates recurring revenue from work you’ve already done. Done poorly, it creates a distraction that competes with your core client work.

Here’s how to tell the difference.

What’s Worth Extracting

Not everything that gets rebuilt deserves productization. The signal to look for is a combination of:

High rebuild frequency. If you’ve built the same pattern three or more times in the past two years, you’ll build it again. That’s your supply side.

Client willingness to pay separately. If clients treat this component as a cost center (“just wire up the auth”), it probably won’t support product pricing. If they’ve ever asked “can we get the same thing you built for client X?” you have demand-side signal.

Low client-specific customization. The more a piece of work is shaped by one client’s specific business rules, the harder it is to generalize. Multi-tenancy patterns are highly generalizable. A custom workflow for one company’s approval process is not.

Maintenance surface you control. You can productize internal tooling that you update when you want. You should not productize something where a single client’s changing requirements drive the roadmap.

The highest-value candidates are usually:

Authentication and user management patterns (every web project needs them)
CMS integration layers (especially when a client reuses the same headless CMS)
Notification systems (email + SMS + push with unified delivery tracking)
Admin panel scaffolding (generic enough to be useful, specific enough to save meaningful time)
Internal tooling for your team’s own operations (billing integrations, client portals, project trackers)

The Four Models of Agency Productization

Once you’ve identified a candidate, you have four packaging options with different economics:

1. Starter Templates

The lowest-investment option. You extract a project scaffold into a template repository and sell it once. Pricing is typically one-time: $200-1500 for a complete project starter. Revenue scales with distribution, not with your time.

Good candidates: full-stack starters with a specific tech combination (Next.js + Supabase + Stripe + Resend), Figma component libraries with real component sets, CI/CD pipeline configurations.

The margin is high but revenue is lumpy. Templates work well as lead generation for your agency (buyers become potential clients) or as passive income supplements.

2. Internal Libraries

You package a reusable component or service as an internal library that your team uses across all projects. This isn’t sold externally — it’s an investment in internal efficiency.

The ROI calculation is straightforward: if the library saves 20 hours per project and you run 8 projects per year, that’s 160 hours saved at your billing rate. At $150/hour, that’s $24,000 in recovered capacity annually from a one-time investment.

Internal libraries often become the most valuable agency IP because they compound. Each improvement benefits all future projects.

3. Productized Services

You package a scope of work as a fixed-price, fixed-deliverable service with a well-defined process. The “product” here is the process and the output, not software.

Examples: a three-week performance audit at $4,500, a four-day security review, a two-week AI feature integration package. The value is in the repeatable process that lets you deliver predictably and at lower cost than custom-scoped work.

Productized services are the fastest to market. There’s no software to build. You’re packaging existing expertise into a named offering with a clear outcome. Revenue starts on day one.

4. SaaS Tools

The highest-complexity, highest-ceiling option. You build something client-adjacent that small businesses or other agencies would pay for monthly.

This is the path most agency founders want to take, and the one that most frequently fails. SaaS requires a different discipline from client work: building in public, managing support volume, shipping to an opinionated general audience instead of a single client with known requirements.

Before building a SaaS, ask honestly: are you solving a problem for the market, or building the tool you wish you’d had on your last project? The second is a product you’ll understand deeply. The first is the one other people will pay for. Often these are the same thing, but verify before you build.

The Extraction Process

Once you’ve picked a candidate and a model, the extraction process follows the same steps regardless:

Document the current state. Write down what the existing code does, where the client-specific parts are, and what would need to change to make it general. This takes 2-4 hours and will surface most of the generalization problems before you’ve written any new code.

Define the interface, not the implementation. For a library or template, start with the API surface — what does a consumer of this thing see and interact with? Get the interface right before building the internals. Interface mistakes are expensive to fix after launch.

Separate the general from the specific. Client-specific business logic goes out. Configuration surfaces come in. A notification system that’s hardcoded to one client’s Postmark account becomes a notification system that accepts provider configuration.

Write the integration guide before the code. Writing the README before the implementation forces you to think about the developer experience from the outside. If the integration guide is confusing to write, the API is confusing to use.

Time-box the build. A template should take one week to extract and polish. A library, two to four weeks. A productized service, a few days of documentation and process mapping. A SaaS product requires a separate business plan, not a time-box.

Pricing Productized Work

Productized work is priced on value, not on time. The buyer doesn’t care how long the template took to build — they care what it would cost to build the equivalent themselves.

A Next.js + Stripe + Supabase starter that includes production-ready auth, billing, and email infrastructure saves a competent developer 30-50 hours. At a senior developer’s rate of $150/hour, that’s $4,500-7,500 of value. Pricing it at $200-500 is reasonable for a template; pricing it at $1,000-2,000 for an agency-quality implementation with support is also defensible.

For productized services, anchor to the outcome rather than the input. “Security audit” is less compelling than “a report that tells you exactly which vulnerabilities would fail a client’s compliance review and how to fix them before it becomes your problem.”

The Realistic Timeline

Productization is a parallel investment, not a replacement for client work. The realistic timeline:

Month 1: Pick one candidate. Document it. Define the interface.
Month 2-3: Build the extracted version. Use it on one internal or client project.
Month 4: Publish and see if anyone buys it without you explaining it.

Most productization efforts stall because agencies try to build something polished before they’ve validated whether anyone wants it. A rough template with clear documentation sells better than a perfect one nobody can find.

The distribution question matters as much as the product. For templates: sell on Gumroad or a personal site, not on marketplaces that commoditize. For productized services: your existing client base is the first market. For SaaS: budget for marketing before you budget for features.

What Not to Productize

A few traps to avoid:

Client work where the IP belongs to them. Check your contracts. Most agency agreements transfer IP to the client on payment. If you want to retain rights to patterns you build, that needs to be in the contract before the work starts, not extracted after.

Things that are only useful with your specific setup. A tool that solves a problem unique to your team’s workflow is useful internally. It’s probably not a product.

Whatever is currently your biggest client bottleneck. Don’t start a productization project with bandwidth that your clients are currently waiting on. The best time to build a product side is when client work is slightly slow, not when you’re already stretched.

The agencies that build durable product revenue start small — one template, one productized service, one internal library — and reinvest the early revenue into the next layer. It compounds slowly and then faster than expected.

The core work is already done. What’s sitting in your project folders?

NATS JetStream in Production: When Kafka Is Too Much

Anurag Verma — Sat, 13 Jun 2026 00:00:00 GMT

Kafka is the default answer for message queuing at scale. But for teams running fewer than a million messages per day, NATS JetStream offers persistence, delivery guarantees, and a dramatically simpler operational footprint.

Prometheus and Grafana: Production Monitoring Without the Complexity Tax

Anurag Verma — Sat, 13 Jun 2026 00:00:00 GMT

A practical guide to setting up metrics collection with Prometheus and visualization with Grafana for backend services — what to instrument, what to skip, and what the dashboards should actually show.

Python asyncio in Production: The Pitfalls No One Warns You About

Anurag Verma — Sat, 13 Jun 2026 00:00:00 GMT

async/await syntax makes Python code look concurrent. The behavior when you get it wrong is harder to predict than most tutorials explain. Here's what breaks in production and how to fix it before it does.

Pydantic v2: The Data Validation Layer Your Python APIs Actually Need

Anurag Verma — Sat, 13 Jun 2026 00:00:00 GMT

Pydantic v2 shipped with a Rust-based core that made validation 5-50x faster. But the performance is only part of it — the v2 model redesign changes how you structure validation logic for complex APIs.

Agency Operations: Building Systems That Work Without You

Anurag Verma — Fri, 12 Jun 2026 00:00:00 GMT

Most agency owners are the bottleneck in their own business. Here's how to identify where you're needed versus where a system or a person could replace you, and how to build those systems.

Dev Containers: Reproducible Development Environments in 2026

Anurag Verma — Fri, 12 Jun 2026 00:00:00 GMT

Dev Containers let you define your entire development environment in a JSON file. New team members are productive in minutes, not days. Here's how to set them up properly.

OWASP API Security Top 10: A Developer's Field Guide for 2026

Anurag Verma — Fri, 12 Jun 2026 00:00:00 GMT

The OWASP API Security Top 10 lists the most critical API vulnerabilities. Most are fixable with straightforward code changes. This guide walks through each one with real examples.

SolidJS in 2026: Fine-Grained Reactivity Without the Virtual DOM

Anurag Verma — Fri, 12 Jun 2026 00:00:00 GMT

SolidJS is not React with a different syntax. It compiles to real DOM operations, skips the virtual DOM entirely, and has a different mental model for reactivity. Here's what that means in practice.

Three.js and React Three Fiber: 3D on the Web Without the Pain

Anurag Verma — Fri, 12 Jun 2026 00:00:00 GMT

Three.js makes WebGL accessible. React Three Fiber makes Three.js feel like React. Together they're the fastest path to interactive 3D on the web. Here's how to actually use them.

Container Security Scanning in 2026: What Trivy and Snyk Find That Your Pipeline Misses

Anurag Verma — Thu, 11 Jun 2026 00:00:00 GMT

Vulnerability scanning catches known CVEs in your base images and dependencies before they reach production. Here's how to set up Trivy and Snyk, understand their output, and act on what they find.

Docker Image Optimization in 2026: Multi-Stage Builds and the Sizes That Actually Matter

Anurag Verma — Thu, 11 Jun 2026 00:00:00 GMT

A bloated Docker image costs you in pull times, storage fees, and attack surface. Here's how to build images that are small, fast to rebuild, and genuinely production-ready.

TanStack Router in 2026: Type-Safe Routing That Rewires How You Think About Navigation

Anurag Verma — Thu, 11 Jun 2026 00:00:00 GMT

TanStack Router brings full TypeScript inference to URL params, search params, and loader data. Here's what that looks like in practice and when it's worth adopting.

Web Images in 2026: AVIF, WebP, and the LCP Work Nobody Does Until It's a Problem

Anurag Verma — Thu, 11 Jun 2026 00:00:00 GMT

Images are the single biggest factor in Largest Contentful Paint for most sites. AVIF has widespread browser support now. Here's the optimization stack worth using and how to implement it.

XState v5: State Machines for UI That's Too Complex to Wing It

Anurag Verma — Thu, 11 Jun 2026 00:00:00 GMT

XState v5 ships a rewritten API that's smaller, faster, and easier to read than v4. Here's how state machines actually help in production UI, and what the migration looks like.

Sprint Planning for Agency Client Projects: An Honest Adaptation of Agile

Anurag Verma — Wed, 10 Jun 2026 00:00:00 GMT

The standard Scrum playbook was designed for product teams with stable backlogs. Agencies have different constraints: client reviews, scope negotiations, and projects that end. Here's what actually works.

Cursor Rules for Teams: Codifying Your Standards for AI Coding

Anurag Verma — Wed, 10 Jun 2026 00:00:00 GMT

Cursor's rules system lets teams encode their architecture decisions, naming conventions, and coding standards into the AI's context. Here's how to set it up so every engineer gets consistent suggestions.

HTTP Security Headers in 2026: The Checklist That Actually Matters

Anurag Verma — Wed, 10 Jun 2026 00:00:00 GMT

Most web apps are missing four or five headers that would neutralize entire classes of attack. Here's what each header does, what to set, and why most defaults leave you exposed.

LangChain vs LlamaIndex in 2026: Choosing the Right AI Framework

Anurag Verma — Wed, 10 Jun 2026 00:00:00 GMT

Both frameworks can build RAG pipelines and agent systems, but they're designed with different priorities. Here's when to reach for each and when to skip both.

Running LLMs Locally with Ollama: A Practical Guide for Developers

Anurag Verma — Wed, 10 Jun 2026 00:00:00 GMT

Ollama makes it possible to run Llama 3, Mistral, Phi-4, and dozens of other open-weight models on your laptop or server with a single command. Here's what actually works and when local inference makes sense.

Agency SLAs and Support Contracts: What Ongoing Work Actually Looks Like

Anurag Verma — Tue, 09 Jun 2026 00:00:00 GMT

Most agencies figure out support pricing and SLA structure only after a client calls at 11pm. A better approach: define what you're selling before the project launches.

Alpine.js in 2026: Lightweight Interactivity for Server-Rendered Apps

Anurag Verma — Tue, 09 Jun 2026 00:00:00 GMT

Alpine.js lets you add dropdown menus, modals, tabs, and form behavior directly in HTML without a build step or a JavaScript framework. Here's when that's exactly what you want.

Cloudflare R2 vs AWS S3 in 2026: The Storage Decision for Developer Teams

Anurag Verma — Tue, 09 Jun 2026 00:00:00 GMT

R2's zero-egress pricing looks compelling on paper. Here's when it actually saves money, when S3's ecosystem still wins, and how to migrate if you decide to switch.

Deno 2 in Production: What Actually Changed and When to Use It

Anurag Verma — Tue, 09 Jun 2026 00:00:00 GMT

Deno 2 ships with full Node.js compatibility, npm support, and a revised standard library. Here's what that means for teams evaluating it as a serious Node alternative.

Maintenance Pricing for AI-Assisted Projects: What's Different in 2026

Anurag Verma — Tue, 09 Jun 2026 00:00:00 GMT

When AI tools write 40-70% of a codebase, the usual rules for estimating support costs break down. Here's how to price maintenance work when your team didn't write most of the code.

TypeScript Decorators in 2026: The Stabilized Proposal Worth Learning

Anurag Verma — Tue, 09 Jun 2026 00:00:00 GMT

TypeScript 5.0 shipped support for the TC39 Stage 3 decorators proposal. It's different from the old experimentalDecorators, more useful, and now the way to actually write decorators.

Agency Case Studies That Win Work: Structure, Metrics, and What to Leave Out

Anurag Verma — Mon, 08 Jun 2026 00:00:00 GMT

Most agency case studies don't convert because they focus on process and outputs instead of client decisions and outcomes. Here's how to write case studies that do the selling for you.

CSS Cascade Layers in 2026: Fix Specificity Wars Without Fighting the Stylesheet

Anurag Verma — Mon, 08 Jun 2026 00:00:00 GMT

CSS @layer lets you define explicit ordering between your reset, base, components, and utility styles. Here's how cascade layers work and how they simplify stylesheet architecture.

ElysiaJS in 2026: End-to-End Type Safety for Bun APIs Without the Ceremony

Anurag Verma — Mon, 08 Jun 2026 00:00:00 GMT

ElysiaJS gives Bun apps fast routing, request validation, and full type inference between server and client — without code generation. Here's how it works and when to use it.

Error Tracking in 2026: What Sentry Catches That Your Logs Don't

Anurag Verma — Mon, 08 Jun 2026 00:00:00 GMT

Logs tell you what happened. Error tracking tells you what broke, in what context, for which users. Here's how to set up Sentry properly and avoid the alert fatigue that makes it useless.

Vendor Lock-in in 2026: What It Actually Costs and When to Stop Worrying About It

Anurag Verma — Mon, 08 Jun 2026 00:00:00 GMT

The fear of vendor lock-in leads to over-engineering. Here's a practical framework for deciding when to abstract cloud dependencies and when accepting lock-in is the right call.

How Agencies Build Contractor Networks: Adding Capacity Without the Headcount

Anurag Verma — Sun, 07 Jun 2026 00:00:00 GMT

Hiring a full-time developer for a three-month surge then watching them sit idle is one of the most expensive mistakes agencies make. Here's how to build a contractor network that actually works.

ClickHouse in 2026: Analytical Queries on Billions of Rows Without the Pain

Anurag Verma — Sun, 07 Jun 2026 00:00:00 GMT

ClickHouse is a columnar database designed for analytical workloads. It answers queries over billions of rows in seconds that would take minutes in Postgres. Here's what application developers need to know.

dbt in 2026: SQL-First Data Transformation That Actually Scales

Anurag Verma — Sun, 07 Jun 2026 00:00:00 GMT

dbt turns SQL SELECT statements into a tested, documented, version-controlled data pipeline. Here's how it works and when you should add it to your data stack.

Fly.io and Railway in 2026: Deploy Full-Stack Apps Without Becoming a DevOps Team

Anurag Verma — Sun, 07 Jun 2026 00:00:00 GMT

Vercel dominates frontend hosting. AWS dominates enterprise infrastructure. Between those two extremes, Fly.io and Railway are the most practical choices for backend-heavy full-stack apps in 2026.

Zustand and Jotai: React State Management Without the Redux Ceremony

Anurag Verma — Sun, 07 Jun 2026 00:00:00 GMT

Redux is overkill for most React apps. Zustand and Jotai cover 90% of real state management needs with a fraction of the boilerplate. Here's when to use each and how they actually work.

Architecture Decision Records: Lightweight Docs That Survive Team Turnover

Anurag Verma — Sat, 06 Jun 2026 00:00:00 GMT

An Architecture Decision Record captures why a technical choice was made, not just what was decided. One page per decision, stored in the repo, reviewed in PRs. Here's the format and how to make it stick.

ESLint 9 Flat Config: The Migration Guide for Teams Who Have Put It Off

Anurag Verma — Sat, 06 Jun 2026 00:00:00 GMT

ESLint 9 made flat config the default and deprecated the old .eslintrc format. If your project is still on the legacy config, here's what changed, why it's better, and how to migrate without breaking your setup.

Pre-commit Hooks and Automated Code Quality: The Setup That Catches Problems Before CI Does

Anurag Verma — Sat, 06 Jun 2026 00:00:00 GMT

Git hooks enforced by Lefthook, Husky, or lint-staged can stop broken code, style violations, and type errors before they reach your CI pipeline. Here's how to build a hook setup that teams actually keep.

Internationalizing a React App in 2026: react-i18next, next-intl, and Lingui Compared

Anurag Verma — Sat, 06 Jun 2026 00:00:00 GMT

Adding multi-language support to a React app is straightforward when you pick the right library for your setup. Here's how react-i18next, next-intl, and Lingui differ, and which fits each project type.

Why Software Estimates Are Always Wrong (And How to Make Them Less Wrong)

Anurag Verma — Sat, 06 Jun 2026 00:00:00 GMT

Most project estimates fail before a single line of code is written. The problem is almost never the hours. It's the unexamined assumptions buried in them. Here's a more honest estimation process.

Client Handoff Documentation That Gets Read After Launch

Anurag Verma — Fri, 05 Jun 2026 00:00:00 GMT

Most handoff docs end up ignored six months later when a client can't find their CMS login. Here's what to write, how to structure it, and what most agencies skip that causes the most post-launch support calls.

Cloudflare Workers AI: Running Models at the Edge Without a GPU Bill

Anurag Verma — Fri, 05 Jun 2026 00:00:00 GMT

Workers AI gives you access to a catalog of open-weight models — Llama, Mistral, Whisper, embedding models — running in Cloudflare's network. Here's what's actually useful, what the limitations are, and when it makes sense.

Inngest: Background Jobs Without the Queue Infrastructure

Anurag Verma — Fri, 05 Jun 2026 00:00:00 GMT

Most background job solutions require you to run and monitor a Redis instance, manage worker processes, and wire up your own retry logic. Inngest skips all of that. Here's how it works and when it's the right call.

Next.js Auth in 2026: Clerk vs Better Auth vs Auth.js v5

Anurag Verma — Fri, 05 Jun 2026 00:00:00 GMT

Three real authentication options for Next.js apps, with different trade-offs on control, cost, and setup time. Here's what each one actually involves.

Ruby on Rails 8: What the Comeback Looks Like in Production

Anurag Verma — Fri, 05 Jun 2026 00:00:00 GMT

Rails 8 ships Solid Queue, Solid Cache, Solid Cable, and Kamal 2. Together they make it possible to run a production app on one server, without Redis, without a separate Node process, and without external managed services for the basics.

Getting Paid: How Agencies Should Structure Payment Terms

Anurag Verma — Thu, 04 Jun 2026 00:00:00 GMT

The invoice you send is only as good as the terms behind it. Here's how to structure deposits, milestones, and late fees so cash flow stays predictable and overdue invoices become rare.

Bruno: The API Client That Stores Requests in Git

Anurag Verma — Thu, 04 Jun 2026 00:00:00 GMT

Bruno keeps API collections as plain files in your repository. No account, no cloud sync, no vendor lock-in. Here's how it compares to Postman and why teams are switching.

Git Worktrees: Check Out Multiple Branches at Once Without the Stash Dance

Anurag Verma — Thu, 04 Jun 2026 00:00:00 GMT

Git worktrees let you have multiple branches checked out simultaneously in separate directories. No stashing, no context switching, no 'just a second while I save my work.'

Headless CMS in 2026: Sanity, Payload, and Contentful for Agency Projects

Anurag Verma — Thu, 04 Jun 2026 00:00:00 GMT

Three headless CMS platforms used by agencies, three different bets on where content management is going. Here's how Sanity, Payload, and Contentful actually compare when you're building for clients.

HTTP/3 and QUIC: What Changes for Web Developers and When It Actually Helps

Anurag Verma — Thu, 04 Jun 2026 00:00:00 GMT

HTTP/3 replaces TCP with QUIC, a UDP-based protocol that eliminates head-of-line blocking and handles packet loss better. Here's when that matters, when it doesn't, and how to enable and verify it.

Structured Outputs from LLMs: JSON Mode, Tool Calls, and Schema Validation in Practice

Anurag Verma — Wed, 03 Jun 2026 00:00:00 GMT

Getting a language model to return reliably structured data is not just about asking nicely. Here's the pattern that actually works at production scale.

Model Context Protocol in Production: How MCP Is Connecting the AI Tool Ecosystem

Anurag Verma — Wed, 03 Jun 2026 00:00:00 GMT

MCP has become the standard for connecting AI models to external systems. Here's how it works, how to implement an MCP server, and what to watch out for before going to production.

React Native vs Flutter vs PWA in 2026: Choosing Your Cross-Platform Strategy

Anurag Verma — Wed, 03 Jun 2026 00:00:00 GMT

Three viable paths to cross-platform mobile in 2026. Which one makes sense depends on your team, your deadlines, and how much of the device you actually need.

Shadow AI in the Enterprise: The Security Gap Most Teams Haven't Closed

Anurag Verma — Wed, 03 Jun 2026 00:00:00 GMT

Employees are using AI tools IT hasn't approved, and the data leaving through those tools is largely invisible. Here's what the risk looks like and what actually helps.

Turso and LibSQL: SQLite at the Edge for Production Applications

Anurag Verma — Wed, 03 Jun 2026 00:00:00 GMT

SQLite runs in every phone and browser. Turso extends it to the server and edge with replication, branching, and a network protocol. Here's when it makes sense.

AI-Automated Client Reporting: How Agencies Are Cutting 5 Hours Per Client Per Month

Anurag Verma — Tue, 02 Jun 2026 00:00:00 GMT

Manually compiling monthly reports is one of the highest-effort, lowest-value activities in a web agency. Here's how to replace most of that work with automated pipelines.

Building CLI Tools with TypeScript in 2026: A Practical Guide

Anurag Verma — Tue, 02 Jun 2026 00:00:00 GMT

Command-line tools are underrated as developer products. TypeScript makes them maintainable. Here's the full picture: argument parsing, interactive prompts, output formatting, and distribution.

The JavaScript Temporal API: Finally a Date Object That Works

Anurag Verma — Tue, 02 Jun 2026 00:00:00 GMT

The Date object has been broken for 30 years. Temporal is its replacement, now shipping in browsers and Node.js. Here's what actually changed and how to use it.

Postgres Query Optimization for Application Developers

Anurag Verma — Tue, 02 Jun 2026 00:00:00 GMT

Most slow queries come from a small set of fixable problems: missing indexes, N+1 patterns, and over-fetching. This is the practical diagnostic and fix guide.

Storybook in 2026: The Practical Case for Component-Driven Development

Anurag Verma — Tue, 02 Jun 2026 00:00:00 GMT

Storybook 8 is faster and less painful to configure than it used to be. More importantly, the workflow shift it enables — building components in isolation — solves real problems on real teams.

Blue-Green and Canary Deployments: A Production Guide for Engineering Teams

Anurag Verma — Mon, 01 Jun 2026 00:00:00 GMT

Blue-green and canary deployments give you a way to release software without taking down your service or discovering a bug when it's already affecting everyone. Here's how they work and when to use each.

NestJS in 2026: The Enterprise Node.js Framework Most Teams Overlook

Anurag Verma — Mon, 01 Jun 2026 00:00:00 GMT

NestJS has been growing quietly for years. If your Node.js backend is a pile of Express middleware with no clear structure, NestJS offers a path forward without changing languages.

Product-Led Growth for SaaS: How Developer Tools Get to Enterprise Without a Sales Army

Anurag Verma — Mon, 01 Jun 2026 00:00:00 GMT

PLG is not a marketing strategy. It's an architectural decision about where conversion happens. Here's what it looks like in practice and which patterns actually move revenue.

Test-Driven Development With AI Coding Assistants: Does TDD Still Make Sense in 2026?

Anurag Verma — Mon, 01 Jun 2026 00:00:00 GMT

AI tools write code fast. TDD asks you to slow down and write tests first. These two impulses seem to be in tension. Here's how they actually work together.

WebGPU in 2026: What You Can Actually Build With GPU Compute in the Browser

Anurag Verma — Mon, 01 Jun 2026 00:00:00 GMT

WebGPU is now available across Chrome, Firefox, and Safari. It's not just a graphics API. It's a general-purpose GPU compute layer that changes what's possible in a browser tab.

Conventional Commits and Automated Releases: The Setup That Pays for Itself

Anurag Verma — Sun, 31 May 2026 00:00:00 GMT

Standardized commit messages unlock automatic changelogs, version bumps, and release notes. Here's the full setup — from writing commits to shipping releases without manual steps.

CSS Architecture in 2026: Choosing Between Tailwind, CSS Modules, and CSS-in-JS

Anurag Verma — Sun, 31 May 2026 00:00:00 GMT

Three different approaches to styling a web application — Tailwind, CSS Modules, and CSS-in-JS libraries — and the team contexts where each one actually makes sense.

Developer Portfolio in 2026: What Gets Noticed When Everyone Claims AI Experience

Anurag Verma — Sun, 31 May 2026 00:00:00 GMT

AI projects flood every portfolio. Here's what actually distinguishes a developer's work from the crowd — and why the way you document your decisions matters more than the tech stack you picked.

eBPF in 2026: The Observability Superpower Hiding in Your Linux Kernel

Anurag Verma — Sun, 31 May 2026 00:00:00 GMT

eBPF lets you attach programs to any kernel hook — network packets, system calls, function calls — without patching the kernel or rebooting. Here's what application developers actually need to know.

Tailscale for Distributed Dev Teams: Private Networks Without the VPN Pain

Anurag Verma — Sun, 31 May 2026 00:00:00 GMT

Tailscale creates a private mesh network across any combination of cloud servers, developer laptops, and office machines — without port forwarding, firewall rules, or dedicated VPN hardware.

Project Post-Mortems for Agencies: The Debrief Habit That Makes Teams Better

Anurag Verma — Sat, 30 May 2026 00:00:00 GMT

Most agencies finish a project, invoice the client, and move immediately to the next one. The ones that improve fastest do one more thing: they sit down and ask what actually happened.

Building Chrome Extensions in 2026: A Practical Manifest V3 Guide

Anurag Verma — Sat, 30 May 2026 00:00:00 GMT

Manifest V3 changed how Chrome extensions work. Here's what actually matters for developers building extensions today: service workers, declarativeNetRequest, and the gotchas nobody warns you about.

Document AI for Agencies: Extracting Structure from PDFs, Forms, and Contracts

Anurag Verma — Sat, 30 May 2026 00:00:00 GMT

Clients ask agencies to 'do something with these PDFs' more often than you'd think. Here's how to actually build document extraction pipelines that work in production: OCR, vision models, and structured output.

Local-First Software in 2026: CRDTs, Sync Engines, and When the Complexity Is Worth It

Anurag Verma — Sat, 30 May 2026 00:00:00 GMT

Local-first means your app works offline and syncs when connected. The technology (CRDTs and sync engines) is mature enough to use. The question is whether your use case actually needs it.

Web Animation in 2026: GSAP, Framer Motion, and When to Use the Platform

Anurag Verma — Sat, 30 May 2026 00:00:00 GMT

Three animation options dominate web development right now: CSS, Framer Motion, and GSAP. Here's how to pick the right one for your project and why the native platform is better than you might expect.

CSS View Transitions and Scroll-Driven Animations: What's Now Baseline in 2026

Anurag Verma — Fri, 29 May 2026 00:00:00 GMT

Two browser APIs that used to require JavaScript libraries are now available in all major browsers. Here's what the View Transitions API and scroll-driven animations can do, with working code.

DuckDB in Practice: Analytical Queries Without a Data Warehouse

Anurag Verma — Fri, 29 May 2026 00:00:00 GMT

DuckDB runs OLAP queries directly in your process, on files on your laptop, without a server. Here's how to use it and when it beats spinning up BigQuery or Redshift.

Headless CMS in 2026: Sanity, Contentful, Strapi, and Payload Compared

Anurag Verma — Fri, 29 May 2026 00:00:00 GMT

Every agency project with a marketing team needs a CMS. The options have changed a lot. Here's how Sanity, Contentful, Strapi, and Payload stack up on the criteria that actually matter.

The Modern Developer's Local Tooling in 2026: Terminal, Git, and the Productivity Stack

Anurag Verma — Fri, 29 May 2026 00:00:00 GMT

The command line tools most developers use today are a decade old. Here's what's replaced them and why: terminals, Git UIs, shell configuration, and the small tools that compound into significant time savings.

Postgres Row Level Security in Practice: Multi-Tenant Data Without Application Guards

Anurag Verma — Fri, 29 May 2026 00:00:00 GMT

Row Level Security moves data isolation into the database where it belongs. Here's how to set it up for a multi-tenant SaaS, handle common edge cases, and avoid the traps that break it.

AI Video Generation in 2026: What Agencies Need to Know Before Pitching It to Clients

Anurag Verma — Thu, 28 May 2026 00:00:00 GMT

AI video tools have moved from toy to production-grade in 18 months. Here's what's real, what still fails, and how to have an honest conversation with a client about it.

Browser-Use Agents: Automating the Web When APIs Don't Exist

Anurag Verma — Thu, 28 May 2026 00:00:00 GMT

A growing class of AI agent frameworks can control a browser the way a human does — clicking, typing, navigating. Here's what works in production, what breaks, and when to actually reach for these tools.

Go for Web APIs in 2026: An Honest Assessment

Anurag Verma — Thu, 28 May 2026 00:00:00 GMT

Go has real strengths for backend API work, and some persistent limitations. Here's what teams actually gain and give up when they choose it over Node.js or Python for web APIs.

Multi-Cloud vs Single Cloud in 2026: An Honest Cost-Benefit Analysis

Anurag Verma — Thu, 28 May 2026 00:00:00 GMT

Multi-cloud gets pitched as the default choice for serious companies. The reality is more nuanced — and for most teams, the complexity cost is higher than the lock-in risk it's supposed to prevent.

Writing Technical Specifications That Clients Will Actually Sign Off On

Anurag Verma — Thu, 28 May 2026 00:00:00 GMT

A spec that doesn't get signed is a spec that doesn't protect anyone. Here's how agencies structure technical specifications that move projects forward instead of stalling them.

Adding Search to Your SaaS: Typesense vs Meilisearch vs Algolia in 2026

Anurag Verma — Wed, 27 May 2026 00:00:00 GMT

A hands-on comparison of Typesense, Meilisearch, and Algolia for production SaaS search in 2026 — covering self-hosting, performance, pricing, and real implementation patterns.

Modern Web Development Best Practices

Anurag Verma — Wed, 27 May 2026 00:00:00 GMT

Essential practices for building fast, accessible, and maintainable web applications in 2026.

Product Analytics in 2026: PostHog, Amplitude, and What Teams Actually Track

Anurag Verma — Wed, 27 May 2026 00:00:00 GMT

A practical comparison of PostHog, Amplitude, and Mixpanel for SaaS teams in 2026 — covering pricing, self-hosting, event tracking patterns, and what metrics actually move products forward.

Stripe Billing for SaaS in 2026: Subscriptions, Webhooks, and the Meter API

Anurag Verma — Wed, 27 May 2026 00:00:00 GMT

A practical guide to building SaaS billing with Stripe in 2026 — covering subscription plans, the Meter API for usage-based pricing, webhook reliability, and the Customer Portal.

Transactional Email in 2026: Resend, SES, and Getting Deliverability Right

Anurag Verma — Wed, 27 May 2026 00:00:00 GMT

A practical guide to transactional email for web apps in 2026 — comparing Resend, Amazon SES, and SendGrid, with a focus on SPF/DKIM/DMARC setup and the common deliverability mistakes teams make.

Zod in Production TypeScript: Schema Validation Across the Full Stack

Anurag Verma — Wed, 27 May 2026 00:00:00 GMT

How Zod became the standard for runtime type validation in TypeScript apps — API contracts, form validation, environment variables, and the patterns that make schemas a source of truth across your stack.

Fine-Tuning vs RAG in 2026: A Decision Guide for Teams Building with LLMs

Anurag Verma — Tue, 26 May 2026 00:00:00 GMT

Both approaches customize LLM behavior for your use case, but they solve different problems. Here is how to decide which one you need, how to know when to use both, and what teams consistently get wrong.

OpenTelemetry for Web Apps in 2026: What to Instrument and What to Skip

Anurag Verma — Tue, 26 May 2026 00:00:00 GMT

OpenTelemetry is the observability standard now. Most tutorials show you how to install the SDK and emit traces. Fewer explain which signals actually matter for web applications and which add noise without helping you debug anything.

Playwright E2E Testing in 2026: The Setup That Actually Scales

Anurag Verma — Tue, 26 May 2026 00:00:00 GMT

Most E2E test suites start fast and grow painful. Playwright solves most of that, but only if you set it up right from the start. Here is what actually works in production.

Scope Creep Is a Process Problem: How Agencies Protect Projects Without Burning Clients

Anurag Verma — Tue, 26 May 2026 00:00:00 GMT

Scope creep feels like a client problem until you realize the same clients cause it on every project while other clients never do. The difference is process, not personality.

Transactional Email Engineering: Why Your Emails Land in Spam and How to Fix It

Anurag Verma — Tue, 26 May 2026 00:00:00 GMT

Password resets, invoices, and notification emails are infrastructure. Most developers treat them as an afterthought until a client asks why their welcome emails are disappearing. Here is the full picture.

LangGraph, CrewAI, and AutoGen: Picking an AI Agent Framework in 2026

Anurag Verma — Mon, 25 May 2026 00:00:00 GMT

Three leading agent orchestration frameworks, three different mental models. Here's when each one earns its place, what each costs you in complexity, and what the choice looks like when you're debugging at 2am.

AI Contract Clauses Every Agency Needs to Review Before Signing

Anurag Verma — Mon, 25 May 2026 00:00:00 GMT

AI projects introduce IP, liability, and data training questions that standard software contracts don't address. Here's the language clients send and what it actually means for an agency taking the work.

Product Analytics for Developer Teams: PostHog vs Mixpanel vs Amplitude in 2026

Anurag Verma — Mon, 25 May 2026 00:00:00 GMT

Most teams pick an analytics tool based on a free trial and then live with that choice for years. Here's an honest comparison of PostHog, Mixpanel, and Amplitude so you pick the right one before the data gets messy.

React Native's New Architecture in 2026: What the Fabric and JSI Migration Actually Took

Anurag Verma — Mon, 25 May 2026 00:00:00 GMT

React Native's new architecture shipped as stable and has been default since RN 0.76. Here's what the Fabric renderer and JSI bridge replacement changed, what the migration looks like in practice, and where the remaining rough edges are.

Stripe in 2026: The Payment APIs Every Web Agency Should Know

Anurag Verma — Mon, 25 May 2026 00:00:00 GMT

Stripe's API surface has grown well beyond checkout forms. Here's the realistic breakdown of which Stripe products matter for agency work, which are overkill, and where teams consistently get burned.

AI Agent Memory: Patterns for Giving Agents Persistence Across Sessions

Anurag Verma — Sun, 24 May 2026 00:00:00 GMT

An agent that forgets everything when the session ends is a limited tool. Here are the practical patterns for building different kinds of memory into your agents.

CSS Container Queries in Production: Components That Adapt to Their Context

Anurag Verma — Sun, 24 May 2026 00:00:00 GMT

Media queries ask 'how wide is the viewport?' Container queries ask 'how wide is my parent?' That shift changes how you think about reusable components.

Lit and Web Components in 2026: The Framework-Agnostic Layer Worth Knowing

Anurag Verma — Sun, 24 May 2026 00:00:00 GMT

If your design system needs to work in React, Vue, and a legacy jQuery app simultaneously, Web Components are the only native answer. Lit makes them practical to write.

Sandboxed Code Execution for AI Agents: E2B, Modal, and Firecracker in Practice

Anurag Verma — Sun, 24 May 2026 00:00:00 GMT

When your AI agent needs to run the code it writes, you can't let it touch your production servers. Here's how the main isolation options work and when to use each.

White-Label Web Development: How Agencies Build Capacity Without Hiring

Anurag Verma — Sun, 24 May 2026 00:00:00 GMT

Every agency hits the same wall: more work than the team can handle, but not enough volume to justify a full-time hire. White-label partnerships are how the ones that survive it manage growth.

Figma AI in 2026: First Draft, AI Grid, and What Changed for Design Handoff

Anurag Verma — Sat, 23 May 2026 00:00:00 GMT

Figma shipped real AI features at Config 2025 and teams have been using them for nearly a year. Here is what actually works, what still doesn't, and how design workflows at agencies have changed.

KEDA, VPA, and Goldilocks: Kubernetes Autoscaling Beyond the HPA in 2026

Anurag Verma — Sat, 23 May 2026 00:00:00 GMT

HPA scales on CPU and memory. But most production workloads don't scale well on those signals. KEDA, VPA, and Goldilocks fill the gaps that HPA leaves open.

OAuth 2.0 and PKCE: The Web Auth Patterns Every SPA Developer Needs in 2026

Anurag Verma — Sat, 23 May 2026 00:00:00 GMT

The implicit flow is dead, and most tutorials still teach it. Here is how authorization code flow with PKCE actually works, how tokens should be stored, and where most SPA auth implementations go wrong.

Open Source Licensing for Agencies: What MIT, Apache 2.0, and GPL Mean When You Ship Client Code

Anurag Verma — Sat, 23 May 2026 00:00:00 GMT

Most agency developers don't think about the license of npm packages they install until a client's legal team asks. Here is what the major licenses actually require and where the real risks sit.

Technical SEO for JavaScript Apps in 2026: What Google Actually Renders

Anurag Verma — Sat, 23 May 2026 00:00:00 GMT

Google's crawler runs JavaScript, but not the same way a browser does. The gap between what your JavaScript app renders and what gets indexed is where most SPA SEO problems hide.

AI in E-Commerce: What's Actually Working in 2026

Anurag Verma — Fri, 22 May 2026 00:00:00 GMT

Past the chatbot hype, AI is genuinely improving specific e-commerce outcomes. Here are the implementations producing measurable results, and the ones that still mostly disappoint.

AI-Assisted Technical Documentation: Keeping Docs Accurate When Code Changes Fast

Anurag Verma — Fri, 22 May 2026 00:00:00 GMT

Bad documentation is usually not a writing problem — it's a maintenance problem. AI tools are changing the equation by making initial doc generation cheap and doc refresh practical at scale.

Developer Burnout in the AI Era: What's Different This Time

Anurag Verma — Fri, 22 May 2026 00:00:00 GMT

Burnout among developers isn't new. But the specific pressures of 2026 — AI-driven productivity expectations, skills anxiety, and the blurring of output and identity — create a different texture of exhaustion.

PostgreSQL Performance Tuning: EXPLAIN ANALYZE, Indexes, and Query Debugging

Anurag Verma — Fri, 22 May 2026 00:00:00 GMT

The queries that destroy production Postgres databases share a small set of root causes. Here is how to find them, understand what EXPLAIN ANALYZE is telling you, and fix them without guessing.

Progressive Web Apps in 2026: What Actually Works on iOS and Android

Anurag Verma — Fri, 22 May 2026 00:00:00 GMT

PWAs got a second wind when iOS 16.4 unlocked push notifications and iOS 17 improved install behavior. Three years later, the gap between PWA and native is narrow enough to matter.

The Vercel AI SDK in 2026: Streaming, Tool Calls, and Multi-Step Agents

Anurag Verma — Fri, 22 May 2026 00:00:00 GMT

The Vercel AI SDK has become the default for building AI features in JavaScript apps. Here is what it actually does, how its core primitives work, and where the sharp edges still live.

Agency Retainer Models: Pricing Ongoing Work Without Burning Out

Anurag Verma — Thu, 21 May 2026 00:00:00 GMT

Retainer contracts promise stable revenue. In practice, they often create scope creep, pricing resentment, and capacity problems. Here is how to structure them so they actually work for both sides.

Effect TS: Typed Error Handling in TypeScript That Actually Scales

Anurag Verma — Thu, 21 May 2026 00:00:00 GMT

JavaScript error handling is broken by default — exceptions are untyped, async errors are easy to miss, and side effects are invisible in function signatures. Effect TS fixes all three. Here is how it works.

LLM Hallucination in Production: Mitigation Strategies That Actually Work

Anurag Verma — Thu, 21 May 2026 00:00:00 GMT

Hallucination is not a bug that gets patched in the next model release. It is a property of how language models work. Here are the patterns that actually reduce it in production systems, and what they cost.

Pinia in 2026: Vue State Management After Vuex

Anurag Verma — Thu, 21 May 2026 00:00:00 GMT

Vuex was Vue's state management library for years. Pinia replaced it as the official recommendation and changed how Vue apps manage shared state. Here is how Pinia works and where it fits in a Vue 3 application.

Hono in 2026: The Web Framework Built for the Edge

Anurag Verma — Tue, 19 May 2026 00:00:00 GMT

Hono started as a tiny router for Cloudflare Workers and grew into the default choice for edge APIs. Here is what it does well, where it fits, and why the 'runs everywhere' claim is actually true.

INP Is a Core Web Vital Now. Here Is What's Still Failing and How to Fix It.

Anurag Verma — Tue, 19 May 2026 00:00:00 GMT

Interaction to Next Paint replaced First Input Delay in 2024, and most sites still haven't caught up. INP is harder to optimize because it measures every interaction, not just the first one.

LLM Routing in Production: OpenRouter, LiteLLM, and When Provider Failover Pays Off

Anurag Verma — Tue, 19 May 2026 00:00:00 GMT

Single-provider AI dependencies are a reliability risk. Routing layers like LiteLLM and OpenRouter let you fall back across providers, cap costs, and try smaller models first. Here is the architecture and when it actually matters.

Neon Postgres: Serverless Database Branching Changes How Teams Work

Anurag Verma — Tue, 19 May 2026 00:00:00 GMT

Neon separates storage from compute to make Postgres behave like a serverless resource. The branching feature is what actually changes the development workflow — here's how it works and when it's worth the migration.

TanStack Query in 2026: Server State Management That Gets Out of Your Way

Anurag Verma — Tue, 19 May 2026 00:00:00 GMT

Client state is easy. Server state — data that lives on a backend, changes over time, and needs to stay in sync — is where most React apps make a mess. TanStack Query handles it without ceremony.

CSS Anchor Positioning: Tooltips and Popovers Without JavaScript

Anurag Verma — Mon, 18 May 2026 00:00:00 GMT

CSS Anchor Positioning lets you position one element relative to another using only CSS. No Popper.js, no JavaScript positioning logic, no layout recalculation on scroll. Here's how it works.

gRPC in 2026: When to Use It Instead of REST or GraphQL

Anurag Verma — Mon, 18 May 2026 00:00:00 GMT

gRPC has been available for years but many teams default to REST without thinking through the tradeoffs. Here's how gRPC works, where it fits, and where it doesn't.

k6 Load Testing: Performance Testing Your APIs Before Users Find the Problems

Anurag Verma — Mon, 18 May 2026 00:00:00 GMT

k6 is a developer-friendly load testing tool with JavaScript scripting, CI integration, and clear metrics. Here's how to write meaningful load tests, interpret the results, and catch performance regressions before they reach production.

Python's Free-Threaded Mode: What the GIL Removal Actually Means for Your Code

Anurag Verma — Mon, 18 May 2026 00:00:00 GMT

Python 3.13 shipped an experimental mode that removes the Global Interpreter Lock. Here's what the GIL actually does, what free-threaded Python changes, and what it still doesn't fix.

Tauri 2.0: Build Desktop and Mobile Apps with Web Tech, Without the Electron Bloat

Anurag Verma — Mon, 18 May 2026 00:00:00 GMT

Tauri 2.0 added iOS and Android support while keeping what made 1.x compelling: tiny binaries, Rust backend, and native OS webviews instead of a bundled Chromium. Here's how it works and when to use it.

AI-Assisted Code Review: What the Tools Catch and Where Humans Still Win

Anurag Verma — Sun, 17 May 2026 00:00:00 GMT

CodeRabbit, GitHub Copilot code review, and similar tools have changed the first-pass review. Here's what they actually catch, where they fail, and the workflow that combines both effectively.

Database Connection Pooling in 2026: PgBouncer, Supabase, and Prisma Accelerate

Anurag Verma — Sun, 17 May 2026 00:00:00 GMT

Connection exhaustion is one of the most common production failures for apps that scale. Here's how pooling works, which tool fits which setup, and the configuration decisions that matter.

pgvector in Practice: Semantic Search in Postgres Without a Separate Vector DB

Anurag Verma — Sun, 17 May 2026 00:00:00 GMT

Add similarity search to your existing Postgres database using pgvector. Real setup, indexing strategies, and when you actually need a dedicated vector database.

Python 3.14: What's New and What Actually Matters

Anurag Verma — Sun, 17 May 2026 00:00:00 GMT

Python 3.14 shipped in October 2025. Seven months in, the features worth caring about have become clear. Here's what changed, what to upgrade for, and what to ignore.

Secrets Management in Production: The Patterns That Actually Work

Anurag Verma — Sun, 17 May 2026 00:00:00 GMT

From .env files to Vault to AWS Secrets Manager: a practical guide to storing credentials, API keys, and certificates without waking up to a breach notification.

shadcn/ui in 2026: The Component Library That Refuses to Be a Dependency

Anurag Verma — Sun, 17 May 2026 00:00:00 GMT

shadcn/ui is now the default starting point for React UIs. Here's what it actually is, why copy-paste beats npm install, and how to use it without accumulating a mess.

HTTP Caching in Practice: Cache-Control, ETags, and CDN Invalidation

Anurag Verma — Sat, 16 May 2026 00:00:00 GMT

HTTP caching is one of the highest-leverage performance optimizations available, and one of the most consistently misunderstood. Here is how it actually works, why stale content happens, and how to design a caching strategy that does not surprise you in production.

Incident Response for Small Engineering Teams: SRE Without a Dedicated Ops Team

Anurag Verma — Sat, 16 May 2026 00:00:00 GMT

Site reliability engineering was designed for teams of hundreds. Most of its principles translate directly to teams of 5. Here is what a practical incident response process looks like when nobody has 'SRE' in their title.

SaaS Pricing Models That Actually Retain Customers: Usage-Based, Seat-Based, and Hybrid

Anurag Verma — Sat, 16 May 2026 00:00:00 GMT

Choosing the wrong pricing model doesn't just slow growth — it creates misalignment that drives churn. Here is how the main SaaS pricing models actually work, where each one breaks down, and how to pick the right one for your product.

Secrets Management in 2026: Vault, Doppler, AWS Secrets Manager, and When .env Is Fine

Anurag Verma — Sat, 16 May 2026 00:00:00 GMT

Leaked credentials are the most preventable category of security breach. Here is an honest look at when you need a dedicated secrets manager, which tool to pick, and what to do if you're still on .env files.

Service Mesh in 2026: Do You Actually Need Istio, Linkerd, or Cilium?

Anurag Verma — Sat, 16 May 2026 00:00:00 GMT

Service meshes promise secure, observable microservice communication. But most teams that adopt one do so before they need it. Here is how to decide, and what each option actually costs you.

The Agency Client Onboarding Playbook: What We Do in the First 30 Days

Anurag Verma — Fri, 15 May 2026 00:00:00 GMT

Project kickoffs are where agency relationships are won or lost. The wrong start leads to scope creep, missed expectations, and a client who stops responding. Here's the exact onboarding process we use.

API Versioning Strategies That Don't Break Clients: URL, Header, and Content Negotiation

Anurag Verma — Fri, 15 May 2026 00:00:00 GMT

Breaking API changes are inevitable. How you handle versioning determines whether clients trust your platform or avoid integrating with it. Here's a practical comparison of URL versioning, header versioning, and content negotiation.

Event-Driven Architecture in Practice: Kafka, Redis Streams, and When Each Fits

Anurag Verma — Fri, 15 May 2026 00:00:00 GMT

Message queues and event streams solve different problems. Kafka is not always the right answer. Here's how to think through event-driven patterns and choose the right tool for your production workload.

Multi-Tenancy for SaaS: Database-per-Tenant, Schema, and Row-Level Security Compared

Anurag Verma — Fri, 15 May 2026 00:00:00 GMT

Every SaaS team eventually faces the multi-tenancy decision. The wrong choice creates migration pain later. Here's how to think through database-per-tenant, schema-per-tenant, and row-level security based on what your product actually needs.

SQL Window Functions: The Analytics Queries Your ORM Won't Write for You

Anurag Verma — Fri, 15 May 2026 00:00:00 GMT

Running totals, rankings, moving averages, lag and lead comparisons: window functions handle the analytics queries that would otherwise require application-side loops or multiple round-trips. Here's how they work.

Drizzle ORM: TypeScript-First Database Access That Gets Out of Your Way

Anurag Verma — Thu, 14 May 2026 00:00:00 GMT

Drizzle ORM has become the go-to choice for TypeScript projects that want type safety without the overhead of a heavy ORM. Here's how it works, how to migrate from Prisma, and when to use it.

LLM Observability in 2026: What to Track and Which Tools to Use

Anurag Verma — Thu, 14 May 2026 00:00:00 GMT

Building an AI feature is only half the work. Once it's in production, you need to know when it's drifting, what it's costing, and where it's failing. Here's how to instrument LLM applications properly.

Polars vs Pandas in 2026: When to Switch and What to Expect

Anurag Verma — Thu, 14 May 2026 00:00:00 GMT

Polars has hit stable 1.x and is showing up in production data pipelines everywhere. Here's an honest comparison with pandas, where Polars wins, where it doesn't, and a migration walkthrough.

Tailwind CSS v4: What Changed and How to Migrate

Anurag Verma — Thu, 14 May 2026 00:00:00 GMT

Tailwind v4 moves configuration from JavaScript to CSS, drops the content array, and ships a faster engine. Here's what the breaking changes actually mean for a real project migration.

Vitest in 2026: The Testing Setup That Replaced Jest for Our Team

Anurag Verma — Thu, 14 May 2026 00:00:00 GMT

Vitest runs faster, works natively with ESM and TypeScript, and uses the same API as Jest. If you're still on Jest in a Vite-based project, here's the case for switching and exactly how to do it.

Biome in 2026: One Tool to Replace ESLint and Prettier

Anurag Verma — Wed, 13 May 2026 00:00:00 GMT

Biome is a Rust-based JavaScript toolchain that handles linting, formatting, and imports in a single binary. We've been running it in production projects since late 2025. Here's what the migration from ESLint and Prettier actually looks like.

Container Security in 2026: Image Scanning, SBOMs, and What Teams Actually Do

Anurag Verma — Wed, 13 May 2026 00:00:00 GMT

Running containers in production without scanning them is the equivalent of shipping code without running tests. Here's how teams scan images, generate SBOMs, and add runtime protection, from the CI step to the cluster.

OpenAPI-First API Development: Write the Contract Before the Code

Anurag Verma — Wed, 13 May 2026 00:00:00 GMT

Code-first API development produces documentation as an afterthought. OpenAPI-first flips that: you write the spec, generate the server stubs and client SDKs, and enforce the contract at every layer. Here's how it works in practice.

Server-Sent Events vs WebSockets in 2026: Picking the Right Real-Time Transport

Anurag Verma — Wed, 13 May 2026 00:00:00 GMT

Not every real-time feature needs WebSockets. Server-Sent Events handle most push scenarios with far less complexity. Here's how to choose, and what each approach looks like in actual code.

Temporal for Durable Workflows: How We Finally Stopped Losing Background Jobs

Anurag Verma — Wed, 13 May 2026 00:00:00 GMT

Background jobs that crash mid-execution lose all their state. Temporal solves this by making workflows durable state machines that survive process restarts, deploys, and outages. Here's what it looks like in TypeScript and Python.

API Rate Limiting: Token Bucket, Sliding Window, and Redis Patterns

Anurag Verma — Tue, 12 May 2026 00:00:00 GMT

Every public API needs rate limiting, but the algorithm you choose shapes the user experience and the failure modes. Here's how each approach works and when to use it.

Passkeys Are Ready: Implementing Passwordless Auth in Your Web App

Anurag Verma — Tue, 12 May 2026 00:00:00 GMT

Passkeys are no longer an experimental feature. Apple, Google, and Microsoft all support them natively. Here's what WebAuthn actually looks like in code and when passkeys make sense for your app.

Playwright in 2026: End-to-End Testing That Survives Code Changes

Anurag Verma — Tue, 12 May 2026 00:00:00 GMT

Most E2E test suites break as fast as the features they cover. Here's how to write Playwright tests that hold up when the UI changes, the data changes, and the team keeps shipping.

How to Write a Technical Proposal That Wins Agency Work

Anurag Verma — Tue, 12 May 2026 00:00:00 GMT

Most technical proposals lose because they describe what will be built, not why the client should trust you to build it. Here's how to write one that actually wins.

GitHub Actions in 2026: Faster Pipelines, Smaller Bills

Anurag Verma — Mon, 11 May 2026 00:00:00 GMT

Most teams treat their CI pipeline as a black box that occasionally fails. A few hours of optimization can cut your CI time by 40-60% and your GitHub Actions bill by a similar margin. Here's exactly how to do it.

LLM Evals in Practice: Testing AI Features Before They Go Wrong

Anurag Verma — Mon, 11 May 2026 00:00:00 GMT

Unit tests tell you if your code does what you wrote. They don't tell you if your AI feature does what users need. Here's how to build an evaluation pipeline that catches the failures that matter before users do.

Terraform vs OpenTofu vs Pulumi: Picking Your IaC Tool in 2026

Anurag Verma — Mon, 11 May 2026 00:00:00 GMT

HashiCorp moved Terraform to a Business Source License in August 2023. OpenTofu forked it under the MPL. Pulumi took a different path entirely. Two and a half years on, the dust has settled enough to make a clear-headed choice.

Valkey in 2026: What Happened When Redis Changed Its License

Anurag Verma — Mon, 11 May 2026 00:00:00 GMT

In March 2024, Redis Ltd. relicensed Redis under a source-available license. Within weeks, the Linux Foundation forked it as Valkey. Two years on, here's how the split played out and what it means for teams choosing an in-memory data store today.

Writing AI IDE Rules That Actually Work: Cursor, Windsurf, and Copilot

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

The AI IDE tools everyone uses have a feature most developers set up once and never tune: custom rules. Here's how to write rules that change how the tool generates code, not just what it says it will do.

Caching LLM Responses: When It Helps, When It Hurts, and How to Implement It

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

LLM calls are slow and expensive. Caching them is the obvious move. But caching the wrong responses breaks the user experience in ways that are subtle and hard to debug. Here's a practical guide to doing it right.

Feature Flags for AI Features: Shipping Safely When Outputs Are Non-Deterministic

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

Rolling back a bad API endpoint takes seconds. Rolling back a bad LLM integration is harder — the damage may already be in your logs, your users' inboxes, or your clients' feeds. Feature flags are how you ship AI features without betting everything on launch day.

HTTP/3 and QUIC in 2026: When to Enable It and What to Expect

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

HTTP/3 is in production at every major CDN and supported by all modern browsers. Whether it actually helps your application depends on factors most guides don't explain.

LLM API Costs Are Out of Control: A Production Guide to Cutting Your Bill

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

AI features ship fast. Then the monthly API bill arrives. Here's a systematic approach to understanding and reducing LLM costs without breaking the product.

LLM Structured Outputs in 2026: Reliable JSON Without the Parser Nightmares

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

Getting a language model to return valid, schema-conforming JSON is harder than it looks. Here's what works in production, from native structured output APIs to library-level validation.

Scoping AI Projects for Clients: The Questions That Prevent Expensive Mistakes

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

Most AI project failures start at the scoping stage. The client wants 'AI integration.' The agency quotes a price. Nobody defines what that actually means. Here's how to scope these projects properly.

What an AI Feature Actually Costs: The Budget Lines Nobody Plans For

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

Every AI integration budget starts with API costs and ends with surprises. Here's what production AI features actually cost once you account for everything the initial estimate missed.

uv: How We Replaced pip, poetry, and pyenv With One Tool

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

uv is a Python package manager written in Rust that handles dependencies, virtual environments, and Python version management. We've been using it across all our projects since early 2026. Here's what actually changed.

Zero-Downtime Database Migrations: A Field Guide for Production Systems

Anurag Verma — Sun, 10 May 2026 00:00:00 GMT

ALTER TABLE locks your database. Your migration takes longer than expected. Users get errors. Here's how to handle schema changes that don't interrupt production traffic.

Fixed Price vs Time and Materials: The Contract Decision That Shapes Every Project

Anurag Verma — Sat, 09 May 2026 00:00:00 GMT

The choice between fixed-price and time-and-materials contracts is one of the most consequential decisions in an agency-client relationship. Each model transfers risk differently. Here's how to decide which one fits your project.

OpenTelemetry for AI Applications: Observability When Your Stack Thinks for Itself

Anurag Verma — Sat, 09 May 2026 00:00:00 GMT

Traditional monitoring tells you a request took 800ms. It doesn't tell you the LLM spent 600ms on a bad prompt, returned a hallucinated answer, and burned $0.04 in tokens. Here's how to actually instrument AI applications with OpenTelemetry.

Prompt Injection in 2026: The Attack Your AI App Probably Isn't Defending Against

Anurag Verma — Sat, 09 May 2026 00:00:00 GMT

Prompt injection is the SQL injection of the AI era. As LLMs ship into production apps by the millions, attackers are learning how to hijack them through the data they consume. Here's what the attack looks like and how to defend against it.

WebRTC in 2026: Adding Real-Time Features Without the Pain

Anurag Verma — Sat, 09 May 2026 00:00:00 GMT

Video calls, live collaboration, real-time audio — features clients want more than ever. WebRTC makes them possible, but the gap between a working demo and a production deployment is wider than the documentation suggests. Here's what that gap looks like.

Are Website Developers in Demand in 2026? (And How Many Hours Do They Actually Work?)

Anurag Verma — Fri, 08 May 2026 00:00:00 GMT

The honest read on web developer demand after AI's impact, which roles are hot, which are cooling, and what the working week actually looks like across employment types.

How Much Do Web Design and Development Agencies Actually Make? (2026)

Anurag Verma — Fri, 08 May 2026 00:00:00 GMT

Real revenue, profit margins, and owner take-home for solo, boutique, mid-size, and enterprise web agencies, including the messy parts most income reports skip.

How Much Is Website Development? A Quick 2026 Answer With Real Ranges

Anurag Verma — Fri, 08 May 2026 00:00:00 GMT

A short, direct answer to 'how much is website development' with bracket ranges by project type, the four levers that move the price, and where to read the deeper breakdown.

How Often Should Your Website Be Updated? A Realistic 2026 Cadence Guide

Anurag Verma — Fri, 08 May 2026 00:00:00 GMT

Five different things people mean by 'update' (content, dependencies, performance, design, full rebuild) and how often each should actually happen.

Website Development Companies Near Me: Local vs. Remote in 2026

Anurag Verma — Fri, 08 May 2026 00:00:00 GMT

When proximity actually matters, when it doesn't, and how to evaluate local agencies without falling for the 'we have an office in your city' theatre.

From Copilots to Agents: How Autonomous AI Is Changing How We Build Software

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

AI coding has moved past autocomplete. In 2026, autonomous agents read tickets, write code, run tests, fix failures, and submit PRs — all without human intervention. Here is what this actually looks like in practice and what it means for engineering teams.

7 AI Coding Mistakes That Are Quietly Destroying Codebases — And How We Fix Them

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

AI coding tools accelerate development. They also introduce subtle, systemic problems that most teams do not notice until it is too late. Here are the 7 AI-specific mistakes we have seen across 11 client projects, and the patterns we use to prevent them.

Is AI Actually Replacing Junior Developers? The 2026 Reality Check.

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

Junior developer hiring is down 30% since 2024. AI tools now handle the grunt work that used to train entry-level engineers. But the real story is more complicated — and more important — than the headlines suggest.

B2B Website Agency Guide: What to Demand Beyond Visual Design

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

How to choose a B2B website agency that can support long buying cycles, multiple stakeholders, and demand generation outcomes.

The Best AI Coding Tools in 2026: What We Actually Use and Why

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

We tested every major AI coding tool on real client projects. Here is our honest breakdown of Claude Code, Cursor, GitHub Copilot, Windsurf, and more — with actual workflow recommendations for different types of developers.

The AI Workflow That Lets Our 3-Person Team Compete with 30-Person Companies

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

How SaaS founders are using AI agents, automation hubs, and agentic workflows to run lean teams that punch above their weight. Our complete workflow with tools, costs, and real results.

Can AI Build Full-Stack Apps in 2026? We Tested the Top Platforms.

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

Bolt.new, Lovable, Replit Agent, and v0 all promise 'prompt to production.' We built the same application on each platform and here is what actually happened — the good, the broken, and the security nightmares.

Cursor vs. GitHub Copilot vs. Claude Code: An Honest Comparison for 2026

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

Three tools, three philosophies, three different answers to 'how should AI help me code?' We tested all three on real projects and here is the breakdown — including when to use each and when to use all three together.

Denver Website Design Agency: How to Choose the Right Partner in 2026

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

A practical Denver website design agency guide covering local fit, process maturity, pricing expectations, and performance-first delivery.

Ecommerce Website Development Agency: What Actually Improves Conversion in 2026

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

A practical framework for selecting an ecommerce website development agency, with checkout UX, speed, mobile conversion, and platform trade-offs.

Federal Agency Website Funding Restoration: What Digital Teams Should Do Next

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

A practical response framework for public-sector digital teams after federal website funding restoration orders, with resilience, accessibility, and vendor continuity priorities.

The Future of the Software Engineer: What Survives, What Dies, and What Emerges

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

AI writes 41% of the world's code. Senior engineers report 2x productivity. Junior hiring is down 30%. So what does the future actually look like for software engineers? Here is our honest assessment — informed by what we see every day building software with AI tools.

How Our Developers Actually Use AI in Production — No Hype, Just the Real Workflow

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

Forget the demos. Here is how our 7-person engineering team uses AI tools on real client projects every day — the prompts we write, the mistakes we catch, and the time we actually save.

Vibe Coding Explained: What It Actually Is, What It Is Not, and Why It Matters

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

Andrej Karpathy coined 'vibe coding' in 2025. By 2026 it has become the most misunderstood term in software development. Here is what it actually means, how it works, when to use it, and when it will get you fired.

Website Development Agency USA: 2026 Buyer Guide for High-Impact Builds

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

How to choose a website development agency in the USA with clear evaluation criteria, pricing models, red flags, and ROI-focused decision checkpoints.

Website Optimization Agency Playbook: Speed, SEO, and Conversion in 2026

Anurag Verma — Tue, 05 May 2026 00:00:00 GMT

A practical guide to selecting a website optimization agency and building a 30/60/90-day roadmap across Core Web Vitals, UX, analytics, and conversion.

Google Workspace Gets a Major AI Boost: Gemini Now Powers Docs, Sheets, Slides & Drive

Anurag Verma — Thu, 19 Mar 2026 00:00:00 GMT

Explore Google's latest Workspace update with Gemini AI enhancing Docs, Sheets, Slides, and Drive, empowering users to leverage AI capabilities for more efficient productivity.

Navigating the AI Storage Tax: Rising NAND & RAM Costs in Cloud Infrastructure

Anurag Verma — Thu, 19 Mar 2026 00:00:00 GMT

Explore the financial impact of the AI storage tax and the sharp rise in NAND and RAM costs, affecting enterprise IT budgets and cloud infrastructure strategies.

Samsung Galaxy Z TriFold Discontinued: Challenges in the Foldable Market

Anurag Verma — Thu, 19 Mar 2026 00:00:00 GMT

Samsung halts Galaxy Z TriFold sales in South Korea after just three months, highlighting challenges in the foldable smartphone market amid this innovative era.

Chrome Emergency Patch: Urgent Need to Address Skia Engine Zero-Day Vulnerability

Anurag Verma — Wed, 18 Mar 2026 00:00:00 GMT

Explore the urgent security patch from Google for a critical Skia engine vulnerability (CVE‑2026‑3909) in Chrome, being actively exploited through malicious web pages.

The Emergence of AI in Developing Affordable Energy Solutions

Anurag Verma — Wed, 18 Mar 2026 00:00:00 GMT

Explore how AI innovations are revolutionizing affordable and sustainable energy solutions, focusing on recent advancements in renewable energy tech by companies pushing the boundaries of sustainable development.

IBM's Project Debater: The First AI to Successfully Participate in Human Debates

Anurag Verma — Wed, 18 Mar 2026 00:00:00 GMT

Explore IBM's Project Debater, the groundbreaking AI that joins human debates, transforming how we perceive machine capability in natural language processing and argumentation.

Amazon Partners with Cerebras to Revolutionize AI Inference with Wafer-Scale Chips

Anurag Verma — Tue, 17 Mar 2026 00:00:00 GMT

Explore the groundbreaking partnership between Amazon AWS and Cerebras, aiming to redefine AI inference with high-performance wafer-scale chips, signaling a major shift in AI deployment at scale.

Leveraging AutoML for Faster AI Development: Key Trends and Innovations in 2026

Anurag Verma — Tue, 17 Mar 2026 00:00:00 GMT

Explore how AutoML is accelerating AI development in 2026 with new tools, techniques, and trends that businesses need to know.

Post-Cloud Era: Embracing Serverless Edge Computing for Optimized Performance

Anurag Verma — Tue, 17 Mar 2026 00:00:00 GMT

Explore the shift towards serverless edge computing in the post-cloud era, focusing on performance improvements, cost savings, and real-world case studies of enterprises leveraging this technology.

ZeroDayBench: Benchmarking LLM Agents for Security Flaw Patching Challenges

Anurag Verma — Tue, 17 Mar 2026 00:00:00 GMT

Explore ZeroDayBench—A new benchmark testing the efficacy of leading LLM agents in discovering and patching unseen security vulnerabilities.

Hackbat: Revolutionizing Embedded Security with Open-Source Hardware

Anurag Verma — Mon, 16 Mar 2026 00:00:00 GMT

Explore Hackbat, the open-source hardware platform launching in Q2 2026, set to redefine embedded security by offering full auditability and eliminating reliance on closed-source devices.

The 2026 Global RAM Shortage: What Every Developer Needs to Know

Anurag Verma — Sat, 07 Mar 2026 00:00:00 GMT

RAM prices surged 90% in Q1 2026 as AI data centers consume 70% of global memory. Here's how the shortage impacts developers, hardware costs, and what you can do about it.

The Low-Code/No-Code Explosion: A $44.5B Market Developers Can't Ignore

Anurag Verma — Sat, 07 Mar 2026 00:00:00 GMT

Gartner's $44.5B projection for low-code has arrived. Here's how platforms like Retool, Bubble, and FlutterFlow are reshaping development, and what it means for professional developers.

Node.js vs Deno vs Bun in 2026: The JavaScript Runtime Wars

Anurag Verma — Sat, 07 Mar 2026 00:00:00 GMT

Bun hits 52K req/sec, Deno 2 achieves full npm compatibility, and Node.js remains the enterprise standard. A practical comparison with benchmarks, code examples, and migration guides.

WASI 0.3 Arrives: Native Async Makes WebAssembly a Real Server-Side Contender

Anurag Verma — Sat, 07 Mar 2026 00:00:00 GMT

WASI 0.3 dropped in February 2026 with native async I/O, stream types, and full socket support. Here's why this changes everything for server-side WebAssembly.

Xcode 26.3 and Apple's Big Bet on Agentic Coding

Anurag Verma — Sat, 07 Mar 2026 00:00:00 GMT

Apple shipped native agentic coding in Xcode 26.3, letting AI agents autonomously write, test, and refactor Swift code. Here's what it means for iOS and macOS developers.

Agentic AI in 2026: Inside Google's Agent Leap Report and the Rise of Autonomous AI