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.
Senior vs Mid vs Junior Developer: When to Hire Which
Developer seniority levels (junior, mid level, senior) describe the combination of technical skill, project experience, independent judgment, and communication ability that characterize engineers at different stages of their career. The hiring decision between seniority levels is not purely about technical skill. It is about the cost of direction, the risk of technical decisions made independently, and the overhead of mentorship relative to the value produced. Different product stages and team compositions require different seniority mixes.
DevOps, Deployment, InfrastructureSelf Hosting on Hetzner vs AWS: The Real Tradeoffs
Self hosting on Hetzner refers to deploying application infrastructure on dedicated or cloud servers from Hetzner, a German hosting provider known for significantly lower prices than major cloud providers. The comparison to AWS represents a broader choice between commodity hosting (Hetzner, OVH, Vultr) and hyperscale cloud (AWS, GCP, Azure). The tradeoffs involve price per compute unit, managed service ecosystem, geographic availability, compliance certifications, and the operational overhead of managing infrastructure without managed services.
AI Integration and Vibe Coding RescueSelf Hosting LLMs: When It Pays Off and When It Wastes Money
Self hosting LLMs refers to running open source large language models (Llama, Mistral, Qwen, Gemma) on infrastructure controlled by the organization, rather than using commercial API services (OpenAI, Anthropic, Google). Self hosting provides control over data residency, eliminates per token API costs at high volume, and allows fine tuning on proprietary data. The tradeoff is GPU infrastructure cost, operational complexity, and typically lower model capability compared to frontier commercial models.
Security, Auth, and ComplianceSecrets Management for SaaS: Vault, AWS Secrets Manager, Doppler
Secrets management for SaaS encompasses the systems used to store, distribute, rotate, and audit access to sensitive credentials including database connection strings, API keys, encryption keys, and service tokens. A secrets management system provides: centralized storage with encryption at rest, access controls that restrict which services and environments can read each secret, audit logs of every secret access, and rotation mechanisms that update secrets without manual deployment. The alternatives range from .env files (no management) to HashiCorp Vault (full dynamic secrets infrastructure).
DevOps, Deployment, InfrastructureSecrets in CI: The Patterns That Avoid Leaks
Secrets in CI refer to sensitive credentials, API keys, tokens, and certificates that must be available to continuous integration and deployment pipelines to run tests, build artifacts, and deploy to production. Managing these secrets safely requires avoiding hardcoded values in code, restricting secret access by job type and branch, preventing secret values from appearing in build logs, and auditing which pipelines have access to production credentials.
MVP Development and Startup BuildsScope Negotiation: How to Push Back on Your Own Wishlist
Scope negotiation in MVP development is the process of deciding which features are essential to the initial product launch and which can be deferred, dropped, or handled through manual processes. It is the discipline of trading completeness for speed, accepting that the first version of the product will not contain everything originally envisioned, and making those tradeoffs intentionally rather than reactively. Scope negotiation applies to features, integrations, polish, and technical infrastructure equally.
Security, Auth, and ComplianceSCIM Provisioning: The Feature Enterprise Customers Will Demand
SCIM (System for Cross-domain Identity Management) is a standardized protocol that allows enterprise identity providers (Okta, Azure AD, Google Workspace) to automatically create, update, and deactivate user accounts in SaaS applications. When a new employee joins a company, their IT team provisions them in the identity provider, which automatically creates their account in all connected SaaS tools via SCIM. When an employee is offboarded, their accounts across every tool connected via SCIM are deactivated automatically. SCIM is a standard enterprise buying requirement for SaaS products targeting companies with more than 50 employees.
Backend, APIs, and System DesignSchema Evolution: Adding Columns Without Downtime
Schema evolution refers to the process of modifying a database schema (adding columns, changing types, dropping tables, creating indexes) while the application is running and serving production traffic. Migrating schema without downtime requires careful sequencing of DDL statements, application code changes, and data backfills to avoid table locks that block reads and writes, and to maintain compatibility between the old and new application code during the deployment window.
SaaS Architecture and ScalingSchema Design Decisions That Haunt You at Million User Scale
Schema design decisions at scale refers to the database structure choices made early in a product's development that become expensive to change once data volumes are large and production traffic is continuous. These decisions include primary key type selection, timestamp precision, soft delete implementation, JSON column usage, and index strategy. Changes to these structures on large tables require careful migration strategies to avoid downtime, and some choices are practically irreversible once millions of rows exist.
SaaS Architecture and ScalingScaling from One Thousand to One Hundred Thousand Users: The Invisible Database Bottlenecks
Database bottlenecks at scale refer to the performance degradation that occurs when a database system that performs adequately at low user volumes begins to show latency, lock contention, or capacity problems as user counts and data volumes grow. These bottlenecks are often invisible at early scale because query execution times and connection counts are low enough that inefficiencies are not measurable. They become visible and painful as data volumes grow and query patterns that were fast on small tables become slow on large ones.
Hiring Developers, Freelancers, and AgenciesSalary Benchmarks for Full Stack Engineers in 2026
Salary benchmarks for full stack engineers represent the compensation ranges at different seniority levels and locations for engineers who work across both frontend and backend layers of a web application. These benchmarks reflect base salary, excluding equity, bonuses, and benefits. The ranges vary significantly between the US, UK, Western Europe, and emerging development markets, and are influenced by years of experience, technology stack, domain specialization, and whether the role is remote, hybrid, or on site.
Backend, APIs, and System DesignSaga Patterns: Distributed Transactions Without Distributed Pain
The saga pattern manages distributed transactions by breaking a multi step operation into a sequence of local transactions, each with a compensating transaction that reverses its effects on failure. When a step fails, the saga executes compensating transactions for all previously completed steps, returning the system to a consistent state without requiring distributed locks or two phase commit. Sagas are the standard approach to long running transactions in microservices and multi service architectures.
SaaS Architecture and ScalingSaaS Webhook Reliability: From At Most Once to At Least Once to Exactly Once
Webhook delivery reliability is described in terms of three guarantees: at most once (the event may be lost but never delivered twice), at least once (the event will eventually be delivered but may be delivered more than once), and exactly once (the event is delivered precisely once). Each guarantee requires progressively more infrastructure to implement. Most SaaS products target at least once delivery with idempotent receivers, which is the practical balance between reliability and implementation complexity.
SaaS Architecture and ScalingSaaS Search at Scale: Postgres Full Text vs Algolia vs Typesense
Search infrastructure for SaaS encompasses the systems that allow users to find content within the product by text query. PostgreSQL full text search uses built in GIN indexes on tsvector columns to support full text queries without additional infrastructure. Algolia and Typesense are dedicated search services that provide relevance ranking, typo tolerance, instant search (results as you type), and faceted search. The choice between them is primarily determined by search complexity requirements and willingness to add a dedicated search service to the infrastructure.
Software Costs and BudgetingSaaS Pricing for Founders: A Cost to Build to Sell Framework
SaaS pricing is the decision about how much to charge customers for access to the product and how to structure that pricing (per seat, per usage, per feature tier, or some combination). The cost to build to sell framework connects pricing to the cost structure of the product: the infrastructure cost per customer, the customer acquisition cost, the support cost per customer, and the gross margin required to build a sustainable business. Pricing that does not account for these costs produces a product that grows in users but shrinks in profitability.
SaaS Architecture and ScalingSaaS Onboarding Architecture: From Signup to Aha
SaaS onboarding architecture encompasses the technical systems that guide a new user from account creation to their first experience of the product's core value (the aha moment). This includes account setup flows, email verification, workspace initialization, sample data provisioning, checklist progress tracking, and the analytics instrumentation that shows whether users reach activation milestones. Onboarding architecture determines the activation rate: the percentage of signups that complete the onboarding flow and reach the aha moment.
SaaS Architecture and ScalingSaaS Multi Tenancy Patterns: Database per Tenant vs Shared Schema
SaaS multi tenancy is the architecture that allows multiple customers (tenants) to share the same application infrastructure while keeping their data isolated from other customers. The three common patterns are: database per tenant (each customer has a separate database, providing the strongest isolation), schema per tenant (each customer has a separate schema in a shared database), and shared schema (all customers share the same tables with a tenant_id column for isolation). Each pattern has different tradeoffs for isolation strength, operational complexity, and cost at scale.
SaaS Architecture and ScalingSaaS Analytics Infrastructure: PostHog vs Mixpanel vs Snowflake vs Build Your Own
SaaS analytics infrastructure encompasses the tools used to collect, store, and analyze product usage data. Product analytics tools (PostHog, Mixpanel, Amplitude) focus on user behavior analysis: funnel analysis, retention cohorts, feature adoption, and A/B testing. Data warehouses (Snowflake, BigQuery, Redshift) store raw event data and support SQL based analysis for business intelligence and custom reporting. The two categories solve different problems and are often used together: product analytics for day to day product decisions and a data warehouse for long term data storage and cross system analysis.
DevOps, Deployment, InfrastructureRunbooks That Actually Get Used During Incidents
A runbook is a documented set of procedures for responding to a specific operational situation: a production incident, a scheduled maintenance task, or a known failure mode. Runbooks that are used during incidents are specific, actionable, and structured for execution under stress: numbered steps with expected outcomes, commands that can be copied and run directly, decision points that route to different procedures based on observed state, and escalation contacts for situations that exceed the runbook's scope. Runbooks that are not used are too abstract, too long, or contain commands that require interpretation before execution.
Web App and Frontend DevelopmentRouting Patterns That Survive Real World Use
Web application routing is the system that maps URLs to the components or pages that should be rendered, and manages navigation state between pages. Routing patterns determine how URLs are structured, how route parameters are typed and validated, how nested layouts are shared across routes, how loading and error states are handled during navigation, and how route guards (authentication, authorization) are applied. Good routing patterns are navigable by URL, bookmarkable, shareable, and consistent with the user's browser navigation expectations.
Recruiter and Career PositioningRoles That Will Matter More in 2026 and Beyond
Engineering role demand shifts reflect changes in what problems are most expensive, hardest to automate, and most consequential for business outcomes. Roles that require deep system understanding, judgment across functions, production ownership, and customer context are gaining leverage as AI tools automate the routine coding and implementation work. Roles primarily focused on routine implementation without those cross cutting dimensions are becoming commoditized as AI coding tools reduce the human time required per unit of output.
Security, Auth, and ComplianceRight to Be Forgotten: How to Implement It Without Pain
The right to be forgotten (formally 'right to erasure' under GDPR Article 17) gives individuals the right to request deletion of their personal data when it is no longer necessary for the purpose it was collected, when consent is withdrawn, or when the data was processed unlawfully. Implementing this right requires identifying all locations where a user's personal data is stored (database records, backups, logs, analytics, third-party services), deleting or anonymizing the data in each location, and maintaining an audit trail of the deletion request itself without retaining the deleted personal data.
Comparisons and Vendor DecisionsRetool vs Internal vs Build Your Own Admin Panel
An admin panel is an internal application used by company employees (support, operations, sales, engineering) to view, manage, and modify application data and user accounts. Retool and Internal are low code platforms that connect directly to databases and APIs to build admin interfaces without writing a full frontend application. Building a custom admin panel involves writing a standard web application with its own design, component library, and deployment. Each approach trades off build time, customization, cost, and maintenance burden differently.
Backend, APIs, and System DesignREST vs GraphQL vs gRPC: A Decision Matrix for Founders
REST, GraphQL, and gRPC are API design paradigms that determine how clients and servers communicate. REST uses HTTP methods and resource URLs with JSON responses, following the constraints of the web architecture. GraphQL is a query language where clients specify exactly what data they need in a single request, reducing both over fetching and under fetching. gRPC uses Protocol Buffers over HTTP/2 for strongly typed, high performance communication between services, primarily used for internal service to service communication. The choice between them is primarily determined by who the API clients are and what the communication requirements are.