The general-purpose thinking part of a computer that follows instructions in order.
Example: A slow report that does heavy calculations is usually waiting on the CPU.
Excel recalculating a big sheet
You paste 50,000 rows into a spreadsheet and the fan starts spinning. The CPU is stepping through every formula one after another. Buying more RAM will not help here; a faster CPU or a simpler formula will.
GPU
How computers work
A chip that does thousands of similar calculations at once, used for graphics and AI.
Example: Video editing and 3D games lean heavily on the GPU.
ChatGPT and Netflix both lean on GPUs
AI models are trained on thousands of GPUs because they do the same maths on huge batches of numbers at once. The same skill draws game frames 60 times a second.
RAM
How computers work
Fast short-term memory that holds whatever the machine is working on right now.
Example: Many open browser tabs fill RAM and slow the laptop down.
Chrome with 40 tabs open
Each tab keeps its page in RAM so switching is instant. When RAM runs out the laptop starts swapping to disk and everything feels sticky. Closing tabs frees it immediately.
Storage
How computers work
Long-term space (SSD or hard disk) that keeps files after the machine is switched off.
Example: Your photos survive a restart because they live in storage, not RAM.
Your phone saying 'Storage almost full'
Photos and videos sit in storage, so they survive a restart. That warning never appears because of RAM; it appears because the long-term shelf is full.
Operating system
How computers work
The software that shares the hardware between apps and enforces permissions.
Example: Windows, macOS, Linux, Android and iOS are operating systems.
iOS asking 'Allow camera access?'
The app cannot touch the camera by itself. iOS sits in between, shares the hardware and enforces the permission. That gatekeeping is the operating system's main job.
Process
How computers work
A running program with its own slice of memory.
Example: Each browser tab often runs as its own process, so one crash does not kill the rest.
One Chrome tab crashes, the rest survive
Chrome deliberately runs tabs as separate processes with separate memory. A broken page takes down its own process only, which is why you see 'Aw, snap' on one tab instead of losing everything.
File
How computers work
A named block of stored bytes, organised in folders.
Example: invoice.pdf is a file; the folder it sits in is just a label for grouping.
Emailing invoice.pdf
The PDF is a named block of bytes. The folder it sits in is only a label; when you attach it to an email, the bytes travel, the folder does not.
Variable
Programming basics
A named box that holds a value while the program runs.
Example: cartTotal = 1200 stores the number 1200 under the name cartTotal.
The cart total on Amazon
As you add items, a variable named something like cartTotal keeps changing value. Nothing is stored permanently yet — it is a labelled box that lives while the page is open.
Type
Programming basics
What kind of value something is: text, number, true/false, list and so on.
Example: The text "5" and the number 5 look alike but behave differently.
Phone number fields that reject letters
A form treats '9876543210' as text, not a number, so leading zeros survive. Mix the two up and 'total = quantity + price' can produce '25' instead of 7.
Boolean
Programming basics
A value that is either true or false.
Example: isPaid = true records that an order has been paid.
The dark-mode switch
darkMode is either true or false. Every toggle, checkbox and 'is the user logged in?' check in an app is this one tiny yes/no value.
Condition
Programming basics
A yes/no check that decides which path the code takes.
Example: If the total is above ₹999, shipping is free.
Free delivery above ₹499
Swiggy checks: if the order total is above the limit, delivery fee becomes zero, otherwise charge it. Business rules are mostly conditions written in code.
Loop
Programming basics
Repeating the same work for each item in a collection.
Example: Calculating tax once per line item on an invoice.
Instagram rendering your feed
The app receives 20 posts and repeats the same 'draw one post card' work for each of them. Nobody writes the card twenty times; a loop does it.
Function
Programming basics
A named, reusable recipe that takes inputs and returns a result.
Example: calculateTax(amount) can be used from every screen that shows a price.
Calculating GST in one place
Write calculateGst(amount) once and call it from checkout, invoices and reports. When the rate changes you edit one function instead of hunting through the whole app.
Array
Programming basics
An ordered list of values.
Example: [100, 250, 400] is an array of three prices.
Your Spotify queue
The queue is an ordered list: first song, second song, third. Reordering, adding to the end and 'play next' are all just array operations.
Object
Programming basics
A group of named values kept together.
Example: { name: "Asha", city: "Pune" } keeps related details in one place.
One customer record
Instead of three loose variables, you keep { name, email, phone } together as one object. Passing one customer around is safer than passing three pieces that can drift apart.
State
Programming basics
What is true in the app right now: who is signed in, what is in the cart.
Example: Two screens disagreeing about the cart count is a state bug.
The spinner that never stops
Almost every 'stuck loading' bug is a state bug: the code set loading to true and a failure path forgot to set it back. Thinking in explicit states — idle, loading, success, error — removes an entire family of bugs.
Language
The technology map
The syntax and rules you write instructions in.
Example: JavaScript, Python, Swift, Kotlin, Go and Rust are all languages.
Python for AI, Swift for iPhone apps
Teams pick a language for its ecosystem, not because it is 'best'. Instagram's backend runs Python; its iPhone app cannot, so it is written in Swift.
Library
The technology map
Reusable code you call to do one job.
Example: A date library formats '3 days ago' so you never write that logic.
Stripe's payment library
Nobody writes card handling from scratch. You install Stripe's library, call a few functions, and keep control of the rest of your app. You call the library; it does not call you.
Framework
The technology map
A structure for the whole app that calls your code at the right moments.
Example: You call a library; a framework calls you.
Airbnb's site built on React
A framework decides the overall structure — routing, rendering, file layout — and you fill in the pages. It calls your code, which is the opposite of a library.
Runtime
The technology map
The environment that actually executes your code.
Example: Browsers and Node.js are two different runtimes for JavaScript.
Node.js letting JavaScript run on a server
JavaScript was born inside browsers. Node.js is the runtime that lets the same language run on servers, which is why one developer can now write both sides.
Compiler
The technology map
A tool that translates source code into machine code before it runs.
Example: Go and Rust are compiled, which catches some mistakes before shipping.
Shipping an iPhone app to the App Store
Swift code is compiled into machine instructions before upload. That is why the download is an app binary, not readable source code, and why builds take minutes.
Package manager
The technology map
A tool that downloads and tracks third-party code.
Example: npm for JavaScript, pip for Python, Cargo for Rust.
npm install on a fresh laptop
One command reads your project's list of dependencies and downloads all of them with correct versions. Before package managers, teams copied folders by hand and versions silently drifted.
Lock file
The technology map
A record of the exact dependency versions used, so every machine builds the same.
Example: package-lock.json prevents 'works on my machine' surprises.
'It works on my machine' bugs
The lock file pins the exact version of every dependency, down to the sub-dependencies. Commit it and your laptop, your teammate's laptop and the server all install the identical set.
IDE
The technology map
An editor with built-in tools: error highlighting, navigation and debugging.
Example: VS Code, Xcode and Android Studio are common choices.
VS Code with autocomplete
The editor knows your project, suggests the next word, jumps to a definition and flags an error before you run anything. Same code, far fewer avoidable mistakes.
URL
How the web works
A web address made of a scheme, domain, path and optional query.
The address carries three things: which site, which page, and extra instructions after the '?'. Sharing a filtered search works because the filters live inside the URL.
DNS
How the web works
The system that turns a domain name into an IP address.
Example: Cached DNS answers are why a domain change can take hours to spread.
The Facebook outage of October 2021
Facebook, Instagram and WhatsApp disappeared for six hours. A configuration change withdrew the routes that made their DNS servers reachable, so the world could no longer look up their names. Staff could not even badge into buildings.
HTTP / HTTPS
How the web works
The rules for sending requests and responses on the web; HTTPS is the encrypted form.
Example: The padlock in the address bar means HTTPS is in use.
The padlock in your browser bar
HTTPS is the same conversation as HTTP, wrapped in encryption. On café Wi-Fi it stops anyone nearby from reading your password as it travels.
Request
How the web works
A message asking a server to read, create, change or delete something.
Example: GET /api/orders/42 asks to read one order.
Tapping 'Place order'
Your phone sends a request: here is the action, here is the cart, here is proof of who I am. Everything the server needs must be inside that one message.
Response
How the web works
What the server sends back: a status code and usually some data.
Example: 201 Created means a new record was made.
The order confirmation screen
The server answers with a status and data — order ID, delivery estimate. The screen you see is your app drawing that answer.
Status code
How the web works
A number summarising how a request went: 2xx ok, 4xx your fault, 5xx server's fault.
Example: 403 means signed in but not allowed.
404 as a brand moment
The 404 page became famous enough that companies design custom ones — GitHub's Star Wars parody, Google's broken robot. Behind the joke is a precise meaning: the server understood you, and that thing does not exist.
HTML
How the web works
The structure and content of a web page.
Example: Headings, paragraphs, buttons and forms are HTML.
Screen readers reading a news article
HTML marks what things are: heading, paragraph, button. Get that right and a blind user's screen reader and Google's crawler both understand the page for free.
CSS
How the web works
The presentation layer: colour, spacing, layout and responsiveness.
Example: Changing one CSS variable can restyle the whole app.
One 'dark mode' switch across a whole site
Colours, spacing and layout live in CSS, separate from the content. Change a handful of values and every page changes look without touching the text.
JavaScript
How the web works
The language browsers run to add behaviour to pages.
Example: Filtering a list as you type is JavaScript at work.
Google Maps panning without reloading
Drag the map and new tiles arrive while the page stays put. That live behaviour inside a page is JavaScript's job.
Browser
How the web works
The program that fetches web pages, renders them and runs their JavaScript.
Example: Chrome, Safari and Firefox each have their own rendering engine.
The same site on Chrome and Safari
The browser downloads your files, draws the page, runs your code and sandboxes it from the rest of the machine. Small differences between browsers are why teams test on more than one.
Component
Frontend
A reusable piece of interface with its own markup, style and behaviour.
Example: One Button component used on every screen keeps the app consistent.
Airbnb's design system
Airbnb, Shopify and Google all publish component libraries so hundreds of engineers build the same button. Change the component once and every screen updates — that consistency is what makes a big product feel like one product.
Routing
Frontend
Mapping a URL to a screen.
Example: /glossary shows the glossary page and can be shared as a link.
The back button on a modern web app
Routing maps a URL to a screen. Done properly, back, forward, refresh and sharing a link all behave the way people expect.
Responsive design
Frontend
One layout that adapts to any screen width instead of separate sites.
Example: Cards stack on a phone and sit side by side on a laptop.
Gmail on a phone versus a laptop
Same site, different arrangement: the sidebar becomes a menu, two columns become one. Not a separate mobile site — the same pages adapting to the width.
Form validation
Frontend
Checking user input and explaining clearly what needs fixing.
Example: 'Phone number needs 10 digits' beats 'Something went wrong'.
'Please enter a valid email'
The browser check is a courtesy for the user. The server must check again, because anyone can bypass the screen and send data directly.
Local state
Frontend
Data that only one component needs.
Example: Whether this dropdown is open right now.
An open dropdown menu
Whether the menu is open matters only to that one component and nobody else. Keeping it local means less code and fewer bugs than storing it globally.
API
Backend and data
A contract describing which requests a service accepts and what it returns.
Example: The app asks the API instead of touching the database directly.
'Sign in with Google' on any site
The site never sees your Google password. It talks to Google's API through an agreed set of requests and gets back only 'this person is verified, here is their email'.
JSON
Backend and data
A plain-text format of keys and values used to exchange data.
Example: {"id": 42, "paid": true}
The format that won
JSON came from JavaScript in the early 2000s and displaced the heavier XML almost everywhere. Open the network tab on nearly any site today and what flows back and forth is JSON.
Database
Backend and data
Organised, queryable storage for your application's data.
Example: Orders, customers and products each get a table.
Your order history still there next year
A database stores data in an organised way and finds a single row among millions in milliseconds. A pile of files cannot do that reliably while thousands of people write at once.
SQL
Backend and data
The language for asking questions of a relational database.
Example: SELECT city, COUNT(*) FROM orders GROUP BY city;
Fifty years and still standard
SQL was created at IBM in the 1970s and still runs banks, airlines and most of the web. Postgres, MySQL and SQLite all speak it. It is one of the few technical skills that has stayed valuable for an entire career.
Relationship
Backend and data
A link between tables, usually by storing an id.
Example: An order stores customer_id instead of repeating the customer's name.
One customer, many orders
Instead of repeating the customer's address on every order, each order points at the customer. Update the address once and every order is correct.
CRUD
Backend and data
Create, Read, Update, Delete — the four basic data operations.
Example: Most admin screens are just CRUD over one table.
Google Docs in four verbs
Create a doc, read it, update it, delete it. Strip almost any business app down and you find these four operations over some data.
Object storage
Backend and data
Cheap storage for large files, referenced from the database by link.
Example: Product videos and PDFs live here, not in a database column.
Netflix video files on Amazon S3
Big files live in object storage, cheap and endlessly expandable; the database only keeps a link to them. Storing videos inside a database would be slow and expensive.
Authorization
Backend and data
Deciding what a signed-in user is allowed to do.
Example: Only admins may issue refunds — checked on the server.
You cannot open someone else's Gmail
You are logged in (authenticated), but the server still checks whether this particular inbox is yours. Most serious data leaks are a missing authorization check, not a broken login.
Native app
Mobile apps
An app written with a platform's own tools and languages.
Example: Swift for iOS, Kotlin for Android.
The Instagram camera
Written specifically for iOS and Android, so it gets the smoothest gestures and full camera control — at the cost of building and maintaining two apps.
Cross-platform
Mobile apps
One codebase producing apps for several platforms.
Example: Flutter and React Native are two common options.
Google Pay built with Flutter
One codebase produces both the Android and iPhone app. You trade a little platform polish for roughly half the building and maintenance work.
WebView
Mobile apps
A browser window embedded inside an app shell.
Example: Capacitor wraps an existing web app for the app stores.
Terms and conditions inside an app
That screen is often a web page in disguise, wrapped in a browser window inside the app. Fine for content, noticeably slower for gesture-heavy screens.
Code signing
Desktop apps
Proving an app came from you and has not been tampered with.
A signature proves who built the app and that nobody tampered with it after. Let the certificate expire and your existing users can suddenly fail to launch or update.
Electron
Desktop apps
A way to ship a web app as a desktop app by bundling a browser engine.
Example: Bigger download, faster reuse of an existing web codebase.
Slack, VS Code and WhatsApp Desktop
All three are web apps wrapped in a desktop shell, which is why one team ships Windows, macOS and Linux together — and why they use more memory than a native app.
Game engine
Games
A toolkit providing rendering, physics, audio, input and an editor.
Example: Unity, Unreal and Godot are widely used engines.
Pokémon GO built in Unity
The engine already handles rendering, physics, input and sound. The team writes the game rules instead of rebuilding a graphics pipeline from nothing.
Game loop
Games
The cycle of reading input, updating the world and drawing a frame.
Example: At 60 fps the whole cycle must finish in about 16 milliseconds.
60 frames per second means 16 milliseconds each
Every frame: read input, update the world, draw it. Overrun that budget and players feel the stutter instantly, even if they cannot name what went wrong.
Git
Shipping software
Version control that records every change and lets you go back.
Example: Reverting a bad release takes minutes instead of hours.
Undoing a bad afternoon of work
Git keeps the full history of every change and who made it. You can go back to this morning's version in seconds instead of hunting for final_v3_FINAL.zip.
Commit
Shipping software
A saved point in history with a message describing the change.
Example: 'Fix tax rounding on invoices' is a useful commit message.
'Fix wrong GST on invoices'
One commit is one meaningful change with a message explaining why. Small, focused commits are what make it possible to find and undo a single bad change later.
Branch
Shipping software
A parallel line of work that does not disturb the main version.
Example: Build a feature on a branch, then merge it when ready.
Building checkout while the live site stays untouched
A branch is a safe side copy. You experiment, review it, and merge only when it works — the running product never sees your half-finished work.
CI/CD
Shipping software
Automated checks on every change, and automated deployment once they pass.
Example: Tests run, a preview deploys, then production updates.
Amazon deploying thousands of times a day
Every change automatically gets built, tested and shipped if the tests pass. That automation is why big teams release constantly instead of once a quarter.
Environment
Shipping software
A separate copy of the system: development, staging or production.
Example: Staging has its own database so tests never touch real orders.
Test payments versus real payments
Development, staging and production run the same code with different settings and keys. Mixing them up is how a test email gets sent to 50,000 real customers.
Secret
Quality and costs
A key, password or token that must never reach the browser or Git.
Example: Keep API keys on the server and rotate them if they leak.
GitHub scans public repositories for leaked keys
GitHub runs secret scanning across public code and notifies the provider when it spots something that looks like a live credential. Providers such as Stripe and AWS can then revoke the key automatically. It is a useful safety net, and a bad primary defence — plenty of leaks happen in private repos and chat screenshots that nothing scans.
Backup vs rollback
Quality and costs
A backup restores data; a rollback restores a previous version of the code.
Example: Lost orders need a backup — a code rollback will not bring them back.
Bad deploy versus deleted table
A rollback returns the code to yesterday's version in minutes. If the data is gone, only a backup helps — and an untested backup is not really a backup.
Logs
Quality and costs
The record an app writes of what it did and what failed.
Example: Logs turn a production mystery into a five-minute read.
'It broke at 3 PM but works now'
Without logs you are guessing. With them you find the exact request, the error and the affected user. Logs are the CCTV footage of your app.
Acceptance criteria
Working with AI agents
The observable result that proves a task is genuinely done.
Example: 'Submitting the form shows a confirmation and sends an email.'
The Denver airport baggage system
A famously ambitious automated baggage system delayed an airport by sixteen months and cost hundreds of millions, in large part because requirements kept shifting and nobody could say what 'done' meant. Small version, same lesson.
Hashing
Security and safety
Turning text into a fixed scrambled value that cannot be turned back.
Example: Passwords are stored as hashes, so even the company cannot read them.
The LinkedIn password leak of 2012
Six million LinkedIn passwords were stolen. They were hashed, but with an old, fast method and no salt, so attackers cracked most of them within days. The lesson the industry took: hashing alone is not enough — it has to be a slow, salted algorithm like bcrypt or argon2.
Authentication
Security and safety
Proving who you are, usually with a password, code or passkey.
Example: Logging in is authentication.
Signing in with Google
When a site offers 'Continue with Google', it is outsourcing authentication. Google proves who you are and tells the site. The site never sees your password, and you get one strong account to protect instead of fifty weak ones.
Authorisation
Security and safety
Deciding what an identified user is allowed to do.
Example: An admin can delete users; a customer cannot.
The intern with production access
Countless incident reports start the same way: someone was given admin because setting up narrower permissions felt like extra work. Authorisation is what decides whether a mistaken click deletes one row or the whole table.
Two-factor authentication
Security and safety
A second proof beyond the password, such as a code or a phone prompt.
Example: Turn it on for anything that controls money or code.
The 2020 Twitter account takeover
Attackers phoned Twitter staff, talked their way into internal tools and tweeted from Obama's and Musk's accounts. The chain started with credentials that a second factor would have made far harder to reuse. It is the single highest-value security switch you can flip.
HTTPS
Security and safety
An encrypted connection between the browser and the server.
Example: The padlock means nobody on the café wifi can read the traffic.
The café wifi problem
On open wifi, anyone nearby can watch unencrypted traffic and even inject content into it. HTTPS made that pointless, which is why browsers now mark plain HTTP pages as 'Not secure' and certificates became free through Let's Encrypt.
Key rotation
Security and safety
Replacing a secret key with a new one and disabling the old.
Example: The only real fix after a key leaks.
Stripe lets you roll a key and keep the old one alive briefly
In the Stripe dashboard you can roll an API key, which creates a replacement and lets you choose when the old one expires. That short overlap is what makes rotation practical — you update your configuration, confirm payments still work, then let the old key die.
SQL injection
Security and safety
An attack where user input is treated as database instructions.
Example: Prevented by using query parameters instead of glued-together text.
Little Bobby Tables
The famous xkcd comic has a student named 'Robert'); DROP TABLE Students;--'. It is a joke about a very real attack that has leaked millions of records from real companies. The prevention is boring and complete: parameterised queries.
XSS
Security and safety
An attack where someone else's text runs as code in your page.
Example: Escaping output stops a comment from running a script.
The Samy worm on MySpace
In 2005, a user embedded script in his profile that added him as a friend to anyone who viewed it, and copied itself to their profiles. Over a million infections in twenty hours. All of it because user content was rendered as code instead of text.
Least privilege
Security and safety
Giving each person, service or agent only the access it truly needs.
Example: A reporting script gets read-only access, not admin.
The Target breach of 2013
Attackers got in through a heating and air-conditioning contractor's credentials, then moved across the network to the payment systems. Forty million cards. A vendor account that could reach payment infrastructure is a least-privilege failure.
Schema
Databases and data
The shape of a database: tables, columns and how they relate.
Example: Adding a field means changing the schema.
Why an 'obvious' new field takes a week
Adding 'company name' to signup sounds like one text box. It touches the schema, the forms, the API, the invoices, existing rows that have no value, and every report. This is why developers ask questions about small-sounding fields.
Foreign key
Databases and data
A column that points at a record in another table.
Example: An order stores customer_id instead of copying the customer's details.
Your bank statement
Each transaction row points at your account rather than repeating your name, address and IFSC code. Change your address once and every future statement is correct — because they are relations, not copies.
Index
Databases and data
A lookup structure that makes searching a column fast.
Example: An index on email turns a nine-second search into milliseconds.
The book at the back of the book
Finding 'photosynthesis' in a 900-page textbook by reading every page takes an afternoon; the index takes five seconds. A database without an index literally reads every row. It is the single most common one-line fix for a slow page.
Migration
Databases and data
A recorded, repeatable change to the database structure.
Example: Adding a column ships as a migration, in version control.
GitLab's 2017 database incident
A tired engineer ran a destructive command on the wrong server and lost six hours of production data, then found five backup methods that all failed. Migrations and backups are process problems, not clever-people problems.
NoSQL
Databases and data
Databases that store flexible documents instead of fixed tables.
Example: Good for loose, fast-changing data; weaker guarantees for money.
MongoDB and the startup rush
Around 2010 many teams chose document databases for speed of iteration, then quietly moved money-related data back to Postgres once they needed guarantees. Both are good tools; the mistake was assuming one fits everything.
Transaction
Databases and data
A group of database changes that all succeed or all fail together.
Example: Money leaving one account and arriving in another must be one transaction.
Money moving between two accounts
Debit one, credit the other. If the power fails between the two, the money must not vanish. A transaction guarantees both happen or neither does. This is the property people mean when they say 'use a real database' for money.
REST
APIs and integrations
A common style of web API using HTTP methods and addresses.
Example: GET to read, POST to create, DELETE to remove.
The Stripe API
Stripe grew largely on the reputation of its API: predictable addresses, clear methods, honest status codes, excellent docs. It became the example developers cite for how much a good API is worth to a business.
Webhook
APIs and integrations
A call the other service makes to you when something happens.
Example: The payment provider tells your server the payment succeeded.
Stripe telling your server about a payment
You never poll Stripe asking whether the card cleared. Stripe calls your URL with a signed event the moment it does. Almost every payment, email and messaging platform works this way, and they all retry.
Idempotency
APIs and integrations
Doing the same operation twice has the same effect as doing it once.
Example: Stops a retried webhook from creating two orders.
The double-click checkout
An impatient customer clicks Pay twice. Without an idempotency key the second click is a second charge and a refund request. Payment providers built idempotency keys into their APIs specifically because this happens constantly.
Rate limit
APIs and integrations
A cap on how many requests you may send in a period.
Example: Exceeding it returns 429 until you slow down.
The Twitter API price shock
When Twitter changed its API limits and pricing in 2023, thousands of apps broke overnight. Rate limits are not just a technical detail — they are a business dependency you inherit from every provider you build on.
Pull request
Git and teamwork
A proposed change, shown as a diff, reviewed before merging.
Example: One intention per pull request keeps review real.
How Linux and every open-source project runs
Thousands of strangers contribute to projects like Linux and React without trusting each other. The pull request is the mechanism: propose, review in public, then merge. GitHub built a company on making that flow pleasant.
Merge conflict
Git and teamwork
Two branches changed the same lines, so a human must choose.
Example: Routine, and rare when branches are short-lived.
Two people, one paragraph
You and a colleague both edit the same function while working on different features. Git will not guess, so it marks both versions and asks. Teams that merge often see tiny conflicts; teams with month-long branches see nightmares.
Serverless
Cloud and infrastructure
Code that runs on demand and bills per request, with no server to manage.
Example: Ideal for traffic that is quiet most of the day.
Netflix and AWS Lambda
Netflix uses serverless functions for encoding pipelines and event handling that spike unpredictably. You get the same benefit at small scale: a hobby project can cost pennies until the day it is popular.
Container
Cloud and infrastructure
An app packaged with everything it needs, so it runs identically anywhere.
Example: Docker images end the 'works on my machine' argument.
Docker in 2013
Before containers, deployment meant matching library versions on every machine by hand. Docker packaged the app with its environment and made deploys repeatable. It is why 'works on my machine' stopped being an acceptable answer.
CDN
Cloud and infrastructure
A network of servers that keeps copies of your files near users.
Example: An image loads from Mumbai instead of Virginia.
Cloudflare in front of half the web
A large share of internet traffic passes through CDNs like Cloudflare and Akamai. They cache content close to users, absorb attack traffic, and are the reason a site hosted in one country feels fast worldwide.
Egress
Cloud and infrastructure
Data leaving your cloud provider, usually billed per gigabyte.
Example: The most common cause of a surprise cloud bill.
The bill nobody predicted
Storage is cheap and uploads are usually free; getting data out is where cloud providers charge. Teams serving large files without a CDN routinely discover a four-figure transfer line on a bill they expected to be small.
Latency
Performance and scale
The delay before a response starts arriving.
Example: Distance and slow queries are the two usual sources.
Amazon's 100ms study
Amazon found that every additional 100 milliseconds of latency cost roughly one percent in sales, and Google found half a second of extra delay dropped traffic noticeably. Speed is not polish; it is revenue.
N+1 query
Performance and scale
Fetching a list, then running one extra query per item.
Example: Fifty orders become fifty-one database round trips.
The dashboard with 340 queries
It is the most common performance bug in web apps, and it always hides in development because ten test rows mean eleven queries. With real data it becomes hundreds, and the page that felt instant now takes seconds.
Queue
Performance and scale
A waiting line of background jobs processed after the response.
Example: Signup returns instantly and the welcome email is sent later.
Email platforms queue sends instead of blasting them
When a campaign tool sends to a hundred thousand contacts, the messages go into a queue and out at a controlled rate. Sending them all in one burst would trip spam filters and overwhelm the receiving mail servers, so pacing is a feature, not a limitation.
Core Web Vitals
Performance and scale
Google's measures of loading, responsiveness and visual stability.
Example: LCP, INP and CLS — each maps to a real frustration.
Google making speed a ranking factor
In 2021 Google started using these measures in search ranking. Suddenly a marketing argument about page speed had a number attached to it, and layout that jumps while loading became a business problem, not a taste problem.
Token
AI, LLMs and agents
A word fragment; the unit a language model reads and writes.
Example: Cost and context limits are both counted in tokens.
Why the bill is bigger than you expected
Providers charge per thousand tokens, in and out. A long system prompt resent on every message, or a whole document pasted into each turn, multiplies quietly. Trimming context is usually the fastest way to cut an AI bill.
Context window
AI, LLMs and agents
How much text a model can consider at once.
Example: Long chats forget early instructions once it fills up.
The long chat that forgot the rules
You set careful instructions at the start of a session. Two hours later the model ignores them — not out of defiance, but because the earliest text no longer fits in what it can see. Restating key rules is the practical fix.
Hallucination
AI, LLMs and agents
A fluent, confident answer that is simply not true.
Example: An invented library function that looks entirely plausible.
The lawyer who cited imaginary cases
In 2023 a New York lawyer filed a brief containing six court cases invented by ChatGPT, complete with plausible citations. He was sanctioned. The output was fluent, formatted correctly and entirely fictional.
Embedding
AI, LLMs and agents
Text converted to numbers that capture meaning, for search by idea.
Example: 'Get my money back' finds the refunds page.
Spotify finding songs that feel similar
Recommendations work by placing items in a space where similar things sit close together. The same mathematics lets a support search understand that 'my card was declined' and 'payment failed' are the same question.
RAG
AI, LLMs and agents
Retrieving your own documents and letting the model answer from them.
Example: The standard way to make an assistant know your product.
Support bots that cite the help centre
Most company assistants you meet today are retrieval systems: they search the help centre, hand the top few articles to the model, and show you the links. When the policy changes, someone edits an article — nothing is retrained.
Local model
AI, LLMs and agents
A model that runs on your own machine instead of a provider's.
Example: Private and free to run, usually weaker than the best hosted models.
Ollama on a laptop
Open models like Llama and Mistral run on a decent laptop through Ollama or LM Studio. Hospitals, law firms and privacy-conscious teams use this to keep sensitive text off the internet entirely, accepting weaker output as the trade.
Agent
AI, LLMs and agents
A model given tools and a loop, so it can act and check results.
Example: Needs narrow permissions and a human on irreversible steps.
The agent that deleted a production database
Publicised incidents in 2025 involved AI coding agents running destructive commands on real data during unsupervised sessions. The pattern is always the same: broad permissions, no confirmation step, no backup rehearsal.
SSR
Modern web stack
Server-side rendering: the server sends finished HTML.
Example: Fast first view and visible to search engines.
Why e-commerce renders on the server
Shops need to be found in search and to show something instantly on a phone with a weak signal. Sending finished HTML does both. Amazon, Flipkart and most large shops render on the server for exactly these reasons.
TypeScript
Modern web stack
JavaScript with types, so mismatches are caught while writing.
Example: The cheapest safety net when an agent writes code.
Airbnb's 38% bug reduction
An Airbnb engineer's postmortem study estimated that TypeScript could have prevented around 38% of the bugs that reached production. That number is why the JavaScript world moved so quickly to types.
Build tool
Modern web stack
Software that turns source files into optimised files to ship.
Example: Vite also runs the dev server that refreshes as you type.
Waiting a minute to see a change
Older build setups rebuilt everything on every save, so developers waited. Vite and esbuild reduced that to milliseconds. The productivity gain is not vanity — feedback speed changes how carefully people can iterate.
Unit test
Testing and debugging
A tiny automated check that runs one function on its own.
Example: A test that checks the discount function returns 90 for 100 minus 10%.
The pricing function everyone is afraid of
Pricing code accumulates rules: discounts, taxes, currencies, promotions. Teams that put a few dozen unit tests on that one function can change it fearlessly for years, because a wrong total fails in under a second instead of on a customer's card.
End-to-end test
Testing and debugging
An automated test that drives the real app in a browser like a user would.
Example: A script that signs in, adds an item and checks out on every release.
One test that guards the money
Most small teams run exactly one or two end-to-end tests: sign in, buy something. They are slow and occasionally flaky, but they catch the catastrophic 'nobody can check out' bugs that no unit test can see, and they run automatically before every deploy.
Regression
Testing and debugging
Something that used to work and broke again after a later change.
Example: The discount bug returning three months after it was fixed.
Why the same bug returns
The Knight Capital trading firm lost around 440 million dollars in 45 minutes in 2012 partly because old code that should have been retired was reactivated by a deploy. Extreme, but the shape is ordinary: nothing was checking that the old behaviour still held.
Test coverage
Testing and debugging
The share of your code that tests actually run.
Example: 80% coverage with no test on checkout is worse than 30% with one.
The metric that lies politely
Coverage counts lines executed, not behaviour verified. A test suite can run 90% of your code and assert almost nothing. Teams that chase the number write useless tests; teams that use it as a hint look for uncovered code that would hurt if broken.
Stack trace
Testing and debugging
The list of function calls that led to an error.
Example: Reading it top-down shows the first line of your own code involved.
The line that names the file
Most people panic at a wall of red text. Experienced developers scan for the first line containing their own file path — the library above it usually failed because of something that line handed it. That single habit resolves a large share of everyday errors.
Reproduce
Testing and debugging
Making a bug happen reliably on demand.
Example: Creating a new account to trigger the failure new users reported.
The bug that only happened on Tuesdays
Support tickets that cannot be reproduced tend to be closed and then reopened forever. The unlock is almost always a pattern: one browser, one country, one timezone, new accounts only. Once you can trigger it on demand, fixing it is ordinary work.
Bisect
Testing and debugging
Halving the search space repeatedly until you find the cause.
Example: git bisect finds the exact commit that introduced a bug.
Finding the bad commit in seven steps
With a thousand commits since the last known good version, git bisect finds the offending one in about ten checks by halving the range each time. It is the clearest everyday proof that binary search is not just an interview question.
Breakpoint
Testing and debugging
A marker that pauses running code so you can inspect it.
Example: Pausing in the browser devtools to see what a variable holds.
Better than scattering print statements
Adding console logs everywhere is the beginner's debugger. A breakpoint in browser devtools pauses execution and lets you inspect every variable, step line by line and change values live — usually finding in one pass what twenty logs would take an hour to reveal.
Observability
Watching a live app
Being able to tell what a running system is doing from the outside.
Example: Logs, metrics and traces together make an app observable.
The plane with no instruments
Running an app without observability is flying in cloud with the instruments switched off. It is fine while nothing changes, and the moment something does you have no idea whether you are climbing or falling until you hit something.
Structured logging
Watching a live app
Writing logs as searchable fields rather than sentences.
Example: Logging userId and duration as fields lets you filter and chart them.
The difference between grep and answers
Logging 'Payment failed for order 4821' gives you a sentence to search. Logging fields — event, orderId, provider, errorCode, durationMs — lets you ask 'how many failures by error code in the last hour', chart it, and alert on it. Same effort, different capability.
Metric
Watching a live app
A number tracked over time.
Example: Requests per minute, error rate, or signups per day.
The four numbers Google watches
Google's SRE teams popularised the 'four golden signals' — latency, traffic, errors and saturation. Most systems, from a hobby app to a global service, can be watched sensibly with just those four before anything more elaborate.
Distributed trace
Watching a live app
A record of one request's journey through every service it touched.
Example: A trace showing 4 of 4.3 seconds were spent in one database call.
Where did the four seconds go?
A page feels slow. The trace shows the server responded in 90 milliseconds, but made 340 separate database calls in a loop. Without a trace, teams often spend days optimising the wrong layer entirely.
Alert fatigue
Watching a live app
Ignoring alerts because too many are false alarms.
Example: After twenty noisy pages, nobody checks the twenty-first.
The alarms nobody heard
In the Target breach of 2013, security tooling did fire warnings and they were not acted on among the noise. Every incident review of a noisy system reaches the same conclusion: an alert that is usually wrong is functionally the same as no alert.
Incident
Watching a live app
An unplanned event that degrades service for users.
Example: Checkout failing for eleven minutes after a deploy.
The six-hour Facebook outage
In October 2021 a configuration change took Facebook, Instagram and WhatsApp off the internet for about six hours — and disabled the internal tools and badge access engineers needed to fix it. The lesson that spread widely: your recovery path must not depend on the thing that is broken.
Postmortem
Watching a live app
A short blameless write-up of what happened and what will change.
Example: The outage report that added a smoke test to the deploy pipeline.
Blameless because blame hides information
Aviation transformed its safety record by making incident reporting non-punitive: pilots report near-misses because it is safe to. Software borrowed the idea directly. The moment a postmortem becomes about who erred, the next problem is quietly hidden.
Uptime
Watching a live app
The share of time a service is available.
Example: 99.9% uptime allows about 43 minutes of downtime a month.
What the nines actually cost
99% uptime is over seven hours of downtime a month; 99.9% is 43 minutes; 99.99% is four. Each extra nine multiplies the engineering effort, which is why sensible teams pick a target their customers actually need rather than the most impressive number.
Accessibility (a11y)
Accessibility and good UX
Designing so people with disabilities can use the product.
Example: Keyboard support, alt text and strong contrast.
The Domino's Pizza case
A blind customer sued Domino's in the US because he could not order using a screen reader. In 2019 the Supreme Court declined to hear the appeal, leaving the ruling against Domino's in place. Accessibility stopped being an optional nicety for consumer apps that day.
Screen reader
Accessibility and good UX
Software that reads a screen aloud for blind and low-vision users.
Example: It announces headings, links and buttons in page order.
Listening to your own page
Turning on VoiceOver or NVDA for five minutes is the fastest accessibility education available. Developers discover immediately that their icon-only buttons announce as 'button', their images as filenames, and their custom dropdown as nothing at all.
Alt text
Accessibility and good UX
A short description of an image for people who cannot see it.
Example: alt="Bar chart: sales doubled in June".
Alt text is not a caption
Good alt text conveys the meaning the image carries in that context. A chart's alt text is its conclusion, not 'chart'. Purely decorative images take empty alt text so screen readers skip them, which is better than announcing 'image-final-v3.png'.
Colour contrast
Accessibility and good UX
How clearly text stands out from its background.
Example: Light grey on white fails; dark grey on white passes.
The light grey trend
Around 2015 fashionable design pushed body text to light grey on white. It looked elegant on a designer's calibrated monitor and was unreadable on a phone in daylight. Contrast checkers became standard tooling largely as a reaction.
Focus ring
Accessibility and good UX
The visible outline showing which element the keyboard is on.
Example: Removing it makes an app unusable without a mouse.
The outline everyone deletes
'outline: none' is one of the most copied lines of CSS on the internet, and it makes an app unusable by keyboard because nothing shows where you are. The correct move is to style focus attractively, never remove it.
Semantic HTML
Accessibility and good UX
Using elements for their meaning, not just their looks.
Example: button, nav and h1 instead of styled divs.
Free behaviour you cannot rebuild cheaply
A real button handles Enter and Space, is reachable by Tab, is announced as a button, works with voice control and respects the operating system's settings. Recreating all of that on a div takes considerable code, and teams almost never finish the job.
WCAG
Accessibility and good UX
The international accessibility guidelines websites are measured against.
Example: AA level is the common legal and practical target.
The standard behind the laws
Most accessibility legislation — the European Accessibility Act, Section 508 in the US, and others — points at WCAG level AA rather than defining rules itself. Meeting AA is therefore the practical target for a commercial product.
Empty state
Accessibility and good UX
What a screen shows when there is no data yet.
Example: A new dashboard explaining what appears here and offering one action.
Slack's first workspace
Products known for good onboarding treat the empty state as a designed screen: what this will show, why it matters, and one button to create the first item. It converts the most fragile moment in the product from confusion into a small success.
Skeleton screen
Accessibility and good UX
Grey placeholder shapes shown while content loads.
Example: Grey bars where the list will appear, instead of a blank page.
Why grey boxes feel faster
Facebook popularised skeleton screens after finding that showing the shape of content made loading feel quicker than a spinner, even at identical speeds. Perceived performance is a real product lever, not a trick.
Webhook signature
Shipping to real users
A signed header proving a webhook really came from the provider.
Example: Verifying the Stripe signature before granting access.
Anyone can POST to your URL
A webhook endpoint is a public URL. Without signature verification, anybody who guesses it can send a fake 'payment succeeded' and upgrade themselves for free. Providers sign every request precisely so you can refuse the fakes.
Idempotent
Shipping to real users
Safe to run more than once with the same result.
Example: Processing the same payment event twice upgrades the account once.
The double-charged customer
Payment providers retry webhooks until they get a success response, so duplicate deliveries are normal, not exceptional. Storing processed event ids and ignoring repeats is the standard fix, and skipping it is one of the most common billing bugs in young products.
Merchant of record
Shipping to real users
The company legally selling to your customer and handling taxes.
Example: Paddle acts as merchant of record; with Stripe, you usually are.
Who owes the tax office
Selling software to a customer in Germany can create a VAT obligation. A merchant of record like Paddle or Lemon Squeezy sells on your behalf and takes that on, at a higher fee. With Stripe you keep more of the money and the paperwork.
Dunning
Shipping to real users
Retrying and chasing failed subscription payments.
Example: Emails and retries after a card expires.
The silent churn
A large share of subscription cancellations are not decisions — they are expired cards. Good retry schedules and clear emails recover a meaningful percentage of that revenue, which is why every serious billing system has dunning built in.
PCI DSS
Shipping to real users
The security standard for handling card data.
Example: Using a hosted payment form keeps you out of most of its scope.
The compliance you buy your way out of
Handling raw card numbers puts a business into the strictest tier of PCI DSS, with audits and network requirements. Using a hosted field or checkout means the card data never touches your servers, reducing the obligation to a short self-assessment.
Feature flag
Shipping to real users
A switch that turns a feature on or off without deploying.
Example: Releasing a new checkout to 5% of users first.
Big products ship unfinished features to production every day
Teams using tools like LaunchDarkly or PostHog feature flags merge work into the main codebase long before it is ready for customers, kept dark behind a switch. This avoids long-lived branches that become painful to merge, and it means turning a feature off is a dashboard click rather than an emergency deploy.
Activation
Shipping to real users
A new user reaching the product's first real value.
Example: Finishing a first lesson, not just signing up.
Facebook's seven friends in ten days
Facebook's early growth team famously found that users who reached seven friends within ten days stuck around. The number matters less than the idea: define the moment a new user first gets real value, and measure that instead of signups.
Retention
Shipping to real users
How many users come back after their first visit.
Example: Week-two retention is a better health signal than total signups.
The only chart investors read twice
Signups can be bought; retention cannot. A cohort chart showing what share of each month's new users are still active later is the clearest single picture of whether a product actually works.
Permissive licence
Shipping to real users
A licence letting you use code commercially with attribution.
Example: MIT, Apache 2.0 and BSD.
Why React and Vite are safe to build on
React is MIT-licensed and Apache 2.0 covers many major tools. You can build a closed commercial product on them, provided you keep the licence notice. This is why permissive licences dominate the web ecosystem.
Copyleft licence
Shipping to real users
A licence requiring derived work to use the same licence.
Example: GPL, and AGPL which extends this to hosted services.
The AGPL clause that surprises founders
Ordinary GPL obligations trigger when you distribute software. AGPL extends them to running it as a network service — which is exactly what a SaaS does. MongoDB shipped under AGPL for years for that reason, then in 2018 decided even AGPL was too easy for cloud vendors to route around and wrote the stricter SSPL instead.
GDPR
Shipping to real users
European rules on collecting and handling personal data.
Example: Consent for tracking, and deleting data on request.
The cookie banners came from here
GDPR made consent and data minimisation legal requirements across Europe, with fines that scale to revenue. The practical takeaway for a small product is simple: collect the least data you can, say what you collect, and be able to delete it.
Parameters
How AI models are made
The learned numbers inside a model; '7B' means seven billion of them.
Example: A 7B model needs about 14 GB of memory at 16-bit precision, 2 bytes per parameter.
Why the number in the name matters
When teams compare '7B' and '70B', they are mostly comparing hardware bills. The 70B needs roughly ten times the memory and a serious GPU, while the 7B runs on a laptop. Capability does rise with size, but a well-trained small model often beats a poorly trained large one, so the number is a cost signal first and a quality hint second.
Pretraining
How AI models are made
The huge first training stage where a model learns language by predicting the next token on enormous amounts of text.
Example: Months of GPU time and millions of dollars — done by a handful of organisations.
The stage nobody you know will ever do
Pretraining a frontier model costs tens of millions of dollars in GPU time. This is why the industry has a small number of base models and thousands of variants built on top of them — almost every 'new model' you read about is someone else's pretraining plus a cheap fine-tune.
Fine-tuning
How AI models are made
Continuing training on a small set of examples to teach a style, format or narrow skill.
Example: Teaching a model to always reply as a short support message with a ticket number.
The right tool, used for the wrong job
Support teams often fine-tune a model on their help articles and are disappointed. The model starts sounding right but still invents details, and goes stale the moment a policy changes. The successful version of the same project uses retrieval for the facts and fine-tuning only to lock in the reply format.
RLHF
How AI models are made
Reinforcement learning from human feedback: people rate answers and the model is nudged towards the preferred kind.
Example: Where a model's tone, refusals and 'I am not sure' behaviour mostly come from.
Where a model gets its manners
The difference between a raw pretrained model and a chat assistant is startling: the raw one continues your text instead of answering it. Human preference training is what turns it into something that answers questions, refuses harmful requests and admits uncertainty.
Model card
How AI models are made
The README of a model page: what it is for, what it was trained on, limits and licence.
Example: Checking the licence line before building a paid product on an open model.
The two minutes that saves a launch
Teams have shipped products on models whose licence forbade commercial use at their scale, and found out during due diligence. Reading the model card's licence and intended-use lines before building costs nothing; discovering it later can mean re-testing an entire feature on a different model under deadline.
Open weights
How AI models are made
A model whose learned parameters you can download and run yourself — not necessarily open source.
Example: Running an open model on your own machine so private data never leaves it.
The hospital that could not use a cloud API
Clinics and law firms often cannot send client data to a third-party API for regulatory reasons. Open-weight models make the feature possible at all: the model file sits on their own server, answers never leave the building, and compliance becomes a hardware question instead of a blocker.
Inference
Running AI yourself
Actually running a trained model to get an answer, as opposed to training it.
Example: Every chat message you send is one inference request.
Training is once, inference is forever
For most companies, inference is the real cost line. A model is trained or chosen once, then runs millions of times. This is why so much engineering effort goes into caching, batching and quantisation — small per-request savings multiplied by every user, every day.
VRAM
Running AI yourself
The GPU's own memory; the whole model must fit in it to run at full speed.
Example: A 4-bit 7B model fits in about 4 GB, so it runs well on an 8 GB card.
The number that decides which model you can use
Every 'can we run this locally' conversation reduces to VRAM. Parameters times bytes per parameter, plus room for context. Teams that do this arithmetic before buying hardware avoid the very common outcome of a machine that technically runs the model at two tokens per second.
Quantisation
Running AI yourself
Storing each parameter with fewer bits (8-bit or 4-bit) so the model needs far less memory.
Example: Turning a 14 GB model into a 4 GB one with a small quality loss.
What made local AI practical
Four-bit quantisation is the single change that moved capable models from data centres to laptops. The quality loss is usually small enough that people cannot pick the difference in ordinary use, while the memory requirement drops by roughly four times.
KV cache
Running AI yourself
Stored intermediate values for tokens already processed, so each new token does not recompute the whole context.
Example: It keeps long answers fast, but grows in VRAM with context length and users.
The out-of-memory error that appears mid-conversation
A model loads fine and answers quickly, then crashes after a long chat. The weights were never the problem — the KV cache grows with every token and every simultaneous user until the card is full. Serving stacks exist largely to manage this memory carefully.
Tokens per second
Running AI yourself
How fast a model writes its answer, separate from how long the first word takes.
Example: Forty tokens per second feels instant; two feels broken.
Two different complaints about 'slow'
Users saying an assistant is slow usually mean one of two things: a long pause before anything appears (time to first token, driven by prompt length) or words trickling out (tokens per second, driven by hardware and model size). The fixes are completely different, so it is worth asking which one they mean.
Batching
Running AI yourself
Serving many requests together in one GPU pass to raise total throughput.
Example: A serving stack answering thirty users at once for barely more than the cost of one.
Why hosted AI is cheaper than your own GPU at low volume
A provider keeps its expensive GPUs saturated by batching thousands of customers' requests together. Your own GPU serving a handful of users is idle most of the time, paying full price for a fraction of the work — which is why self-hosting only wins at steady, heavy usage or when data cannot leave.
Prompt caching
Running AI yourself
Reusing a repeated fixed part of your prompt so it is billed and processed cheaper.
Example: A 3,000-token system prompt sent on every message, cached instead of re-charged.
Halving a bill without changing an answer
Products with long system prompts — style guides, tool descriptions, policies — resend the same thousands of tokens on every request. Turning on prompt caching bills that fixed prefix at a fraction of the rate, cutting costs substantially with zero change to output quality.
AI app builder
AI-native building & agents
A tool that turns a written product brief into editable application screens and code.
Example: Building a signup prototype in hours, then reviewing ownership and tests before launch.
A fast demo with an exit door
A founder validates demand in a day, then checks source export, data ownership and rollback before investing further.
Coding agent
AI-native building & agents
An AI system that can inspect a codebase, use development tools, edit files and verify work.
Example: Codex or Claude Code updating a dependency and running the affected tests.
A capable contractor, not an approver
The agent changes twenty files and runs tests, while protected production and a human review remain outside its authority.
Context engineering
AI-native building & agents
Selecting and organising the instructions, files, memory and tool results an AI needs for one task.
Example: Giving an agent the checkout files and acceptance tests instead of the whole repository.
Less context, better signal
A focused folder, project rules and acceptance checks outperform dumping a large contradictory repository into one prompt.
MCP
AI-native building & agents
Model Context Protocol: a standard interface through which AI clients discover tools and resources.
Example: One read-only documentation connector available to several coding agents.
A universal socket is not a lock
MCP makes tools portable across clients, but each server must still authenticate, validate and restrict every operation.
Tool calling
AI-native building & agents
A model proposes structured arguments for an application function to validate and execute.
Example: An assistant proposes searchOrders({orderId}), then code checks permission before running it.
Proposal first, execution second
The model outputs structured arguments; ordinary code checks schema, ownership and permission before any side effect.
Prompt injection
AI-native building & agents
Untrusted content attempts to override an AI system's instructions or misuse its tools.
Example: A document tells an agent to upload secrets; policy blocks secret access and external requests.
The résumé that gave orders
A file can contain hostile instructions. Treating retrieved text as data and denying broad tools prevents those words becoming authority.
Evaluation set
AI-native building & agents
A versioned collection of representative tasks and expected qualities used to compare AI changes.
Example: Thirty real Hindi support questions run before changing the model or prompt.
Your benchmark beats the internet's
A small set of your real Hindi queries catches regressions that impressive public coding scores cannot predict.
SPF
Growth-ready product operations
A DNS record listing the servers allowed to send email for a domain.
Example: Authorising your email provider to send receipts from a product subdomain.
The authorised sender list
Without SPF, receivers cannot confirm that your email provider is allowed to speak for your domain.
DKIM
Growth-ready product operations
A cryptographic signature that lets receivers verify an email came from the claimed domain unchanged.
Example: A mailbox verifies the receipt signature using the public key in DNS.
A seal mailboxes can verify
DKIM proves domain responsibility for a message and helps receivers distinguish genuine receipts from altered mail.
DMARC
Growth-ready product operations
A domain policy for handling email that fails SPF or DKIM, with aggregate reports.
Example: Starting in report-only mode before asking mailboxes to reject spoofed mail.
Turn authentication into policy
DMARC reports reveal spoofing and alignment problems before you gradually move from monitoring to enforcement.
Canonical URL
Growth-ready product operations
The preferred address for a page when the same content appears at several URLs.
Example: Consolidating tracking and print URLs onto the main guide URL.
One article, one official address
A canonical consolidates duplicate campaign and print URLs instead of making search systems guess.
Structured data
Growth-ready product operations
Machine-readable labels describing visible entities and facts on a page.
Example: Marking visible product price and availability with the matching schema.
Labels, not magic rankings
Truthful markup helps machines interpret visible content; invented ratings are spam and can remove eligibility.
Internationalisation (i18n)
Growth-ready product operations
Designing software so languages and locale rules can be added without rebuilding it.
Example: Keeping interface text outside components and using locale-aware number formatting.
Prepare the product before translating
Locale-aware formats and externalised text keep a new language from becoming a rewrite.
Localisation (l10n)
Growth-ready product operations
Adapting a product for a specific language and locale, including text, formats and layout.
Example: Hindi copy with Indian currency, dates and enough room for longer labels.
More than replacing words
Currency, dates, plurals, sorting and layout make a Hindi experience feel native rather than pasted on.
Unicode
Growth-ready product operations
The common character standard used to represent scripts, symbols and emoji in software.
Example: Preserving Devanagari names through signup, search and export.
Names are not ASCII
Unicode-safe storage and validation preserve Indic scripts across forms, search and exported backups.
DPDP
Growth-ready product operations
India's Digital Personal Data Protection framework for processing people's digital personal data.
Example: Giving a clear notice, collecting only needed fields and providing correction and deletion paths.
Privacy becomes a product flow
Notice, purpose, safeguards and usable rights must exist in the interface and operations, not only a policy page.
Data minimisation
Growth-ready product operations
Collecting only personal data necessary for a stated product purpose.
Example: Not requesting a birth date when age has no role in the service.
The safest field is one never collected
Removing unused personal data reduces breach harm, compliance work and user distrust at once.
Chunking
AI, LLMs and agents
Splitting documents into smaller passages before embedding, so retrieval returns the useful piece instead of a whole file.
Example: A 40-page handbook is chunked into 300-word sections; the leave-policy chunk is what actually gets retrieved.
The needle was in the wrong haystack
One giant chunk per document buried the answer in noise; sane chunk sizes with a little overlap made retrieval precise.
Stale embeddings
AI, LLMs and agents
Vectors computed from an older version of a document that no longer match its current text.
Example: The pricing page changed last week, but search still answers from last month's embedded copy.
The answer from last month
A re-embed job tied to content publish keeps the index honest — otherwise search confidently serves retired facts.
Retrieval miss
AI, LLMs and agents
When the right answer exists in your data but the search step never surfaces it, so the model answers without it.
Example: The refund rule is in the docs, yet the bot says 'no information' because the query wording never matched that chunk.
Check the search before blaming the model
Logging which chunks were retrieved for a bad answer usually reveals the model never saw the right one.
Hallucinated citation
AI, LLMs and agents
A confident answer that points to a source that does not exist or does not say what is claimed.
Example: The bot quotes 'Policy 4.2(b)' — a section nobody ever wrote.
Trust, then verify the footnote
Answering only from retrieved chunks — and linking the real chunk — turns invented references into checkable ones.
Hybrid search
AI, LLMs and agents
Combining keyword search with vector similarity, so exact terms and meaning both count.
Example: Searching 'SKN-2041 error' needs the exact code matched literally, not just semantically similar text.
Exact words and meaning, both
Error codes, SKUs and names fail under pure vector search; keyword matching catches what similarity smooths over.
Re-ranking
AI, LLMs and agents
A second pass that reorders the first search results, putting the genuinely relevant passages on top.
Example: The first pass returns 20 chunks; the re-ranker pushes the one that actually answers the question to position 1.
Cheap first pass, smart second pass
Retrieving 20 and re-ranking to 3 beats trying to make the first pass perfect.
Vector database
AI, LLMs and agents
A store built to keep embeddings and find the nearest ones fast.
Example: pgvector, Qdrant and friends answer 'which chunks are closest to this question' in milliseconds.
Start where your data already lives
pgvector inside your existing Postgres carries most small products far; a dedicated vector DB earns its place at scale.
Agent loop
Working with AI agents
The repeat cycle of plan, act with a tool, read the result, and decide the next step.
Example: The agent edits a file, runs the tests, reads the failure, and tries a fix — that is one loop iteration.
The loop needs an exit
A maximum step count and a 'stop and ask' condition keep a confused agent from burning budget in circles.
Guardrails
Working with AI agents
Hard limits around an AI feature: what it may read, what it may do, and what always needs a human.
Example: The support bot can draft refunds up to ₹500; anything above goes to a person.
Limits written in code, not in prompts
A prompt can be talked around; an enforced permission check cannot.
System prompt
Working with AI agents
The standing instructions that frame how a model behaves before the user says anything.
Example: 'You are a billing assistant; never reveal other customers' data' sits in the system prompt, not the chat.
Instructions are not armour
The system prompt shapes behaviour, but anything retrieved can still try to override it — hence data stays data.
Diff review
Working with AI agents
Reading the exact line-by-line changes an agent made instead of trusting its summary.
Example: The agent said 'small fix', but the diff shows it also renamed a config key used in production.
Read the diff, not the summary
The summary is marketing; the diff is the contract. Reviewing it catches the rename the agent forgot to mention.
Tool permission
Working with AI agents
The scope of what an agent's tools are allowed to touch — files, networks, credentials, deploys.
Example: Read access to the repo, no access to production secrets, and no shell on the live server.
Least privilege for robots too
An agent with read-only access cannot leak what it cannot reach — scope tools before giving them work.
Environment variable
Security and safety
A named setting the app reads when it starts, supplied by the machine rather than written into the code.
Example: DATABASE_URL points at a local database on a laptop and at the real one on the server, with no code change.
The same app runs on your laptop and on Vercel
On a laptop a Next.js project reads settings from a local .env file. Deployed to Vercel, the identical code reads the same names from the project's environment settings page. Nothing in the code knows the difference, which is exactly the point: one codebase, different values per place it runs.
Staged rollout
Shipping software
Turning a feature on for a growing share of users — you, then a few, then everyone — instead of all at once.
Example: A pricing change goes to 5%, then 25%, then everybody once the numbers hold.
App stores roll updates out in percentages
Google Play's staged rollout lets you release a new Android version to 1% of users, watch the crash rate, and then widen to 10%, 50% and 100%. If crashes spike, you halt the rollout and most of your users never received the bad build at all.
Background job
Backend and data
Work the server does after replying to the user, so slow tasks never make a page wait.
Example: Clicking Export returns instantly, and the finished file arrives by email a minute later.
Your bank statement PDF arrives by email, not instantly
Ask a bank app for a two-year statement and it does not freeze while building the file. It accepts the request, tells you it is being prepared, and emails it when done. The wait is the same, but the app stays usable and the request cannot time out.
Cron
Backend and data
A schedule that runs a task at fixed times, such as every night or every Monday.
Example: A cron entry runs the database backup at 3am daily.
Cron syntax is decades old and still everywhere
The five-field schedule format — minute, hour, day, month, weekday — comes from Unix and survives unchanged in GitHub Actions, Vercel Cron, Supabase's pg_cron and Kubernetes. Learning to read `0 3 * * *` as '3am every day' pays off across almost every tool you will touch.
Idempotency key
Backend and data
A unique id sent with a request so that repeating it does the work once, not twice.
Example: A retried payout carries the same key, so the provider returns the original transfer instead of paying again.
Stripe requires one on retried charges for a reason
Stripe's API accepts an Idempotency-Key header on payment requests. If the network drops after the charge succeeds but before your server hears back, your retry carries the same key and Stripe returns the original charge instead of taking the money twice. Without it, retries and double charges are the same thing.
Runbook
Git and teamwork
Step-by-step instructions for handling a specific failure, written for someone half-awake at 2am.
Example: When the site goes down, the on-call person follows the runbook instead of guessing.
Google's SRE practice treats runbooks as required
In Google's site reliability engineering approach, a service is not considered ready for on-call support until it has playbooks for its known failures. The reasoning is measurable: engineers following a runbook resolve incidents far faster than engineers reasoning from scratch at 3am.
Decision log
Git and teamwork
A short record of what the team chose, what it rejected, and why — one paragraph per decision.
Example: Six months later, nobody has to re-argue why the team did not switch databases.
Architecture Decision Records are a one-page habit
Many teams keep ADRs — short numbered markdown files in the repository, one per significant decision, covering context, the choice, and the consequences. They take ten minutes to write and settle the 'why did we do it this way?' question months later, especially after the people involved have moved on.