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.
Engineering Retention: The Patterns That Work
Engineering retention is the practice of keeping the engineers you have. The cheapest form of hiring is retaining the engineer who would have left. The patterns that work are specific. Meaningful work. Clear career progression. Fair compensation. A manager who advocates. A culture that respects the engineer's time. Each pattern is unglamorous. The combined effect is engineers who stay because the alternative is worse, not just because the comp is acceptable.
Recruiter and Career PositioningEngineering Mentorship That Actually Works
Engineering mentorship that actually works is a structured relationship where a more senior engineer helps a less senior engineer level up faster than they would alone. The mentor is specific. The mentee is committed. The meetings have agendas. The work between meetings is real. Most mentorship is theater. The mentorship that produces real growth is rare and identifiable by a few patterns.
Recruiter and Career PositioningEngineering Interview Preparation Without Burning Out
Engineering interview preparation is the work to get ready for the specific interviews you have coming up. The default approach is grinding through LeetCode for months and burning out. The better approach is targeted preparation matched to the companies and the roles, with explicit time bounds and rest. The engineers who land the best offers prepared deliberately. The engineers who burned out prepared by volume.
Startup Technical StrategyEngineering Driven Customer Discovery
Engineering driven customer discovery is the practice of engineers participating directly in customer conversations. The engineer hears the customer's words, the context, and the pain. The understanding shapes the technical decisions in ways that secondhand notes cannot. The teams that adopt this build better products. The teams that keep engineering away from customers build products that miss the mark.
Startup Technical StrategyEngineering Diversity Without Performative Theater
Engineering diversity is the practice of broadening the pool of candidates the team hires from and the perspectives the team carries. The actual work is mostly in sourcing, the interview process, and the team's culture. Performative theater is the announcements and the values pages that produce no measurable change. The teams that do the real work quietly end up with more diverse teams. The teams that perform it loudly often do not.
Startup Technical StrategyEngineering Capacity Planning for Small Teams
Engineering capacity planning at small team scale is the practice of knowing what your team can actually ship in a quarter and aligning commitments accordingly. The discipline does not require Jira ceremony. It requires honesty about velocity, time absorbed by maintenance, and the difference between scheduled hours and shipping hours. The teams that plan honestly ship what they promise. The teams that do not promise more than they can deliver.
Hiring Developers, Freelancers, and AgenciesEngineer LinkedIn Profiles That Actually Convert Recruiters
A LinkedIn profile that converts recruiters is the one that lets a recruiter quickly decide whether the engineer is a fit for their role. Clear headline that names the role and the stack. About section that reads like a real person wrote it. Experience entries that name impact, not duties. Skills section with the technologies recruiters search for. The profile is a search result, not an autobiography.
Tech Debt and RefactoringEnd to End Tests: When They Help and When They Hurt
End to end tests exercise the application from the user's perspective. The test opens a browser, performs actions, and verifies the result. The tests are valuable because they catch integration failures unit tests miss. The tests are expensive because they are slow, flaky, and costly to maintain. The right balance is a small number of high value e2e tests guarding the critical paths, with unit and integration tests covering the rest.
Security, Auth, and ComplianceEncryption at Rest vs in Transit: What Customers Will Ask
Encryption at rest protects data stored on disk from being read if the storage is compromised. Encryption in transit protects data being moved across the network from being read if the connection is intercepted. Both are now table stakes for B2B SaaS in 2026. The implementations are straightforward. The teams that have not implemented either are usually the teams that have not been through an enterprise security review yet.
DevOps, Deployment, InfrastructureEgress Costs on AWS: The Bill Nobody Sees Coming
Egress costs on AWS are the fees charged when data leaves AWS for the public internet or moves across regions and availability zones. The rate is 0.09 USD per GB to the internet for most regions in 2026, after the first 100 GB free. Cross AZ transfer is 0.01 USD per GB each direction. At scale these add up. The teams that engineer for low egress save tens of thousands per month. The teams that do not pay the full rate.
Web App and Frontend DevelopmentDrag and Drop in Modern Web Apps
Drag and drop in modern web apps lets users move items between locations using their mouse or touch. The basic browser API exists. The library ecosystem in React has matured to dnd-kit as the dominant choice. The right implementation handles keyboard accessibility, touch devices, virtual lists, multi item selection, and the inevitable optimistic update with server confirmation. The wrong implementation works in the demo and breaks for real users.
Backend, APIs, and System DesignDomain Driven Design for SaaS: A Practical Subset
Domain Driven Design is a set of patterns for modeling complex business domains in code. The full method has heavy ceremony. The practical subset that helps SaaS teams is small. Bounded contexts give you clear module boundaries. Ubiquitous language keeps engineering and product talking about the same things. Aggregates protect consistency across related entities. Three patterns. Used well, they prevent the architectural mess that grows from absent design.
AI Integration and Vibe Coding RescueDocument Understanding in SaaS: PDFs, Spreadsheets, and Beyond
Document understanding in SaaS is the capability to extract structured information from unstructured or semi structured documents. PDFs. Spreadsheets. Scanned forms. Contracts. Receipts. Modern AI has made this dramatically cheaper and more accurate than the previous OCR plus rules approach. The teams that ship it well embed it into specific workflows. The teams that ship it badly build a generic upload box.
Comparisons and Vendor DecisionsDiscord vs Slack vs Teams for Engineering Communities
Discord, Slack, and Microsoft Teams are the three credible options for engineering community communication in 2026. Discord is the default for open developer communities. Slack is the default for internal company use and customer communities. Teams is the default for Microsoft heavy enterprises. The choice depends on who you are bringing together and what they already use.
Backend, APIs, and System DesignDesigning for Failure: A Backend Engineer's Mental Model
Designing for failure means assuming that every dependency can fail and building the application to degrade gracefully rather than cascade. Timeouts. Retries with backoff. Circuit breakers. Bulkheads. Graceful degradation. Each is a small pattern that prevents a small failure from becoming a customer facing incident. The mental model is that failures are normal and the system should handle them as such.
Backend, APIs, and System DesignDesigning for Audit From the Start
A system designed for audit captures every sensitive action with enough context that an auditor can reconstruct what happened. The discipline is in the design, not in the bolt on logging after the fact. Append only audit storage, tenant scoped queries, retention that fits the regime, and an auditor friendly query interface. The investment at week one is small. The retrofit at year three when an auditor demands evidence is a quarter of work.
MVP Development and Startup BuildsDesigning an MVP That Can Scale Without Rewriting It
An MVP designed to scale is one where the early decisions do not block the later scaling work. Multi tenancy as a first class concept. A clean data model. Idempotent jobs. Bounded contexts. A real database. These are not big upfront investments. They are choices that cost little at week one and save a quarter of rewrite at year two. Most MVPs do not need to be rewritten. Most MVPs were designed in ways that make rewrite inevitable.
Backend, APIs, and System DesignDesigning an API That Customers Will Not Curse In Five Years
An API that customers will not curse in five years is the result of decisions made at week one. Stable shapes. Additive evolution. Consistent naming. Clear errors. Cursor based pagination. Versioning that respects existing integrations. The discipline is unglamorous. The result is an API that customers integrate once and keep using rather than tolerating.
Cross Platform and Mobile DevelopmentDeep Linking: A Mobile Engineering Primer
A deep link is a URL that opens directly to a specific screen inside a mobile app, with optional context. The user clicks the link in an email, a message, a notification, or a web page. The app opens to the right screen. Done well, deep linking is invisible plumbing that powers marketing, sharing, and notifications. Done poorly, links route to the wrong place or open the web instead of the app.
DevOps, Deployment, InfrastructureDatadog vs New Relic vs Grafana Cloud vs Honeycomb
Observability platforms collect metrics, logs, and traces and present them in a way that engineers can use to diagnose issues. Datadog is the most expensive and most complete. New Relic is the simplest to onboard. Grafana Cloud is the most cost effective for teams comfortable with assembly. Honeycomb is the deepest for distributed tracing. Most teams pick one. The mature teams pick deliberately.
Performance OptimizationDatabase Query Performance: The Five Patterns That Hurt the Most
Database query performance problems usually come from a small set of recurring patterns. The N plus one query that issues many queries instead of one. The sequential scan that ignores indexes. The unbounded result set that grows with the database. The cross join that produces a cartesian product. The lock contention that serializes work that could have been concurrent. Fix these five and most database performance work is done.
Backend, APIs, and System DesignDatabase Partitioning: Strategies and Pitfalls
Database partitioning is the technique of splitting one logical table into multiple physical pieces. The pieces can be queried as one but are stored and indexed separately. The pattern fits very large tables where queries naturally filter by the partition key. The pattern hurts tables where the queries do not naturally filter. The right key and the right time are the two decisions that matter most.
SaaS Architecture and ScalingDatabase Migrations at Scale: How to Move Fast Without Breaking Things
Database migrations at scale are the schema and data changes that have to ship without taking the application offline. The patterns that worked on a small table produce locks, blocked writes, and outages on a large table. The right playbook uses concurrent operations, backfills in batches, dual writes during transitions, and verification at every step. The discipline is small. The protection from outages is large.
Backend, APIs, and System DesignDatabase Indexes: A Practical Primer for SaaS Engineers
A database index is a data structure that speeds up query lookups. The right index turns a query from seconds to milliseconds. The wrong index slows writes and wastes storage without helping reads. Most SaaS performance problems are missing indexes. The fix is mechanical. The discipline is to recognize which indexes to add and which to skip. The primer is small. The impact is large.