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.
URL As State: A Pattern Worth Embracing
The URL is the oldest and most underused state management tool in web development. When filter values, pagination, sort order, and active tabs live in the URL instead of a component or a store, pages become shareable, bookmarkable, and resilient to refresh. Most teams discover this pattern late and spend effort retrofitting it. The teams that start with it build better products faster.
Web App and Frontend DevelopmentThe Empty State Discipline
An empty state is the interface a user sees when a list, a table, a dashboard, or a section of the product has no data to display. Empty states are the first impression every new user has of the product's core functionality, and the experience at that moment determines whether they understand what to do next or leave confused. Most empty states are an afterthought. The products that invest in them convert better.
Web App and Frontend DevelopmentThe Onboarding Wizard: A UX and Engineering Discussion
The onboarding wizard is the first substantive interaction a user has with a product. It sets the expectation for everything that follows. Most wizards are too long, collect information the product does not immediately need, and create friction at exactly the moment it is most costly. The teams that ship effective wizards treat it as a product problem first and an engineering problem second.
Web App and Frontend DevelopmentWCAG for Founders: A Practical Subset
WCAG is the official accessibility standard. It is also long and intimidating. The practical subset that catches most of what matters is: semantic HTML, keyboard navigability, color contrast, alt text, focus indicators, and proper form labels. Get these right and you are accessible enough for most users and most enterprise procurement checks. The rest can come later.
Web App and Frontend DevelopmentThe Modern Email Builder for SaaS Products
The modern email builder for SaaS products is a development workflow that uses React components to define transactional email templates, renders them on the server to HTML for delivery, and sends them through a transactional email service with strong deliverability. This approach replaces the traditional pattern of HTML string manipulation, MJML preprocessing, or visual email builders with a workflow native to how developers already work, where email templates are version controlled, typed, and testable in the same environment as the rest of the application.
Web App and Frontend DevelopmentThe Accessibility Audit Every Web App Should Pass
An accessibility audit is a structured review of whether your web app can be used by people with visual, motor, auditory, or cognitive disabilities. WCAG 2.1 AA is the legal and practical standard in most markets. Most web apps fail it. The failures are not exotic. They are the same twelve issues, repeated across thousands of codebases.
Web App and Frontend DevelopmentThe Forms Problem: React Hook Form vs Formik vs TanStack Form
React Hook Form, Formik, and TanStack Form are the three dominant libraries for managing form state in React applications. React Hook Form is the performance default: uncontrolled inputs with minimal rerenders, strong TypeScript support, and the largest ecosystem. Formik is the original standard, now largely superseded by React Hook Form for new projects. TanStack Form is the newest entrant with a type safe API and a framework agnostic design that appeals to projects where forms are complex and TypeScript correctness is a priority.
Web App and Frontend DevelopmenttRPC vs REST vs GraphQL on the Frontend
The choice between tRPC, REST, and GraphQL on the frontend is mostly a question of who controls the backend and how much the frontend needs to own its data shape. tRPC wins when you own both ends of the wire. GraphQL wins when the frontend needs flexible queries against a shared graph. REST wins when you need broad compatibility, external consumers, or an existing API.
Web App and Frontend DevelopmentThe Frontend Architecture That Survives Three Years of Feature Sprawl
A frontend architecture that survives three years of feature additions is one built around clear module boundaries, a consistent data fetching layer, a design system that constrains UI variation, and a state management approach that does not require global state for local problems. The specific patterns that fail at scale: colocating business logic with UI components, using global state for everything, and building without a design system so every feature adds its own UI primitives.
Web App and Frontend DevelopmentZustand vs Redux vs Jotai vs Recoil vs Context
React state management in 2026 is no longer a debate about Redux. It is a question of what shape your state has. Zustand for simple global stores. Redux Toolkit for large apps that need devtools and time travel. Jotai or Recoil for atomic state. Context for narrow scopes. Picking right depends on the actual access patterns of your state, not on library popularity.
Web App and Frontend DevelopmentThe State Management Question in 2026
State management in React has fragmented into several credible answers, each suited to a different kind of problem. The choice in 2026 is not Redux versus Zustand. It is a question of what kind of state you have, where it lives, and whether a library is even the right tool. Most teams overbuild this early and pay for it later.
Web App and Frontend DevelopmentThe Modern Web App Stack: A 2026 Survey
The modern web app stack in 2026 is a set of technologies that are stable, well maintained, and productively used by individual developers and small teams to build production web applications. The landscape has consolidated significantly from five years ago: TypeScript is the default language, React with Next.js is the dominant framework for full stack applications, PostgreSQL is the default database, and Vercel or similar edge deployment platforms handle infrastructure. The remaining choices (ORM, authentication, payment processing, deployment) have clear defaults that work well for most cases.
Founder Decision FrameworksThe Decision to Walk Away
Walking away from a company means making the deliberate decision to stop, not because external forces compelled it but because the founder has decided the cost of continuing exceeds the expected value of what continuing might produce. It is the hardest decision in the founder's decision set because it requires separating identity from outcome, accepting the sunk cost, and making a choice that will be second guessed from every direction.
Founder Decision FrameworksThe Decision to Sunset a Product
Sunsetting a product means shutting it down permanently, migrating or releasing customers, and removing it from active development and support. Unlike sunsetting a feature, a product sunset affects all customers simultaneously and requires comprehensive communication, data export, and contract management. How a company shuts down a product tells customers and the market as much about the company's values as how it launched one.
Founder Decision FrameworksThe Decision to Sell the Company
Selling a company is an irreversible decision made under significant time pressure, information asymmetry, and emotional complexity. The buyer has done many acquisitions. The founder has done zero. The acquirer's legal team has reviewed hundreds of term sheets. The founder's lawyer may be seeing the first one. Understanding what the terms actually mean and what the alternatives are is the work that must happen before the negotiation begins.
Founder Decision FrameworksThe Decision to Sunset a Feature
Sunsetting a feature means removing functionality that currently exists and that at least some users depend on. Every feature removal creates a migration problem for those users and a trust question about whether the product will continue to evolve in ways that disrupt established workflows. Handled with notice and a real migration path, a feature sunset reduces maintenance burden and sharpens product focus. Handled as a surprise, it generates churn and damages the product's reputation for reliability.
Founder Decision FrameworksThe Decision to Build a Second Product
Building a second product is one of the highest risk decisions a SaaS founder can make. It splits the team's attention, the codebase's evolution, the go to market investment, and the customer support capacity. The founders who do it well treat the second product as a separate company with its own resources, not as a feature addition to the first product's roadmap.
Founder Decision FrameworksThe Decision to Productize a Service
Productizing a service means turning a repeatable workflow that you currently deliver manually for clients into a software product that delivers the same outcome automatically. The promise is leverage: a product can serve hundreds of customers simultaneously while a services business is limited by the number of hours its team can bill. The reality is that most services that seem productizable have enough variation per client to make true productization difficult.
Founder Decision FrameworksThe Decision to Add Enterprise Sales
Enterprise sales is a separate motion from self serve SaaS. It requires dedicated headcount, longer sales cycles, custom contracts, compliance documentation, and a product that can be customized to enterprise requirements. Adding it before you are ready is expensive and distracting. Adding it too late means leaving large contracts on the table while you wait for inbound to scale.
Founder Decision FrameworksThe Decision to Change Pricing
Changing pricing is one of the most impactful decisions a SaaS founder can make and one of the most avoided. The fear is losing customers. The reality is that underpricing costs more revenue than overpricing. A pricing change that is grounded in the value the product delivers, communicated clearly, and grandfathered appropriately for existing customers is achievable without customer churn.
Founder Decision FrameworksThe Decision to Remove a Free Plan
Removing a free plan means telling a portion of your user base that the product they have been using at no cost will now require payment. This is one of the most emotionally difficult decisions a founder can make and one of the most operationally complicated to execute. Done well, it filters for users who get real value from the product. Done poorly, it generates negative press, user backlash, and a lost acquisition channel.
Founder Decision FrameworksThe Decision to Add a Free Plan
Adding a free plan is a distribution decision, not a pricing decision. Done right, it creates a self serve acquisition channel where users try the product, see value, and convert to paid without needing a sales call. Done wrong, it fills your user base with people who will never pay, increases your support burden, and signals to serious buyers that the product is not worth paying for.
Founder Decision FrameworksThe Decision to Outsource Customer Support
Outsourcing customer support means transferring ticket resolution to a third party team that is not employed by the company. The economic case is clear: lower cost per ticket than internal headcount, coverage in time zones where the company does not have staff. The strategic risk is equally clear: the support team is where the company learns about product problems, and an outsourced team is a worse conduit for that feedback than an internal one.
Founder Decision FrameworksThe Decision to Hire Your First Operations Person
An operations hire owns the systems that keep the company running: vendor relationships, internal processes, compliance administration, finance operations, and the coordination work that does not fall cleanly to engineering or sales. The role is justified when the founder is spending more than 10 hours per week on operational tasks that are not strategic and could be owned by someone else.