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 Boy Scout Rule in Practice: Leaving Code Better Than You Found It
The boy scout rule for code says: always leave the code better than you found it. Not dramatically better. Not rewritten. Better. Rename the confusing variable. Extract the repeated block. Add the missing type. The practice compounds over a year into a codebase that is measurably cleaner without any dedicated refactor sprint, because improvement happened in every pull request.
Tech Debt and RefactoringWhy Your Test Suite Is Slow and How to Fix It
A test suite gets slow because of a few specific causes: tests that hit the database when they should not, integration tests masquerading as unit tests, expensive setup repeated per test, and tests that run sequentially when they could run in parallel. Each cause has a known fix, and the wins compound. Most teams can cut their suite time in half in a week.
Tech Debt and RefactoringThe Multi Year Refactor: Cultural Patterns That Make It Stick
A multi year refactor is a large scale improvement to a codebase that cannot be completed in a single sprint or project; it runs in parallel with ongoing product development over months or years. The technical challenge is manageable; the cultural challenge is not. Teams that succeed at multi year refactors have specific behavioral patterns: they break the work into small, deployable increments; they protect capacity from interruption sprint to sprint; they measure progress visibly; and they have engineering leadership that treats the refactor as a business investment, not a tax on product velocity.
Tech Debt and RefactoringThe Database Migration Without Downtime
A zero downtime database migration changes a live production schema without taking the application offline. It requires running old and new code simultaneously during the transition, writing carefully sequenced SQL that does not lock tables, and deploying in stages rather than in a single cutover. Most teams learn this the hard way after their first failed maintenance window.
Tech Debt and RefactoringThe Refactor Sprint: When a Quarter of the Roadmap Becomes Cleanup
A refactor sprint is a quarter or partial quarter where the team's primary commitment is reducing technical debt rather than shipping new features. I recommend it when the debt has compounded to the point where feature velocity is measurably slower than it was a year ago and the Pareto refactor has already addressed the quick wins. It requires explicit buy in from whoever owns the roadmap, and it needs a defined exit criterion or it will not end.
Tech Debt and RefactoringThe Pareto Refactor: Twenty Percent Effort for Eighty Percent Improvement
The Pareto refactor is the discipline of identifying the twenty percent of technical debt that is causing eighty percent of the team's daily friction, fixing exactly that, and stopping before the work becomes an indefinite cleanup project. I use this framing on every engagement where the team wants to improve the codebase but cannot justify a full rewrite or a refactor sprint that runs for months.
Tech Debt and RefactoringThe Legacy Codebase: A Senior Engineer's Five Day Audit
The legacy codebase audit is the structured process a senior engineer uses to understand an inherited codebase before proposing changes. The goal is not to rewrite immediately or to document everything that is wrong. It is to identify the highest risk areas (the code that breaks most often, the dependencies that are most outdated, the patterns that are most inconsistent), understand why specific decisions were made, and build a map of what can be changed safely versus what requires careful, staged migration.
Tech Debt and RefactoringWhy TypeScript Almost Always Pays Off in SaaS
TypeScript pays off in SaaS because the time horizon is years, not weeks. The cost is up front: a slower first month and a steeper learning curve. The benefits compound: fewer runtime bugs, faster refactors, faster onboarding, and a codebase that documents itself. For anything that will outlive the founders' first sprint, the tradeoff is decisive.
Tech Debt and RefactoringThe Quiet Cost of Skipping Type Safety
Skipping type safety is a decision that looks free at the start and reveals its cost over eighteen to twenty four months. The symptoms are not dramatic. They are slow: bugs that require a debugger to trace, refactors that take three times the estimate, and engineers who spend more time reading code than writing it. I have cleaned up the aftermath of this decision enough times that I no longer see it as a style preference.
Tech Debt and RefactoringThe Engineering Migration: Patterns That Work
Engineering migrations (moving from one database schema, one service architecture, or one infrastructure platform to another) fail most often because they are treated as single, isolated events rather than incremental processes. The patterns that work share a common structure: make the old and new systems coexist, move traffic incrementally, validate at each step before proceeding, and maintain the ability to roll back until confidence is high. The pattern is applicable to schema changes, service extraction, and platform migrations.
Tech Debt and RefactoringThe Architecture Decision Record: A Lightweight Discipline
An Architecture Decision Record is a short document that captures a significant technical decision, the context that drove it, the alternatives considered, and the reasoning behind the choice. ADRs are not design documents. They are decision logs. The value is not in the writing. It is in the future conversation that does not have to happen because the answer is already written down.
Tech Debt and RefactoringThe Mock Versus Real Service Debate
The mock versus real service debate in software testing concerns whether tests should use mocked versions of external dependencies (databases, third party APIs, queues) or real versions. The answer depends on the test type and the purpose of the test: unit tests test isolated logic and should mock everything external; integration tests test how components interact and should use real implementations of internal dependencies but can mock external APIs; end to end tests test the full user flow and should use real services wherever practical. The failure mode that causes the most production bugs is mocking too aggressively in integration tests, producing tests that pass against mocks but fail against real implementations.
Tech Debt and RefactoringThe Test Pyramid for SaaS: Unit, Integration, End to End
The test pyramid describes the ideal ratio of unit tests to integration tests to end to end tests in a healthy test suite. Unit tests form the base, integration tests sit in the middle, and end to end tests sit at the top. Most SaaS teams invert this unintentionally, building too many brittle end to end tests and too few integration tests. Understanding why the pyramid is shaped the way it is changes how you allocate testing effort.
Tech Debt and RefactoringThe Tech Debt Negotiation: How Engineers Should Talk to Founders About It
The tech debt negotiation is the conversation where an engineer explains to a founder why the team needs time to fix something that already works. Most engineers lose this conversation because they speak in technical terms to someone who thinks in business terms. I have run this negotiation dozens of times. The engineers who win it stop arguing about code quality and start arguing about cost.
Tech Debt and RefactoringThe Tech Debt Ledger: A Discipline Worth Keeping
A tech debt ledger is a living document that tracks the shortcuts a codebase has accumulated, what each one costs per quarter, and who owns the decision to pay it down. I keep one on every project I run. It makes the invisible visible, turns a vague sense of dread into a prioritized list, and gives engineers a way to talk to founders without sounding like they are making excuses.
Tech Debt and RefactoringWhy Most Rewrites Fail
Most rewrites fail not because the engineers are incompetent but because the work expands to absorb every known problem with the old system, the timeline slips past the point where the business can wait, and the new code turns out to have its own edge cases that only production use reveals. I have seen this pattern across dozens of teams. Understanding why it happens is the first step to avoiding it.
Tech Debt and RefactoringThe Strangler Fig Pattern: Replacing Legacy in Stages
The strangler fig pattern replaces a legacy system incrementally by routing traffic surface by surface to a new system that grows around the old one. The old system continues running until enough surfaces have been migrated that it can be retired. I use this pattern on every large migration where a big bang cutover would be too risky and a direct rewrite would take longer than the business can sustain.
Tech Debt and RefactoringWhen to Refactor and When to Rewrite
Refactoring improves the internal structure of code without changing its observable behavior. Rewriting replaces the code entirely with a new implementation. The decision between them is not about code quality. It is about cost, risk, and what the existing code knows that you do not. I lean heavily toward refactoring, and I push for rewrites only when I can show the math that justifies them.
Tech Debt and RefactoringThe Tech Debt Audit: A Two Day Process
A tech debt audit is two days of structured investigation that produces a ranked list of the highest cost problems in a codebase. I run this on every new engagement before recommending any refactor or rewrite. The goal is not a comprehensive catalogue. The goal is a short list of the things that are actively slowing the team down or creating risk right now.
DevOps, Deployment, InfrastructureThe First Hire in DevOps: When and What
The first DevOps hire at a startup is justified when the infrastructure work required to keep production reliable and the development environment productive is consuming more engineering time than a dedicated hire would cost. Most startups reach this point between 8 and 15 engineers. The role at this scale is not a traditional operations role: it is a software engineering role focused on the internal platform that product engineers build on.
DevOps, Deployment, InfrastructureThe Quiet Cost of Vendor Lock In: A Practical Audit
Vendor lock in is the degree to which your system depends on a specific vendor's proprietary APIs, data formats, or infrastructure such that switching would require significant rework. It is not inherently bad. AWS, Stripe, and Twilio are all forms of lock in that most teams accept because the cost of building the alternative is higher than the switching cost. The problem is lock in you did not choose consciously.
DevOps, Deployment, InfrastructureThe Customer Communication Playbook for Incidents
Customer communication during incidents is the discipline that separates companies that survive outages from the ones that lose accounts because of them. The technical fix matters. The communication around it matters just as much. Customers who are informed promptly, honestly, and with a clear timeline tolerate downtime far better than customers left in silence.
DevOps, Deployment, InfrastructureThe Engineering Dashboard Every Founder Should Have
The engineering dashboard a founder needs is not a dashboard of every metric the infrastructure produces. It is a dashboard of the five to ten signals that tell the founder whether the product is working, whether the team is shipping, and whether the system is heading toward a problem. Most founders either have too much data with no interpretation or too little data until something breaks. The right dashboard sits between these.
DevOps, Deployment, InfrastructureThe Migration From Heroku: A Step By Step
The Heroku migration is the process of moving an application from Heroku's managed platform as a service to an alternative hosting provider. The migration is usually motivated by cost (Heroku's pricing increased significantly after Salesforce's 2022 free tier removal), by the need for features Heroku does not provide (persistent storage, custom compute configurations, specific database options), or by the desire for more infrastructure control. The most common migration targets are Railway, Render, Fly.io, and AWS/GCP managed services.