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.
Responsive Design vs Adaptive Design vs Mobile First
Responsive design uses fluid grids, flexible images, and CSS media queries to allow a single layout to adapt fluidly across different screen sizes. Adaptive design serves different fixed layouts to different device classes, typically detected by user agent or screen size. Mobile first design is a development approach that starts by designing and building the mobile layout, then progressively enhancing to larger screens. These approaches are complementary: most modern implementations use responsive design techniques built with a mobile first methodology.
Backend, APIs, and System DesignResilience Patterns: Circuit Breakers, Retries, Bulkheads
Resilience patterns are design techniques that allow distributed systems to continue functioning when individual components fail or degrade. Circuit breakers prevent cascading failures by stopping requests to a failing dependency before the failure spreads. Retries with exponential backoff recover from transient failures without creating retry storms. Bulkheads isolate failures to a subset of resources so that one failing dependency cannot consume all available capacity and degrade unrelated functionality. Together they form the baseline resilience architecture for services that depend on external APIs, databases, and other network connected components.
DevOps, Deployment, InfrastructureReserved Instances, Savings Plans, Spot: The Saving Map
AWS Reserved Instances, Savings Plans, and Spot Instances are three mechanisms for reducing compute costs below on demand pricing. Reserved Instances commit to a specific instance type for 1 or 3 years in exchange for a 30 to 70 percent discount. Savings Plans commit to a dollar amount of compute spend per hour for 1 or 3 years in exchange for discounted rates across eligible services. Spot Instances use spare AWS capacity at up to a 90 percent discount but can be interrupted with 2 minutes notice when AWS needs the capacity. Each mechanism is appropriate for a different workload profile.
Software Costs and BudgetingReserved Instances and Cost Math: When They Pay Off
Reserved instances are cloud compute commitments where you agree to use a specific instance type in a specific region for one or three years, in exchange for a discount of 30 to 70 percent compared to on demand pricing. Reserved instances transfer the utilization risk from the cloud provider to the buyer: the cloud provider offers a lower price because they have committed capacity, and the buyer pays for the capacity whether they use it or not. The break even point for reserved instances requires sustained utilization above approximately 60 percent.
Comparisons and Vendor DecisionsResend vs Postmark vs SendGrid vs Mailgun
Resend, Postmark, SendGrid, and Mailgun are transactional email services used to send programmatically triggered emails: authentication emails, purchase receipts, notification emails, and onboarding sequences. They differ in API design, deliverability guarantees, email template tooling, analytics capabilities, and pricing at different volume tiers. The choice among them is primarily determined by the engineering team's stack and preferences, the required deliverability tier, and the email volume that determines which pricing model is most favorable.
Comparisons and Vendor DecisionsResend vs AWS SES vs Mailgun for Transactional Email
Transactional email services provide infrastructure for sending programmatically triggered emails: account confirmation, password reset, purchase receipts, notification emails, and onboarding sequences. They handle SMTP relay, IP reputation management, delivery tracking, bounce and complaint handling, and compliance features (unsubscribe management, GDPR compliance). The distinction between transactional email (triggered by user actions) and marketing email (sent in bulk to subscriber lists) matters for deliverability: mixing them on the same IP reputation degrades deliverability for the transactional emails users need to receive.
Business Automation and OpsRenewals and Expansion Revenue Automation
Renewals and expansion revenue automation refers to the systems that identify renewal opportunities, trigger renewal workflows at the right time, identify expansion opportunities based on usage signals, and execute upsell or cross sell communications without manual sales intervention. These systems integrate product usage data, billing data, and CRM data to surface the right opportunity at the right time and route it to the appropriate workflow: automated renewal for low touch accounts, sales assisted renewal for high value accounts, and upsell triggered by usage for accounts approaching plan limits.
Comparisons and Vendor DecisionsRender vs Fly.io vs Railway vs Heroku in 2026
Render, Fly.io, Railway, and Heroku are platform as a service (PaaS) providers that abstract infrastructure management so developers can deploy applications without configuring servers, load balancers, or networking. They compete on deployment simplicity, pricing, geographic distribution, and the range of supported services (databases, caches, queues, cron jobs). The market shifted after Heroku removed its free tier in 2022, and Render and Railway gained adoption as the direct alternatives.
Business Automation and OpsRefund Automation Without Customer Friction
Refund automation is the process of building systems that evaluate refund requests against defined policy rules and automatically process eligible refunds without human review. A properly designed refund automation system handles the majority of refund cases instantly, which reduces support load and improves customer satisfaction at the same time. It routes edge cases and exceptions to a human review queue, integrates with payment processors to issue the refund programmatically, and maintains an audit trail of every refund decision for accounting and dispute purposes.
Tech Debt and RefactoringRefactoring Without a Test Suite: A Survival Guide
Refactoring without a test suite is the practice of changing code structure without the automated validation that confirms behavior has been preserved. This is the common case in legacy codebases, inherited projects, and startup codebases where shipping speed was prioritized over test coverage. Safe untested refactoring uses a combination of characterization tests (tests that document current behavior rather than specify correct behavior), incremental changes with immediate deployment validation, and rollback mechanisms that allow reverting a change if production behavior changes unexpectedly.
Tech Debt and RefactoringRefactoring User Sessions Without Logging Anyone Out
Refactoring user sessions involves migrating from one session storage or session format to another without invalidating existing sessions, causing users to be logged out, or introducing authentication gaps during the transition. Common session refactors include migrating from cookie based sessions to JWT tokens, changing session storage from a database to Redis, updating session schema to include new fields, and migrating from one authentication provider to another. Each of these migrations requires a dual read strategy that validates both the old and new session format during the transition window.
Tech Debt and RefactoringRefactor Stories That Saved a Startup
A refactor that saves a startup is a targeted code restructuring that removes a specific technical constraint that was directly limiting business outcomes: blocking a key customer requirement, preventing a feature the market requires, causing reliability problems that were churning customers, or slowing development to the point where the team could not respond to market feedback. Successful refactors have a specific business outcome they are trying to unlock, an incremental execution plan, and a measurable definition of done.
Tech Debt and RefactoringRefactor Stories That Killed a Startup
A refactor that kills a startup is a large scale code restructuring initiative that consumes engineering capacity for months without shipping user value, introduces regressions that damage user trust, and delays the product iteration that would have validated the business model. Not all large refactors have this outcome, but the ones that do share predictable patterns: underestimating scope, attempting the refactor without adequate test coverage, running the refactor in parallel to product development without maintaining velocity, and lacking a clear incremental delivery strategy.
Hiring Developers, Freelancers, and AgenciesRed Flags in a Developer's Portfolio
Portfolio red flags are signals in a developer's presented work, explanations, and public code that suggest potential problems with code quality, professional judgment, communication, or fit for the role being evaluated. A portfolio assessment is one of the most information rich parts of a hiring process because it shows actual output rather than claimed skills. Reading portfolios effectively requires knowing what absence of information signals as much as what presence signals.
Hiring Developers, Freelancers, and AgenciesRecruiter Mistakes That Repel Senior Engineers
Recruiter mistakes that repel senior engineers are the specific behaviors in outreach, job descriptions, and hiring processes that cause experienced engineers to disengage from a recruiting process. Senior engineers whose skills are in demand receive enough inbound recruiting interest to be selective about which processes they invest time in. Recruiting behaviors that signal a poor candidate experience, a misaligned role, or a disrespectful hiring process cause senior engineers to opt out early, regardless of whether the role itself would be a good fit.
MVP Development and Startup BuildsRealistic MVP Development Timelines: What Nobody Tells You
An MVP (Minimum Viable Product) development timeline is an estimate of how long it will take to build the minimum version of a product that can be used by real customers to validate or invalidate the core product hypothesis. Realistic MVP timelines account for the non coding work that consumes development time: product decisions that must be made during implementation, integration complexity with outside services, QA and bug fixing, environment setup and deployment infrastructure, and the inevitable scope changes when early users provide feedback.
Performance OptimizationReal User Monitoring vs Synthetic Monitoring: Both, Not Either
Real User Monitoring (RUM) collects performance data from actual users as they use the application in their real browsers, networks, and devices. Synthetic monitoring simulates user interactions from fixed locations using scripted tests that run on a schedule. RUM shows what real users actually experience, including performance on slow networks, old devices, and geographically distant locations. Synthetic monitoring provides consistent, repeatable baseline measurements for catching regressions before they reach users.
Web App and Frontend DevelopmentReal Time Collaboration: A Web App Engineering Primer
Real time collaboration in web applications allows multiple users to view and edit the same content simultaneously, with changes from each user instantly reflected in all other users' views. The core technical problems are conflict resolution (two users editing the same field simultaneously), state synchronization (ensuring all clients eventually see the same state), presence (showing who is currently viewing or editing), and latency compensation (showing local changes immediately before the server confirms them). WebSockets are the standard transport for real time collaboration features.
SaaS Architecture and ScalingRead Replicas: When They Save You and When They Lie to You
A read replica is a copy of the primary database that receives a continuous stream of write operations from the primary and applies them to stay in sync. Read replicas are used to distribute read traffic: queries that do not need the absolute latest data are routed to replicas, reducing load on the primary. The critical constraint is replication lag: replicas are always slightly behind the primary (milliseconds to seconds depending on load), so reads from replicas may return data that is slightly stale.
Web App and Frontend DevelopmentReact Query vs SWR vs RTK Query
React Query, SWR, and RTK Query are React libraries for managing server state: data fetched from an API that needs to be cached, synchronized, and updated in the UI. They solve the problem of manually managing fetch, loading, and error state, providing automatic caching, background refetching, stale-while-revalidate semantics, optimistic updates, and pagination utilities. The distinction between client state (what the user has done) and server state (what the server has) is the conceptual foundation for all three libraries.
Cross Platform and Mobile DevelopmentReact Native Performance: The Patterns That Make It Production Ready
React Native performance optimization involves identifying and eliminating the specific causes of frame drops, slow navigation, and janky animations in React Native apps. The main performance categories are JavaScript thread work (heavy computation, excessive rerenders), main thread contention (synchronous native calls, operations that trigger layout), network and data loading patterns (waterfall requests, missing loading states), and bundle size (large JavaScript payloads that increase startup time and parse time).
Cross Platform and Mobile DevelopmentReact Native New Architecture: What Founders Should Know
React Native's new architecture replaces the asynchronous JavaScript bridge with a synchronous JavaScript Interface (JSI) that allows JavaScript to directly call native code without serialization overhead. The new architecture includes three components: JSI (the synchronous native binding layer), Fabric (the new rendering system that enables synchronous UI updates), and TurboModules (natively lazy loaded modules that improve startup time). Together they eliminate the performance bottlenecks that distinguished React Native from fully native apps.
Backend, APIs, and System DesignRate Limiting Algorithms Compared: Token Bucket, Leaky Bucket, Fixed Window
Rate limiting is the practice of restricting how many requests a client can make to an API within a time window. The algorithm used determines how requests are counted, when limits are enforced, and how burst traffic is handled. Common algorithms include fixed window (simple count per time period), sliding window (count across a rolling time period), token bucket (tokens regenerate at a fixed rate, bursts are allowed up to bucket capacity), and leaky bucket (requests are queued and processed at a fixed rate, smoothing burst traffic).
AI Integration and Vibe Coding RescueRAG (Retrieval Augmented Generation) for SaaS: When It Helps and When It Does Not
Retrieval Augmented Generation (RAG) is an AI architecture pattern that combines a retrieval system (typically vector search over a document store) with a large language model. When a user asks a question, the system retrieves relevant documents from the store and includes them in the LLM prompt as context, allowing the model to generate answers grounded in specific documents rather than relying on training data alone. RAG is used when the answer depends on information that is proprietary, recent, or not in the LLM's training data.