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.
Becoming a Senior Engineer in Three Years
A senior engineer owns systems end to end, communicates trade offs clearly, makes decisions that compound, and lifts the engineers around them. The title is awarded by behavior, not by tenure. The accelerated path from junior to senior in three years is real but rare. It requires a deliberate plan, sustained intensity, and the willingness to take work that other engineers avoid.
Backend, APIs, and System DesignBatch Processing vs Streaming: The Choice Founders Often Conflate
Batch processing runs over a bounded window of data on a schedule. Streaming processes events continuously as they arrive. Batch is simpler, cheaper, and right for almost every SaaS analytics workload. Streaming is right when the latency of the output matters in seconds rather than minutes, or when the data has no natural batch boundary. The wrong choice often doubles the operational cost and provides no business benefit.
SaaS Architecture and ScalingBackup, Restore, and Drill Practice: A SaaS Disaster Recovery Guide
A SaaS disaster recovery plan covers what is backed up, how to restore it, how often it is drilled, and what the recovery time and recovery point objectives are. The document set is small. The discipline is what matters. A team that drills quarterly recovers in hours. A team that has never drilled recovers in days, if at all.
Security, Auth, and ComplianceBackup and Restore Drills: A Compliance Asset Most Teams Skip
A backup and restore drill is a scheduled exercise where the team restores from backup, validates the restored data, and measures the time to recover. It is the only way to know if the backups are real. Compliance frameworks like SOC 2, ISO 27001, and HIPAA all expect evidence of drills. The drill is also the cheapest insurance against the worst day a SaaS can have.
Backend, APIs, and System DesignBackground Jobs at Scale: Inngest, Trigger, Cron, and Beyond
Inngest and Trigger.dev are managed durable execution platforms designed for serverless and Next.js stacks. They handle retries, scheduling, fan out, and step level state for multi step jobs. Cron is still the right tool for simple scheduled work. The combination of a managed durable executor for complex flows and a queue for simple background work covers most modern SaaS workloads cleanly.
SaaS Architecture and ScalingBackground Job Queues: The Architecture Decision Founders Skip
A background job queue is the system that runs work asynchronously from the user request. It is the right place for sending email, processing files, calling external APIs, generating reports, and anything that should not block the response. The queue choice determines the failure model, the retry semantics, the observability story, and the operational tax of the product for years. Most founders pick by accident. The ones who pick by design save quarters of work.
Performance OptimizationBackend Performance Budgets: How to Set Them
A backend performance budget is a documented latency target for each user facing endpoint, measured at the 95th and 99th percentile, with an owner and a remediation process when the budget is breached. It is the equivalent of a service level objective scoped to performance. Teams that operate with budgets ship faster and catch regressions earlier. Teams without them discover slowness in production after the customer noticed.
Comparisons and Vendor DecisionsAWS vs GCP vs Azure: A Founder Framework
AWS is the default for breadth, market share, and enterprise procurement. GCP is the default for data heavy workloads, BigQuery, and Kubernetes ergonomics. Azure is the default for Microsoft shops, regulated industries, and customers that already buy Microsoft. The capability gap between the three has nearly closed. The right choice for a founder in 2026 is the one that matches the team and the customer base, not the one that wins benchmark articles.
DevOps, Deployment, InfrastructureAWS ECS vs EKS vs Fargate: A SaaS Founder Comparison
ECS is AWS's native container orchestrator, simpler than Kubernetes and cheaper to operate. EKS is managed Kubernetes, more portable but operationally heavier. Fargate is the serverless compute layer that runs containers without nodes for either ECS or EKS. Most SaaS startups land on ECS with Fargate, scale into ECS with EC2 for cost, and only adopt EKS when Kubernetes portability becomes a hard requirement.
Security, Auth, and ComplianceAuthorization Patterns: RBAC, ABAC, ReBAC Explained
RBAC, ABAC, and ReBAC are the three dominant authorization patterns in modern SaaS. RBAC maps users to roles to permissions. ABAC checks attributes of the user, the resource, and the request against a policy. ReBAC encodes authorization as a graph of relationships, the way Google Zanzibar models it. Each one solves a different shape of problem, and the right call depends on how your customers think about access.
Comparisons and Vendor DecisionsAuth0 vs Clerk vs Supabase Auth vs Build Your Own
Auth0 is the enterprise default, expensive but battle tested. Clerk is the modern developer experience leader for B2B SaaS in 2026, with batteries for organizations, MFA, and passkeys included. Supabase Auth is the right call when you are already on Supabase and want auth tied to your Postgres. Building your own is a real option only when you have a security team, a multi region constraint, or an unusual integration.
Security, Auth, and ComplianceAudit Trails for Sensitive Actions: The Pattern That Earns Trust
An audit trail for sensitive actions is a focused, structured record of the operations that carry security or compliance weight. Logins, permission changes, exports, impersonations, configuration writes, and any destructive operation. It exists separately from the noisy application log. It is the artifact a customer security team will ask to see in the second meeting, and the one your compliance auditor will sample first.
Security, Auth, and ComplianceAudit Logs That Pass Real Audits
An audit log that passes a real audit is structured, append only, queryable by both customer and auditor, retained for the regulatory minimum, and tied to a controlled vocabulary of action names. It captures who did what, on which resource, in which tenant, from which network. It is reviewed regularly. It survives the auditor walking through it line by line and asking why each field exists.
Comparisons and Vendor DecisionsThe Vendor Audit Every Funded Startup Should Run Once a Year
A vendor audit is a structured annual review of every paid tool, platform, and service a startup relies on. I run one to surface redundant spend, hidden lock in, security gaps, and contracts that no longer match the product's actual shape. Done well it takes three days and usually saves more than it costs in the first pass.
SaaS Architecture and ScalingAudit Logs for SaaS: A Compliance and Trust Tool
An audit log records who did what, when, on which resource, with which authentication path. It is a compliance requirement for SOC 2 and many other regimes. It is also a customer trust feature, because enterprise buyers ask about it. Done well, the audit log is a queryable, exportable record that proves the system behaves as documented. Done badly, it is a noisy table nobody reads.
Backend, APIs, and System DesignAsync Job Failure Recovery: Patterns That Actually Work
Async jobs fail. Patterns that recover them well share five qualities. Idempotency, exponential backoff with jitter, dead letter queues with alerting, structured retries, and reconciliation jobs. Together they handle the vast majority of failure modes a SaaS will see. The teams that ship them ride out incidents that would sink the teams that skipped them.
Cross Platform and Mobile DevelopmentApple Watch and Wearable Apps: When They Make Business Sense
A wearable app makes business sense when the product has a clear glanceable moment, when the user benefits from acting without their phone, and when the engineering team can sustain the platform support. Most apps fail at least one of these three. The ones that pass all three get a retention lift and a differentiation that competitors find hard to match.
Cross Platform and Mobile DevelopmentApple Intelligence and Android AI: Building for the New Platforms
Apple Intelligence on iOS and the AICore framework on Android both let apps tap into operating system level AI without sending data off device. The platforms cover summarization, transcription, smart suggestions, and image understanding. The opportunity for developers is to ship AI features without paying API costs. The constraint is that the OS controls the capability set and the device tier. Most modern apps should support both pathways.
Cross Platform and Mobile DevelopmentApple App Store Account Setup: Avoiding the Common Traps
Setting up an Apple Developer account looks like a paperwork task. It contains several decisions that compound for years. Account type, legal entity name, tax setup, bank routing, contract acceptance. Each one has a default that is wrong for some founders. Here is the version with the traps marked so you make the right call the first time.
Cross Platform and Mobile DevelopmentApp Versioning Strategy: Why Force Update Is a Last Resort
App versioning strategy is the contract between mobile clients and the backend they talk to. The discipline is to keep the contract flexible enough that old clients keep working, and the support window long enough that users do not feel ambushed. Force update is the option you keep for the cases that genuinely require it, not the default reaction to every backend change.
Cross Platform and Mobile DevelopmentApp Tracking Transparency and Marketing Attribution
App Tracking Transparency removed the device level identifier most attribution tools relied on. The replacement is a stack of partial signals: SKAdNetwork on iOS, Privacy Sandbox on Android, server side conversion APIs, deferred deep links, and probabilistic matching. The teams that combine them carefully get attribution that is good enough to drive marketing decisions. The teams that wait for the old precision to return are still waiting.
Cross Platform and Mobile DevelopmentApp Store Review Hell: How to Survive It as a Solo Founder
App review hell is the loop of submission, rejection, resubmission, and panic that catches every solo founder who has not done the homework. The survival kit is small. A reviewer note that addresses common concerns up front. A test account that works on the first try. Privacy disclosures that match the runtime. A clean appeal template. The teams that ship these never live in review hell. The teams that skip them visit often.
Cross Platform and Mobile DevelopmentApp Store Pricing Psychology for Founders
App pricing psychology comes down to three numbers. The free tier that gets users in. The paid tier that captures most of the revenue. The premium tier that anchors the others. The discipline is choosing each one based on customer perception, not on cost. The teams that price by perception ship products that convert. The teams that price by cost end up under priced or over priced, both of which leave money on the table.
Cross Platform and Mobile DevelopmentApp Store Optimization for Founders Who Hate Marketing
App Store Optimization is the discipline of making your app easier to find and more likely to install once found. The work is mostly mechanical. A clear title and subtitle. Keywords that match real searches. Screenshots that show the product in one second. A description that converts the curious. A short video that does the same job for the patient. Done well, ASO can lift the install rate from store search substantially, without spending a dollar on ads.