An airline announcing Starlink doesn’t mean your flight has Starlink.

That’s the mistake thousands of travelers make every week.

Airlines announce deals.

Planes get upgraded one aircraft at a time.

Your ticket is for one specific aircraft, not for a press release.

After auditing 235 airlines, I realized there was no easy way to know whether your specific flight would actually have Starlink or an older satellite system. That’s why I built FlightWifi, a free tool that shows flight Wi-Fi quality directly inside Google Flights before you book. This article is the dataset behind it.

The audit used only official airline documentation and connectivity-provider announcements, never aggregator blogs. Here is what it says about in-flight internet in mid-August 2026, starting with the quick version:

The rest of this guide is the detail behind that table, and the traps it can’t show.

The full-coverage club: every plane (or every plane of a type) has it

These are the airlines where you don’t need luck. If you’re on the aircraft type listed, Starlink is there.

• Qatar Airways: the entire Boeing 777, Airbus A350 and 787–8 widebody fleet is done. The 787–9s finish before end of 2026, the A320s come last. Free for everyone.

• Hawaiian Airlines: every Airbus A330 and A321. Free (a free Atmos Rewards account is required since July). The 787s get theirs from fall 2026.

• WestJet: the whole 737 narrowbody fleet, finished back in 2025. The 787–9s are being fitted through end of 2026. Free for WestJet Rewards members.

• Virgin Atlantic: all 12 A350s since June 2. Free for Flying Club members. The 787s and A330s are still on the old paid Viasat until their retrofits.

• airBaltic: the entire A220 fleet. Free for every passenger from boarding, no account, no tier. The quiet European pioneer.

• ZIPAIR: the whole 787 fleet, and it has been there longer than almost anyone. Free for all.

• Air Canada (Jazz): 25 Dash 8–400 turboprops on the Billy Bishop Toronto routes. Free for Aeroplan members.

The coin-toss tier: real Starlink, but whether YOUR plane has it is chance

This is the tier that generates the viral praise and the angry follow-up posts. The system is genuinely flying, on some of the planes.

• United: about 522 of 1,817 aircraft as of this week, converting 40 to 50 more every month. All regional jets are done, 1,000 aircraft targeted by end of 2026, widebodies complete by summer 2027. Free with a MileagePlus account.

• Emirates: 33 Boeing 777s and 3 A380s as of July, heading for around 150 aircraft by end of 2026 and the full 232-strong widebody fleet by mid-2027. Free in all cabins on fitted planes.

• Air France: 28 of 31 777–300ERs, 30 of 41 A350s, 45 of 56 A220s, 24 of 30 E190s, but only 3 of 28 A320s as of June. Completion expected end of 2026. Free with Flying Blue.

• SAS: live since March, A320 family first, remaining types through Q4 2026. Free for EuroBonus members, with quoted speeds above 500 Mbps.

• Southwest: rolling since June, targeting about 300 of its 800+ 737s by end of 2026. Free for Rapid Rewards members, $8 for everyone else.

• Alaska Airlines: every E175 regional jet plus about 50 mainline 737s so far, 787s from fall 2026. Free with a free Atmos Rewards account, sponsored by T-Mobile.

• Aer Lingus: flying since March 29. All Shannon transatlantic A330s are equipped and the airline now targets 100% of long-haul by end of 2026. Free for everyone on fitted aircraft.

• Iberia: first revenue Starlink flight on June 23, Madrid to São Paulo. Free in every cabin on fitted aircraft.

• British Airways: five 787s since March. Installations paused for the summer schedule and resume in October. Free on those five, paid legacy Wi-Fi on the rest.

• Copa Airlines: first aircraft in July, full fleet targeted by Q1 2027. Paid in economy, free in business and for top-tier ConnectMiles.

• Gulf Air: progressive rollout since May. Free, unlimited, gate to gate, for every passenger on fitted aircraft.

• Air New Zealand: a domestic trial, including the world’s first Starlink ATR 72 turboprop. Most of the domestic fleet is not yet fitted.

Signed, announced, celebrated, and not carrying a single passenger yet

Every airline below has a real Starlink contract. None of them will give you Starlink if you book today.

• Lufthansa Group: the biggest deal of all, 850+ aircraft across Lufthansa, SWISS, Austrian, ITA, Brussels, Eurowings and Edelweiss, phased through 2029. The very first aircraft, an A320neo, enters service this week (August 19). Everything else is still the old FlyNet.

• Korean Air: Starlink hardware has been going onto A350s since July, but the service is not switched on for passengers yet. The group deal also covers Jin Air, Air Seoul and Asiana, none flying it either.

• Singapore Airlines: around 53 A350s and A380s, installations start Q1 2027, completing 2029.

• flydubai: my favorite cautionary tale. It announced Starlink, and in the meantime it removed its old Wi-Fi entirely. A flydubai flight today has no internet at all.

• El Al (2027), Frontier (installs from early 2027, no Wi-Fi at all today), Wizz Air (installs 2027), Volaris, JetSMART, Cebu Pacific (all 2027), Vietjet (signed in May, no date announced).

The biggest lie in airline Wi-Fi

Your phone shows full Wi-Fi bars.

Your messages do not send.

Because the “Wi-Fi” isn’t connected to the internet. It’s a movie server.

This is the most common trap in the entire dataset. Dozens of airlines advertise “Wi-Fi onboard” that is a local streaming network: films, a menu, a moving map, and no connection to the ground at all. easyJet, Ryanair, IndiGo, Vietjet, Volotea, Aeroflot and many others fall in this bucket today. Aggregator sites list them all as “has Wi-Fi.” No airplane Wi-Fi lie is told more often than this one.

Fast without Starlink

Starlink isn’t the only low-orbit game in airline Wi-Fi. Amazon’s Kuiper reaches JetBlue from 2027. Eutelsat OneWeb capacity is already flying in multi-orbit setups at Avianca (since December 2025), Air Arabia (since March 2026) and Discover Airlines, with LATAM’s narrowbodies next. SES’s mid-orbit O3b mPOWER is coming to Thai Airways and Air Astana. And to be fair to the old guard: Delta, American, JetBlue and Qantas all run modern high-orbit systems that are perfectly fine for mail and browsing, just not for a video call.

I built the tool I wish existed

Every time I booked a flight, I ended up researching the same questions:

• Does this exact aircraft have Starlink, or the older satellite?

• Is the Wi-Fi on this plane actually usable for work and video calls?

• Is this airline halfway through a rollout, where my plane is a coin toss?

• Is the “Wi-Fi” even connected to the internet?

Eventually I got tired of repeating that research for every booking.

So I built FlightWifi. It adds the answer directly into Google Flights (and Skyscanner and Soar) before you book: an aircraft-specific verdict on every flight, from “video calls work” to “no Wi-Fi”, with the source behind every claim one hover away. Knowing your Wi-Fi before booking takes zero extra clicks, and it’s free.

Want to check your own flight?

Explore FlightWifi.app to see airline, aircraft, provider and Starlink Wi-Fi data, or install the tool on Chrome web store to see the verdict directly inside Google Flights.

Method: every claim above comes from an official airline page, an official provider announcement (SpaceX, Viasat, Panasonic, Intelsat, SES, Anuvu, SITA) or established aviation trade press, checked airline by airline in August 2026. Rollout counts change weekly on the fast movers, and this article reflects mid-August 2026. If you spot something that has since changed, tell me and I’ll correct it.

And then you sit there reading it with a slowly sinking feeling.

Some of this is genuinely good. Some of it is quietly wrong. And you cannot tell which is which without doing most of the work yourself, which was the entire thing you were trying to avoid.

Here is the uncomfortable part: that is not a prompting problem. You will not fix it with a better prompt. You could write the greatest prompt in human history and still get a confident blob you have to fact-check line by line.

It is an architecture problem. And it has a fix with a slightly intimidating name.

Graph engineering.

One worker versus a small team

A single chat session is one person doing everything at once.

That one person is simultaneously planning the work, researching it, writing it, checking it, and deciding when it is done. If you hired a human like that, you would not be surprised when quality wobbled. You would not ask one employee to be the strategist, the analyst, the writer, and the quality reviewer, and then also be the person who signs off on their own performance review.

But that is exactly what a single prompt does.

Graph engineering is the alternative. Instead of one prompt doing everything, you break the work into a set of connected jobs, each with one responsibility, wired together with logic, passing information between them.

That is it. That is the whole idea. Everything else is detail.

The three pieces: jobs, arrows, and state

A graph has three parts, and the third one is where the magic actually lives.

Jobs are the boxes. Each one is a unit of work with a single responsibility. “Research how competitors price this.” Not “build my business.” A job should be small enough that you could describe what a good output looks like in one sentence. If you cannot, it is not one job, it is three wearing a trench coat.

Arrows are the logic between the boxes. Sometimes an arrow just means “then do this next.” Sometimes it is conditional: if the checker rejects it, go back. Sometimes one job fans out to three, and three fan back into one.

State is what travels along the arrows. This is the part people skip, and it is the part that makes the whole thing work.

In a normal chat, state is invisible. It is just the conversation history, an ever-growing pile of everything that has been said, dragged along into every new turn whether it is relevant or not. That pile is why long sessions get dumber. The model is trying to hold every stray comment, every abandoned idea, and every apology from forty messages ago in mind at once.

In a graph, state is explicit. Each job receives a defined input and produces a defined output, and that specific thing is what moves forward. The researcher does not need to know what tone you argued about in message six. It needs the question and the constraints. That is all.

Explicit handoffs are the difference between a team with a process and a group chat.

Quick detour: this is not a knowledge graph

The word “graph” is overloaded, so let us clear this up fast.

A knowledge graph maps relationships between things. This customer bought that product. This paper cites that paper. This concept relates to that one. It is about how data connects.

An agent graph, which is what we are talking about, maps how work moves between specialized workers. A planner hands to a researcher. A researcher hands to a skeptic. A skeptic hands back or hands forward.

Same word, different job. Knowledge graphs organize facts. Agent graphs organize labor.

The Diamond, and why it beats your best prompt

The most useful pattern to learn first is shaped like a diamond. It starts narrow, gets wide, then gets narrow again.

One question
                     |
        +------------+------------+
        |            |            |
   Research A   Research B   Research C
        |            |            |
        +------------+------------+
                     |
              Skeptic / Checker
                     |
              Recommendation
                     |
              Human approval

Read it top to bottom.

One question at the top. You frame the actual problem. Not a vague vibe, a real question with a real decision attached to it. Most bad AI output traces back to a fuzzy question, and no amount of downstream cleverness rescues it.

It splits into parallel research paths. Three separate investigations, running independently, each pursuing its own angle without seeing what the others are doing.

That independence is the entire point. When one chat session explores a problem, it commits to its first plausible idea within about two paragraphs and then spends the rest of the session gathering support for it. That is not research, that is a press release. Three branches that cannot see each other cannot converge on the same early guess, so you get actual different perspectives instead of one idea wearing three hats.

Everything flows into a skeptic. A dedicated job whose only purpose is to attack what the researchers produced. Find the contradictions. Find the unsupported claim. Find the thing that sounds right and is not.

Then it merges into a recommendation. One job takes the surviving material and produces a clear answer with reasoning attached.

And ends at human approval. You. Looking at a tight recommendation with the critique already applied, instead of a raw blob you have to audit from scratch.

Notice what the diamond did to your workload. In the one-prompt world, you are the reviewer, the fact-checker, and the skeptic, all at 11pm. In the diamond, those jobs happened before the output ever reached you. You get to do the thing humans are actually good at, which is making the call.

The one rule you cannot break: separate the checker

If you take a single thing from this article, take this.

Never let the model that generated the work be the model that grades it.

You have probably done the thing where you ask, right at the end, “now review your answer and fix any mistakes.” And it says something like “great catch, here is an improved version,” and improves nothing of substance. It fixes a comma. It rewords an intro. It declares itself correct.

This is not the model being lazy. It is structural. That model has the full reasoning chain that produced the answer sitting in its context, and that chain feels coherent, because it built it. Asking it to review its own work is asking someone to spot their own blind spot using only their blind spot.

So make checking a real job. Separate box, fresh context, adversarial instructions. Do not say “review this.” Say “your job is to find what is wrong with this. Assume it contains at least one significant error. Identify unsupported claims and internal contradictions.”

A grader that shares context with the generator is a rubber stamp with extra steps.

Three levels, and why you should start embarrassingly low

Here is the trap. You read all this, get excited, and immediately go install an orchestration framework. Do not do that yet.

Level 1 is manual. Draw the graph on a whiteboard, or in Excalidraw, or on the back of an envelope. Then run it by hand. Open a fresh session per job. Paste the output of one into the next. Yes, it feels primitive. Do it anyway, at least once.

Running it manually is the fastest way to discover that your graph is wrong. And your first graph will be wrong. You will find that two of your boxes should be one box, that a step you thought was essential produces nothing useful, and that the handoff between step two and three is where everything falls apart. Discovering that with copy and paste costs you an hour. Discovering it after you have automated it costs you a weekend.

Automating a broken process just gets you broken results faster, with better logging.

Level 2 is file-based. Now bring in your coding agent and have each step write its output to an actual file. 01-question.md, 02-research-a.md, 03-critique.md, 04-recommendation.md.

This is the sweet spot for most people, and it is more powerful than it looks. You get a paper trail, so when the final answer is weird you can walk backward and find the exact step where it went sideways. You get reproducibility, so you can rerun one step without redoing everything. You get resumability, so a failure at step four does not cost you steps one through three. And your state stops being “whatever is in the chat” and starts being “these specific files,” which is the whole discipline made concrete.

Level 3 is automated. Now you graduate to orchestration frameworks: LangGraph, AutoGen, n8n, and friends. These give you real state management, conditional routing, human-in-the-loop approval gates, retries, and connections to external systems and APIs.

This is where you go when the graph is stable, you run it often, and the manual overhead has become the bottleneck. Not before. Most people should stay at level 2 considerably longer than their ego wants them to.

Do not build a cathedral

Once graphs click, there is an overwhelming temptation to add boxes. A second skeptic. A meta-planner that plans the planning. A synthesis layer that synthesizes the synthesis.

Resist.

The goal is the smallest graph that measurably improves quality. That is the whole target. Not the most impressive graph, not the one that would look best in a diagram on Twitter.

Every box you add costs you something real: more latency, more tokens, more places for state to get mangled, and more surface area to debug when the output comes out strange. If splitting a job in two does not visibly improve the result, merge it back. A four-box graph that reliably produces good work beats a twelve-box graph you do not fully understand.

The test is simple. Remove a box. Did the output get worse? If not, it was decoration.

The part almost everyone skips: memory

Here is the difference between a graph that helps you today and a graph that compounds.

A good graph does not just produce an answer. It produces artifacts. The framed question. The research. The critique. The reasoning behind the recommendation. And, if you are smart, the options you rejected and why.

That last one is worth its weight in gold. Six weeks later, when someone asks “did we consider X?”, you do not have to reconstruct your thinking from memory. It is written down, with the reason attached.

And those artifacts become inputs. Feed last quarter’s decisions into this quarter’s planner. Feed the critiques into your prompts so the skeptic knows what your recurring blind spots are. Feed the good outputs in as examples of the standard.

A chat session ends and takes everything with it. A graph leaves the receipts.

That is where the real multiplier lives. Not in any single run, but in the fact that run number twenty starts with everything runs one through nineteen learned, structured well enough to actually use.

Start this week, badly

You do not need a framework. You need a pen.

Pick one task you do over and over and quietly dread. Content research. Technical spec writing. Competitive analysis. Debugging a category of issue that keeps recurring.

Draw four boxes: frame the question, do the work, attack the work, produce the answer. Run it by hand, one fresh session per box. Notice exactly where it falls apart, because it will. Fix that one arrow. Run it again.

That is graph engineering. Everything after that is optimization.

Back to that 400-word prompt

You were not bad at prompting. That prompt was probably excellent.

You were just asking one worker to be an entire team, and then acting surprised when the work came back looking like one tired person did all of it at midnight.

Give the work a shape. Give each job one thing to do. Let something hostile check it before you ever see it. And write down what happened, so tomorrow starts smarter than today.

Your model did not get better. Your process did. That is the 10x.

You get a task and you think you can use Claude or Codex to help you. So you write a good prompt with lots of details and you tell it to not make things up. You hit enter. It gives you a lot of text that sounds really confident.

Then you read it and you start to feel bad. Some of it is good. Some of it is wrong.. You cannot tell which is which without doing a lot of work yourself. This is not what you wanted.

The problem is not with the prompt. You can write the prompt in the world and still get bad results. The problem is with how the computer’s set up. It is like having one person do everything. They have to plan, research, write and check their work by themselves. This is too much for one person.

There is a way. It is called graph engineering. Of having one person do everything you break the work into smaller jobs. Each job has one thing to do. They are all connected. This way each job can focus on its thing and do it well.

A graph has three parts: jobs, arrows and state. Jobs are like boxes where each box does one thing. Arrows are like the connections between the boxes. They show how the jobs are related. State is like the information that moves between the jobs.

In a conversation state is like a big pile of everything that has been said. It can get confusing.. In a graph state is clear. Each job gets the information it needs. Gives the information it produces. This way each job can do its thing without getting confused.

Some people might think that a graph is like a map of how thingsre related.. That is not what we are talking about. We are talking about a map of how work moves between jobs.

There is a pattern that’s really useful. It is called the diamond. It starts with one question then splits into three research jobs. Each job does its research and then gives its results to a skeptic. The skeptic checks the results. Gives them to a person who makes a recommendation. Finally a human approves the recommendation.

The diamond is good because it breaks the work into jobs. Each job can focus on its thing and do it well. The human only has to approve the recommendation, which is easier than doing all the work themselves.

There is one rule: the person who checks the work cannot be the same, as the person who does the work. This is because the person who does the work will not be able to see their mistakes. You need someone to check the work and find the mistakes.

There are three levels of using graphs. The first level is manual. You draw the graph on a piece of paper. Run it by hand. This is a way to start because you can see if the graph is working. The second level is file-based. You use a computer to run the graph. Each job writes its results to a file. This is a way to keep track of the work and make sure it is reproducible. The third level is automated. You use a program to run the graph and it can do everything for you.. You should not start with this level. You should start with the level and work your way up.

The goal is to make the graph that works. You do not need to make a complicated graph. You just need to make one that works and gives you results. So do not try to add many jobs or make it too complicated. Just keep it simple. Make sure it works.

Every time you add a box to something it costs you something. You get latency, more tokens and more places where things can go wrong.. When things do go wrong you have more things to check. If splitting a job into two parts does not make it better then you should just put it together. A simple graph with four boxes that works well is better than a graph with twelve boxes that you do not understand.

The test to see if a box is really needed is simple. Just remove the box. See if things get worse. If they do not then the box was not necessary.

People often forget about memory.

The difference between a graph that helps you now and a graph that will help you in the run is big.

A good graph does not just give you an answer. It also gives you useful things. You get the question you were trying to answer the research you did the critique of your work and the reasons why you made choices.. If you are smart you will also write down the options you did not choose and why you did not choose them.

This is really valuable. On, when someone asks you if you thought about something you will not have to try to remember. You will have it written down along with the reasons why you made your choices.

These things you write down can be used again. You can use quarters decisions to help you plan this quarter. You can use the critiques you got to help you write prompts.. You can use the good things you did as examples of what you should do again.

When you have a conversation it. You do not have anything to show for it.. When you make a graph you have something to show for it. You have a record of what you did.

This is where the real benefits come from. It is not from one time you use the graph but from the fact that each time you use it you can start with what you learned last time.

So start this week even if you do not do it well.

You do not need some system. You just need a pen.

Choose one thing you do over. Over that you do not like. It could be researching, writing specifications or analyzing competitors.

Draw four boxes: what is the question do the work check the work and give the answer. Try it out by hand one step at a time. See where it does not work and fix that part. Then try it again.

This is how you make a graph work well. Everything else is just making it a little better.

Now think about that prompt you wrote.

You were not bad, at writing prompts. That prompt was probably good.

You were just asking one person to do much work and then you were surprised when the work was not good.

Give each job one thing to do. Let someone check it before you see it. And write down what happened so you can do better tomorrow.

Your model did not get better. Your process got better. That is what made the difference.

Most founders treat that faith like a sale. They shouldn’t. How you repay those first few people is the single highest-leverage decision you’ll make in the early life of your company. And the way you repay it is by over-delivering: wildly, unsustainably, on purpose.

Let me make the case.

At small numbers, every customer is the whole company

When you have ten thousand customers, one unhappy person is a rounding error. You can lose them and never feel it.

When you have ten, one unhappy person is ten percent of everything you’ve built. Their experience isn’t a row in a dashboard. It’s a tenth of your reputation, walking around in the world, telling a story about you whether you like it or not.

This is the math early founders get wrong. They benchmark themselves against companies operating at scale, where service is a cost center to optimize down. But you are not at scale. At your size, a single delighted customer doesn’t just stay. They recruit. And a single burned customer doesn’t just leave. In a small, tight market, they warn everyone who’ll listen.

Early on, the leverage runs in both directions, and it is enormous.

Over-delivering doesn’t scale. That’s the entire point.

The most common objection sounds responsible: “I can’t answer every email at midnight, hand-onboard every user, and build a custom feature for one account. That doesn’t scale.”

Correct. It doesn’t. And that is precisely why you should do it now, while you still can.

Over-delivering isn’t a permanent operating model. It’s a temporary subsidy you pay while you have few enough customers that the subsidy is affordable. The window is small (measured in dozens of customers, not thousands), and it closes the moment you grow. You will never again have the time to personally make someone’s day. So spend that time now, when the per-customer cost is high but the per-customer payoff is highest.

Founders who refuse to do unscalable things in the name of building a scalable business often end up with neither. They optimize for efficiency before they have anything worth being efficient about.

Your early customers are your cheapest, best distribution

You will spend a great deal of money, later, trying to acquire customers. Ads. Content. Sales calls. A delighted early customer is the one channel that costs you nothing and converts better than all of them.

People do not share “fine.” Nobody has ever told a friend about a checkout flow that worked exactly as expected. What gets shared is the surprise: the bug you fixed before they reported it, the reply that arrived in two minutes instead of two days, the small thing you did that they never asked for and couldn’t have demanded.

Over-delivery is what manufactures that surprise. And surprise is what turns a customer into a megaphone you didn’t have to buy.

In a world where every founder is fighting for attention and paying dearly for it, the cheapest growth you’ll ever touch is a handful of early users who feel like they found something that actually cares about them.

You don’t yet know what “delivering” means: over-delivering is how you find out

Here’s the part nobody tells you: in the beginning, you don’t actually know what your product is for.

You have a guess. You built features you thought mattered. But your real value (the reason people will eventually pay) is almost always something adjacent to, or buried inside, what you set out to build.

When you over-deliver, you do a lot of things for those first customers. You go above and beyond in five directions at once. Then you watch which of those five things they actually light up about. The over-delivery is a sensor. It tells you, with more honesty than any survey, what people quietly value versus what they politely tolerate.

That signal is worth more than the effort costs. You’re not just delighting customers. You’re paying to discover your own product.

What over-delivering actually looks like

It’s rarely grand. It’s almost always small, fast, and human:

• Replying before they’ve finished wondering whether you will.

• Doing the thing manually that they assumed was automated, without mentioning it was you, sweating behind the curtain.

• Catching the problem before they hit it, and reaching out first.

• Remembering their context, so they never have to re-explain themselves.

• Giving them the upgrade, the extra month, the unasked-for fix, because you can, and because they were early.

None of this is a growth hack. All of it says the same thing: a real person on the other end noticed you took a risk on us, and decided to honor it.

That feeling is sticky. People forget your features. They do not forget how you treated them when you had every excuse to treat them like a number.

The trap: it’s a phase, not a personality

One warning, because this advice has a failure mode.

Over-delivering is a tactic for a season: the first cohort, the first community, the first reputation. It is not a forever-promise to every customer who ever shows up. If you over-deliver to everyone, indefinitely, you’ve quietly built a consulting business wearing a product’s pricing, and you’ll burn out somewhere around customer two hundred.

The move is this: over-deliver early to buy two things (word of mouth and learning), and then, once you know what people actually value, systematize the parts that matter and let go of the parts that don’t. The handwritten note becomes a great onboarding email. The midnight reply becomes a genuinely fast support norm. The one-off custom feature becomes a roadmap decision.

You’re not promising heroics forever. You’re using heroics, briefly, to earn the right to exist.

The faith, repaid

Come back to where we started. Being someone’s first customer is an act of faith. They bet on you when betting on you was irrational.

You can repay that bet two ways. You can deliver exactly what was promised: competent, forgettable, the floor. Or you can over-deliver so plainly that they walk away certain they were right to take the risk, and tell everyone they know.

The first costs you nothing and earns you nothing. The second costs you a few weeks of unsustainable effort, early, while it’s still cheap, and buys you the only thing a young company actually runs on: a small group of people who believe in you, loudly.

Plenty of competent products die quietly every year. The ones that take root are almost always the ones whose first handful of customers couldn’t keep quiet about them.

Over-deliver while you can. The window is open now, and it won’t stay open long.

He was a good engineer. The product was real a scheduling tool for freelance video editors, a niche he knew well because he had been one. He worked nights and weekends, polished the onboarding, rewrote the billing flow twice, added the integrations he was sure people would ask for. He did everything right except one thing.

Launch day: he posted it on X to his 312 followers, put it on Product Hunt, and waited.

Eleven signups. Four of them were friends. One was his brother.

The product was good. I used it. It deserved better than eleven signups. But nobody knew he existed, and the internet does not reward things it cannot see. He spent fourteen months building the answer to a question nobody had heard him ask.

Around the same time, I watched someone else do the opposite. She spent a year building an audience posting daily about design systems, sharing teardowns, growing a newsletter to twenty thousand subscribers. Then she launched a product. A small one. Honestly, a worse product than my friend’s - a Notion template pack she made in two weekends.

She did five figures in the first month.

Worse product. A hundred times the outcome. That asymmetry should bother you. It bothered me for a long time, until I accepted what it actually means.

Distribution beats product, and it is not close

Here is the uncomfortable math of being a solo founder in 2026.

Building product has never been easier. AI pair programmers, no-code tools, open-source everything a competent solo founder can now ship in weeks what took a funded team a year in 2015. Which means your product, however good, is the least defensible thing about your business. Whatever you build, someone can clone in a month.

What they cannot clone is twenty thousand people who trust you.

Attention is the scarce resource now. Product is abundant. When something becomes abundant, its price falls. When something stays scarce, its price rises. The market is telling you what to build first, loudly, and most engineers refuse to hear it because the answer offends them.

It offended me. I am an engineer. I wanted the craft to win. I wanted the best product to find its users by being the best, the way it works in the story we tell ourselves. That story is dead, if it was ever alive. The graveyard of failed startups is not full of bad products. It is full of good products nobody heard about.

But audience-building feels like wasted time

I know the objection, because I made it for years. Posting on the internet feels unproductive. You write a thread, it gets forty likes, and you have nothing to show for it no code, no feature, no thing. Meanwhile a day spent building gives you something real you can point to.

This is an accounting error, and it is worth understanding exactly where the error lives.

When you build product before audience, your work compounds at zero until launch. Fourteen months of my friend’s effort produced no feedback, no validation, no waitlist, no learning about what people actually wanted. All the value was theoretical until the day it met the market and the day it met the market, the market shrugged.

When you build audience first, every single post is a tiny launch. You learn in public what resonates and what dies. You find out which problems people actually have not the ones you assume they have because they tell you, in replies, every day. By the time you build the product, you are not guessing. You are fulfilling an order the audience already placed.

The audience is not a marketing channel. It is the cheapest market research that has ever existed, and it pays you back twice: once in learning, once in launch-day distribution.

What this looks like in practice

Not “become an influencer.” Nobody needs another founder posting motivational threads about morning routines.

It looks like this: pick the niche you are going to build in, and become the person who publishes the most useful free things in that niche. If you are building for freelance video editors, publish the rate calculators, the client-contract templates, the workflow teardowns. Give away the knowledge that adjacent founders are hoarding for their paid product.

Do it for six months before you write a serious line of product code.

This is the part where every engineer’s stomach turns six months of not building. But you are building. You are building the asset that decides whether your product launch is a launch or a whisper. And here is the thing nobody tells you: the audience work makes the product better, not just the launch. The two hundred conversations you have along the way will kill your bad ideas early, for free, before you spend fourteen months on one.

The honest counterargument

There is one case where product-first is right, and pretending otherwise would make this essay propaganda instead of advice.

If your product’s users are not reachable through content enterprise buyers, regulated industries, niches that do not hang out on the internet audience-first collapses. You cannot newsletter your way to a hospital procurement department. In those markets, the equivalent of audience is relationships and pilots, and you often do need a working product to start those conversations.

And if you are a genuine outlier building something so technically deep that the demo is the distribution the product can be the audience strategy. But be honest with yourself about whether you are that outlier. Almost everyone who thinks they are, is not. The base rate is brutal.

For everyone else every SaaS, every tool, every template, every course, every app aimed at people who read things on the internet the order is settled.

Audience first. Then product. Then both forever.

Build the audience before the product, not because the audience matters more, but because the audience is the only thing that makes the product matter at all.

My friend with the scheduling tool understood this eventually. He spent the next year doing what he should have done first publishing, teaching, becoming visible in his niche. Then he relaunched the same product, barely changed.

Four hundred signups in the first week. Same product. Different fourteen months.

The product was never the problem. The silence was.

The uncomfortable truth about engineering careers is that the things that actually separate the great from the merely good are almost embarrassingly simple

The reason this is good news is that habits are learnable. You do not need a higher IQ. You do not need a better degree. You need to know which small things matter, and then do them until they stop feeling like effort and start feeling like who you are.

Here are the twenty-five that matter most. None of them are hard to understand. The hard part, the only hard part, is doing them on the days you do not feel like it, for long enough that they become automatic.

If you build even half of these into how you work, you will not need to be the smartest person on your team. You will be the one they cannot run the team without.

1. Clarify requirements before coding. The most expensive code is the code that solves the wrong problem perfectly. Ask what “done” looks like before you write a single line, and you will save yourself the rewrite.

2. Break problems into smaller parts. A problem you cannot solve is usually three problems you have not separated yet. Cut it into pieces small enough to finish one sitting, and the impossible turns into a checklist.

3. Read documentation fully. The answer you are about to spend an hour searching ChatGPT for is often two paragraphs into the docs you skimmed. Reading the whole page once is faster than guessing five times.

4. Debug before guessing. Changing random lines until the error goes away is not fixing the bug: it is hiding it until it comes back worse. Find out what is actually happening before you touch anything.

5. Write clean commit messages. Six months from now, “fixed stuff” tells you nothing and a clear message tells you everything. You are writing notes to a future version of yourself who has forgotten all of this.

6. Ship consistently. The engineer who ships something small every week beats the one chasing the perfect release that never arrives. Done and in production teaches you more than perfect and in your head.

7. Ask precise questions. “It doesn’t work” wastes everyone’s time; “the login returns a 500 when the email has a plus sign” gets you an answer in minutes. A good question is half the solution.

8. Measure before optimizing. Your instinct about what is slow is usually wrong, and you will spend days speeding up code nobody waits on. Profile first, then fix the thing that actually costs time.

9. Think in tradeoffs. There is no best choice, only the right choice for this situation faster but more memory, simpler but less flexible. Naming what you are giving up is what separates a decision from a guess.

10. Write maintainable code. Code is read ten times for every once it is written, usually by someone tired and in a hurry. Write for the person who has to change it next, because that person is often you.

11. Review code seriously. A rubber-stamp “LGTM” helps no one and lets bugs walk straight into production. A real review catches the problem now, when it is cheap, instead of at 2 AM when it is not.

12. Keep notes while learning. You will solve the same tricky problem three times in your career and forget the solution twice. A few lines written down today is an hour saved next year.

13. Automate repetitive tasks. If you have done it by hand three times, the fourth time should be a script. The minutes you spend automating come back as hours, and the machine does not make typos.

14. Protect focus time. Real engineering happens in long uninterrupted blocks, not in the gaps between meetings and Slack pings. Guard a few hours a day like they are the job, because they are.

15. Improve communication daily. The best technical idea is worthless if you cannot make someone else understand it. Your career grows at the speed of your ability to explain, not just your ability to build.

16. Test critical paths. You do not need to test everything, but the few flows that lose money or break trust must never fail silently. Know which paths those are and cover them first.

17. Learn from incidents. An outage that teaches you nothing is just pain with no payoff. Write down what broke and why, so the same failure does not happen twice with your name on it.

18. Refactor continuously. Messy code does not clean itself, and the “I’ll fix it later” pile only grows. Tidy a little as you go, so you never face the rewrite that eats a whole quarter.

19. Manage time realistically. Most estimates are wrong because they imagine a perfect day that never happens. Plan for the interruptions, the bugs, and the meetings, and you will stop disappointing people.

20. Understand business context. Code that ships on time but solves nothing the company needs is wasted effort, however elegant. Knowing why you are building something changes what you build.

21. Stay calm under pressure. Production is down and panic makes you slower, sloppier, and more likely to break the next thing. The engineer who breathes and thinks clearly fixes it faster than the one who flails.

22. Keep ego low. The moment you stop being able to hear “you’re wrong” is the moment you stop improving. The best engineers are the ones most willing to be corrected.

23. Learn fundamentals deeply. Frameworks come and go every two years, but how memory works, how networks move data, and how systems fail do not change. Master the things that outlast the trends.

24. Help teammates often. The trust you build by unblocking others is the foundation everything else in your career sits on. A team that wins together beats a hero who burns out alone.

25. Stay consistent for years. Talent gets you noticed; showing up every day for a decade is what actually builds a career. The compounding is invisible day to day and undeniable looking back.

Same Claude Code subscription. Same model. Same eight hours a day. But somehow this person closes three tickets in the time you close one, and when you sit behind them at lunch and ask how, they shrug and say something useless like “I just prompt better.”

They are not prompting better. They are running a stack you are not running.

I figured this out the slow, embarrassing way. For months I was the engineer in the first paragraph! the one paying full price and getting maybe a quarter of the value. My terminal sessions kept ending in the same place. I would start a task, spend twenty minutes loading Claude with the project context, get somewhere useful, close the laptop, and watch all that context evaporate by morning. The next day I would do the loading dance again. I told myself this was just how the tool worked.

It was not how the tool worked. It was how I was using the tool, while half of GitHub had quietly built the parts I was missing.

Here are the 20 I actually use. If you are running fewer than half of them, you are paying full price for a tool you are using at quarter strength.

Start with what Anthropic already gives you

1. anthropics/claude-code: the terminal client itself. Reinstall it just to read the README, because the half of it nobody reads is where most of the configuration tricks live.

2. anthropics/skills: Anthropic’s official skill pack for handling real file formats (PDF, DOCX, XLSX, PPTX), plus the meta-skill that teaches Claude how to write new skills. Install if you have ever asked Claude for a Word doc and gotten plain text instead.

3. anthropics/claude-code-action: a GitHub Action that wires Claude into your pull requests so you can tag it for code review the same way you tag a teammate. The setup is one config file. The payoff is every PR getting reviewed.

Find the good stuff faster than scrolling GitHub at midnight

4. hesreallyhim/awesome-claude-code: the canonical index of everything in the ecosystem. Start here when you do not know where to start.

5. ComposioHQ/awesome-claude-skills: Composio’s curated skills covering things you actually need at work: Postgres queries, deep research, root-cause investigation, log triage.

6. ComposioHQ/awesome-claude-plugins: same team, plugin side. Frontend scaffolds, artifact builders, third-party app connectors.

7. FlorianBruniaux/claude-code-ultimate-guide: a full course masquerading as a repo, with templates and quizzes that take you from “I just installed this” to “I run my whole workflow through it.” Send to anyone on your team who has not opened Claude Code yet.

Skill packs that change how Claude thinks

8. obra/superpowers: forces Claude to slow down: brainstorm before specs, specs before plans, plans before code, tests before merging. After a week of it you will catch yourself writing better specs even when Claude is not in the loop.

9. nextlevelbuilder/ui-ux-pro-max-skill: design memory in skill form. Color palettes, layout patterns, UX heuristics that stop Claude from defaulting to the same Bootstrap-shaped UI everyone else has been shipping since 2019.

10. bmad-method: splits Claude into roles instead of steps: analyst, PM, UX designer, architect, developer. Pick this when your bottleneck is project structure, not code production.

11. github/spec-kit: spec-first development as a slash command pipeline. If you have ever shipped the wrong feature beautifully, this is the repo that makes you write the contract before the code.

12. travisvn/awesome-claude-skills: community-built skills with one feature most lists skip: warnings about which ones to vet before installing. Trust beats novelty.

Subagents: stop running everything in one cluttered window

A long Claude session collects clutter the same way a long browser session does. Subagents give you a team of specialists running in parallel instead of one assistant getting more confused with every prompt.

13. wshobson/agents: production-ready subagents covering every role you would hire for: dev, security, design, data, ops, research. Drop the folder in and call them by name.

14. danielrosehill/Claude-Code-Repos-Index: agent templates for jobs that are not coding. Writing, ops, customer support, research workflows. Install if you want Claude Code to be your assistant for everything else you do at a computer, not just your IDE.

MCP servers: connect Claude to the rest of your stack

Claude Code on its own can read your files and run shell commands. MCP servers extend that reach to the actual tools you spend your day inside.

15. github/github-mcp-server: first-party access to PRs, issues, branches, CI runs, the whole platform. The first MCP server most people install because it is the one that earns its keep on day one.

16. microsoft/playwright-mcp: gives Claude a browser. Once it can click and scroll, the boundary between “things Claude can help with” and “things only a human can do” moves further than you expect.

17. crystaldba/postgres-mcp: query your database from Claude with read-only access by default, so you do not accidentally drop a table while exploring. Replaces the loop where you SSH in, type the query, copy the result back into chat.

18. upstash/context7: pulls live, version-correct documentation into every prompt. The repo that finally stopped Claude from confidently inventing API methods that do not exist.

19. czlonkowski/n8n-mcp: connects Claude Code to the 400+ apps n8n already integrates with. If you run automation, this is the bridge between your workflow engine and your coding agent.

Memory and orchestration

The hardest thing about Claude Code is that every new session starts as a stranger. These two are the difference between a tool you have to keep re-introducing yourself to and one that knows where you left off.

20. thedotmack/claude-mem: long-term memory through context compression. The single most-requested Claude Code feature, solved by a community repo, free.

Bonus: GetStopover

15+ airlines offer free 5-star hotels and city tours during long international layovers. Turkish, Qatar, Singapore, Etihad, and Emirates all run real stopover programs but eligibility lives in fare-class fine print.

Most travelers never claim them because the rules are scattered across each airline’s site. GetStopover compares every program in one place search live flights and see which routes unlock free stopovers.

Try here: getstopover.com

I have watched this same failure happen in dozens of interviews, at every level, from new grads to principal engineers. The names change. The companies change. The prompt changes: Design Uber, Design Netflix, Design a URL shortener, Design WhatsApp. The failure does not change.

And here is the thing no one tells you: the prompts do not really change either.

Strip the brand name off any system design question and you are left with one of roughly fourteen problems. Every interview at every company is a remix of the same fourteen. Once you see the list, you stop studying systems and start studying patterns. Once you study patterns, the interview stops being a memory test and starts being a recognition test which of the fourteen is hiding inside this prompt, and which two or three combine to solve it.

This is the list. If you learn these fourteen well enough to explain each one in two minutes to a smart non-technical friend, you will pass ninety percent of the system design interviews you take in 2026.

Here they are.

1. Load Balancing:

• Distributes traffic across multiple servers (Round Robin, Least Connections, Consistent Hashing)

• Analogy: Head chef assigning orders to different line cooks so no one gets overwhelmed

• Pros: High availability & scalability

• Cons: Can become single point of failure if not redundant — Best for: High-traffic web apps, APIs, streaming services

2. Caching Strategies:

• In-memory (Redis), CDN, write-through vs write-back

• Analogy: Prepping frequently used ingredients on the counter instead of fetching from the fridge every time

• Pros: Blazing fast reads

• Cons: Cache invalidation & consistency issues

• Best for: Read-heavy systems, e-commerce, social feeds

3. Database Choices (SQL vs NoSQL):

• Relational (ACID) vs Document/Key-Value/Graph

• Analogy: Using a structured cookbook vs a flexible recipe notebook

• Pros: SQL for transactions, NoSQL for scale

• Cons: Wrong choice kills performance

• Best for: Transactions (SQL) vs massive unstructured data (NoSQL)

4. Sharding & Partitioning:

• Splitting data across multiple DB instances

• Analogy: Dividing the kitchen into stations so each chef handles one type of dish

• Pros: Horizontal scaling

• Cons: Cross-shard queries & rebalancing pain

• Best for: Massive datasets (Twitter, Instagram scale)

5. CAP Theorem & Consistency Models:

• Choose 2 out of Consistency, Availability, Partition tolerance

• Analogy: Deciding whether the kitchen prioritizes perfect recipes, speed, or handling power outages

• Pros: Guides trade-offs

• Cons: No “perfect” system

• Best for: Distributed systems design decisions

6. Microservices vs Monoliths:

• Service boundaries, communication (gRPC, Kafka, REST)

• Analogy: One big kitchen vs multiple specialized food trucks

• Pros: Independent scaling & teams

• Cons: Distributed complexity & latency

• Best for: Large evolving products

7. Rate Limiting & Throttling:

• Token bucket, Leaky bucket, API gateways

• Analogy: Limiting how many orders one customer can place so the kitchen doesn’t collapse

• Pros: Prevents abuse & overload

• Cons: False positives for legit users

• Best for: Public APIs, SaaS platforms

8. Message Queues & Event-Driven:

• Kafka, RabbitMQ, SQS for async processing —

• Analogy: Order tickets passed to the right station without blocking the front counter

• Pros: Decoupling & resilience

• Cons: Eventual consistency & debugging

• Best for: Background jobs, notifications, data pipelines

9. CDN & Edge Computing:

• Caching content closer to users

• Analogy: Having mini-kitchens in every city instead of one central HQ

• Pros: Low latency

• Cons: Cache invalidation & cost

• Best for: Global apps, video streaming, static assets

10. Observability (Logging, Metrics, Tracing):

• OpenTelemetry, Prometheus, Jaeger —

• Analogy: Installing cameras, timers & thermometers everywhere in the kitchen

• Pros: Root cause in minutes

• Cons: Data overload if not filtered

• Best for: Production debugging at scale

11. API Design & Versioning:

• REST, GraphQL, gRPC, backward compatibility

• Analogy: Standard menu format so every customer knows exactly what they’re ordering

• Pros: Developer-friendly

• Cons: Version sprawl

• Best for: External-facing services

12. Data Consistency & Transactions:

• 2PC, Saga pattern, eventual consistency

• Analogy: Making sure every dish in a multi-course meal is ready at the exact right time

• Pros: Reliability

• Cons: Performance hit

• Best for: Banking, e-commerce orders

13. AI System Design Specifics:

• LLM serving, vector DBs, RAG pipelines, cost/latency trade-offs

• Analogy: Building a smart kitchen that can generate new recipes on demand while keeping costs low

• Pros: Modern differentiator

• Cons: Rapidly evolving tools

• Best for: GenAI products, recommendation engines

14. Fault Tolerance & Disaster Recovery:

• Circuit breakers, retries, backups, chaos engineering

• Analogy: Fire extinguishers, backup generators & evacuation plans in the kitchen

• Pros: 99.99% uptime

• Cons: Extra cost & complexity

• Best for: Mission-critical systems

Short Story :-

The candidate had six years at a well-known company. Staff engineer title. Clean resume. He opened the call confident.

Question: Design Twitter.

He started with microservices. Then he drew a box labeled “auth service.” Then another box labeled “tweet service.” Then an arrow. Then he stopped, looked at what he had drawn, and started over. The second attempt had Kafka in it. No explanation for why. When the interviewer asked how the timeline would be built, he said “fan-out,” paused, and asked if he meant on read or on write.

He did not answer. He was waiting to see if he knew the difference mattered.

He did not.

Forty minutes later the call ended. He had touched six different technologies and explained none of them. He had not asked about scale. He had not asked about the read-to-write ratio. He had not asked what “Twitter” meant in the question the full product, the timeline feature, the posting flow, something else. He reached for tools before he understood the problem.

He failed the interview. Not because he did not know enough. Because he knew a lot of things without knowing which one the moment called for.

TL;DR

• Load Balancing → traffic distribution

• Caching → speed wins

• DB Choices → right tool for data

• Sharding → horizontal scale

• CAP → trade-off decisions

• Microservices → modularity

• Rate Limiting → abuse protection

• Queues → async decoupling

• CDN/Edge → global speed

• Observability → visibility

• API Design → clean contracts

• Consistency → reliability

• AI-Specific → GenAI systems

• Fault Tolerance → resilience

2. Work Smart, Not Hard
The goal isn’t to avoid AI, it’s to use it smartly. Efficiency > ego. 🚀

3. The Future Is Hybrid
AI won’t replace developers — but developers who use AI will replace those who don’t. 💻🤖

4. True Intelligence
Smarter isn’t doing everything yourself, it’s knowing what to delegate to machines. 🔥

5. Progress Over Pride
Coding without AI is like walking when you have a car — sure, it builds endurance, but you’ll get there slower. 🏎️