The Journal
The notes I would have wanted at fifteen.
Long-form notes on shipping production systems, scaling SaaS, hiring engineers, AI integration, and the engineering decisions behind Yashveer Labs — written by founder Yashveer Singh.
The Game Day: How to Run a Failure Simulation
A game day is a planned, controlled failure simulation where engineering teams intentionally break things in an environment that mirrors production, to test whether their monitoring, alerting, runbooks, and incident response processes actually work. The value is not in the failure itself. It is in discovering the gaps between the incident response process that exists on paper and the one that executes under pressure. Teams that run game days learn what breaks before customers discover it.
DevOps, Deployment, InfrastructureThe Error Budget: SRE for Small Teams
An error budget is the allowable amount of downtime or failure derived from your SLO. If your SLO is 99.9 percent uptime, your monthly error budget is about 43 minutes. When you spend that budget, you stop shipping features and fix reliability. It is how Google operationalized the trade off between velocity and stability, and it scales down to a two engineer SaaS team.
DevOps, Deployment, InfrastructureThe On Call Rotation That Engineers Can Actually Sustain
An on call rotation is the schedule that determines which engineer is responsible for responding to production incidents outside of business hours. A sustainable one means pages that are actionable, shifts that are short enough to not destroy sleep, and a feedback loop that reduces the page volume over time. Most rotations fail on all three of those. The ones that work are designed explicitly, not inherited.
DevOps, Deployment, InfrastructureThe Disaster Recovery Plan That Fits on One Page
A disaster recovery plan is the documented procedure for restoring a system to operational state after a catastrophic failure. Most DR plans are too long to read during an incident, too abstract to execute under pressure, and stored in systems that may not be accessible during the disaster they are meant to address. A useful DR plan fits on one page, lives in multiple locations, and contains specific commands rather than general principles.
DevOps, Deployment, InfrastructureTrunk Based Development for Small Teams
Trunk based development is a source control practice where all engineers commit directly to a single main branch, or to short lived feature branches that merge within one to two days. The goal is to eliminate the integration problems that come from long lived branches. It requires feature flags for work in progress and a CI pipeline that runs fast enough to give feedback before the next commit.
DevOps, Deployment, InfrastructureThe Monorepo vs Polyrepo Debate Settled for Startups
A monorepo is a single Git repository that contains multiple related packages or applications. A polyrepo (or multirepo) is a separate Git repository for each package or application. The debate between them is about developer experience, CI/CD complexity, and team coordination overhead. For startups and small teams, the monorepo wins on nearly every dimension: shared TypeScript types across frontend and backend, one CI pipeline to maintain, atomic commits across related changes, and no dependency versioning across repositories.
DevOps, Deployment, InfrastructureWhy Vercel Cannot Be Your Entire Backend
Vercel is a great frontend host and a competent edge runtime. It is not designed to host long running processes, background jobs, persistent connections, or workloads that need precise control over memory and concurrency. Trying to make it do all of those things produces a system that is fragile in ways that get worse as traffic grows.
DevOps, Deployment, InfrastructureThe Twelve Factor App in 2026: Still Relevant, Slightly Updated
The twelve factor app is a methodology for building software as a service applications that are portable, scalable, and operable. Published by Heroku engineers around 2011, it defines twelve practices covering codebase structure, dependency management, configuration, backing services, build and release, process execution, port binding, concurrency, disposability, environment parity, logging, and admin processes. In 2026 the core is still sound with a few factors that need a modern context.
DevOps, Deployment, InfrastructureThe Deployment Pipeline That Survives Real World Pressure
A deployment pipeline is the automated system that takes code from a developer's commit to production. Under real world pressure, pipelines fail in predictable ways: they slow down when the team needs them most, they produce false positive failures that erode trust, and they lack the rollback speed required to respond to production incidents. A pipeline that survives pressure is fast, honest about failures, and reversible.
Performance OptimizationThe Three Hour Performance Audit Every Team Should Run Quarterly
A three hour performance audit is a structured quarterly review covering database query health, API endpoint percentiles, front end bundle size, and caching layer effectiveness. I run these with client teams as a repeating calendar item. The goal is not perfection. It is catching the regressions that compound quietly over a quarter and turning each one into a tracked task before a customer notices.
Performance OptimizationThe Performance Regression That Hides in CI
A CI performance regression is a latency or throughput degradation introduced by a code change that passes functional tests but is never caught because the pipeline has no budget check wired to the build. It ships quietly, accumulates over weeks, and surfaces only when a customer complains or a metric dashboard finally gets reviewed. The fix is a budget gate, not more manual review.
Performance OptimizationWhy Memoization Is a Trap When Misused
Memoization caches the result of a function so future calls return instantly. Used carefully on expensive, deterministic computations, it is a real win. Used as a reflex on cheap functions or as a fix for rerendering issues, it adds complexity, increases memory, hides the real problem, and produces stale data bugs that are nearly impossible to reproduce in development.
Performance OptimizationThe Hot Path: Finding and Optimizing It
The hot path is the code that executes on every request or on the most performance critical requests in a system. It is the code where a 1ms improvement has the largest impact on the overall system latency, and where a 5ms regression is immediately visible in p99 latency metrics. Finding the hot path requires profiling, not intuition: experienced engineers are wrong about which code is slow as often as they are right. Optimizing the hot path requires removing unnecessary work, deferring work to background tasks, and caching the results of expensive operations.
Performance OptimizationThe Slow Query Log: A Discipline Every SaaS Team Should Practice
The slow query log is a database level feature that records every query exceeding a configured threshold, typically 100 to 500 milliseconds. I treat it as a standing discipline, not a firefighting tool. Reviewed weekly, it surfaces the queries that will degrade under load before users see the effect. Teams that skip this step discover the same queries in production under pressure.
Performance OptimizationThe Garbage Collection Tax: A Backend Story
Garbage collection tax is the latency added to request processing when the runtime's garbage collector pauses execution to reclaim memory. In Node.js and JVM based services, GC pauses are the most common source of latency spikes that are not explained by slow database queries or external API calls. The tax is paid on every GC cycle but is invisible in average latency metrics. It shows up as p99 and p999 latency outliers that are much higher than p50.
Performance OptimizationThe HTTP Caching Strategy That Most Teams Get Wrong
HTTP caching is the mechanism by which browsers and CDNs store responses and serve them without contacting the origin server. The correct caching strategy depends on whether the content changes frequently, whether it is user specific, and what the acceptable staleness window is. Most teams either cache too aggressively (serving stale user specific data) or too conservatively (disabling caching for static assets that could safely be cached for months). The difference between a correct and incorrect caching strategy is measurable in page load time, infrastructure costs, and the correctness of what users see.
Performance OptimizationThe Edge Rendering Bet: When It Pays Off
Edge rendering executes server side rendering logic at CDN edge nodes distributed globally, rather than at a single origin server. The promise is lower latency for geographically distributed users. The reality depends on the workload: pages that are mostly static or can be cached benefit significantly from edge rendering. Pages that require database queries, authenticated sessions, or dynamic content may not benefit, and may perform worse due to the limitations of the edge runtime.
Performance OptimizationThe Real Numbers Behind a Fast Web App in 2026
The real numbers behind a fast web app are not goals you pick from a blog post. They are the thresholds at which users stop noticing load time, at which search engines reward you, and at which churn starts to drop. I track six metrics per app: LCP, INP, CLS, API p95 latency, time to first byte, and bundle size. Every one has a concrete target and a measurement method.
Performance OptimizationWhy Your App Got Slower After You Added Users
An app slows down as it grows because the work per request scales with the size of the data, not the number of features. Queries that scanned ten rows now scan ten million. The fix is rarely a rewrite. It is finding the three or four queries and code paths that grew with the data and fixing those.
Security, Auth, and ComplianceThe Data Processing Agreement: A Founder's Practical Read
A data processing agreement is a contract between a SaaS company and its customers that specifies how personal data is handled, stored, and protected. Under GDPR and similar laws, any company processing personal data on behalf of a customer must have a signed DPA in place before doing so. For enterprise buyers, a missing DPA is a deal blocker.
Security, Auth, and ComplianceThe Post Mortem Culture That Improves Security
A post mortem culture that improves security is one where incidents are written down without blame, root causes are traced to systems not people, and every finding maps to a concrete action with an owner and a deadline. The teams that do this consistently find the same class of vulnerability once. The teams that skip it find it repeatedly.
Security, Auth, and ComplianceThe Customer Security Questionnaire: A Strategic Asset
The customer security questionnaire is the document an enterprise buyer sends before signing a SaaS contract. Most founders treat it as a compliance burden. The founders who close more enterprise deals treat it as a sales asset: a chance to demonstrate that their security posture is stronger than competitors who are still scrambling to answer the questions.
Security, Auth, and ComplianceVendor Security Assessments: How to Pass Them Quickly
A vendor security assessment is the customer's way of confirming your product will not become their security incident. The questionnaire looks daunting and is mostly repeatable. Build the answers once, store them in a system you trust, and the next assessment becomes a copy and paste job with light editing. The real work is having the underlying controls; the documentation is downstream of that.
Security, Auth, and ComplianceThe Privacy Policy That a Lawyer Actually Approved
A privacy policy that a lawyer actually approved is one written to match what your product actually does with data, reviewed by counsel with privacy experience, updated when the product changes, and posted where users can find it before they give you their data. The policy is not a compliance trophy. It is a contract with your users and a legal document that will be read by enterprise buyers and regulators alike.