I was frustrated with the Houston gas station experience.

Thought I’d turn this frustration into an opportunity to build what I recommend my customers buy.

Here is what happened, and how you can build one too.

(TOOLS USED AT BOTTOM)

I built the whole stack for a gas station that does not exist. A site search across county property records. A screen for what goes on the shelf. A working model of the operation that I ran for a simulated year. 364 daily closes, about $907,000 in net, and not one of the numbers that mattered was typed in.

Here is what it could be: Astra - Modern Convenience “Sanctuary, not a pit stop”

I mostly wanted to see for myself what was possible. Not in a demo.

On something I cared about getting right.

The distance between what is in your head and something that actually runs is shorter than it was a year ago. That matters most for the people who already have the hard part. If you work in industrial operations you know how your plant, your terminal, your yard actually behaves, including the parts nobody ever wrote down. You can now shape that into something real yourself, far enough that when you bring the right team around you, you are handing them a working thing instead of a description of one.

The gas station was the easy case. Its numbers are public. The industry publishes its benchmarks and the county publishes the property records, so I could check my work against reality on a Saturday afternoon. Your operation publishes nothing. You have a historian, a maintenance system, a stack of spreadsheets, and people carrying the parts that were never written down. That changes the first step and none of the rest.

Step 1: Find out what is actually there.

I could have named four intersections in Houston I thought would work. That is not analysis. That is a guess with a zip code on it.

What I wanted was every commercial parcel inside a boundary I drew, with its size, its owner, its assessed value, and whether anything was already sitting on it. I did not know where that came from. I did not know that a county appraisal district publishes it, that you can download the entire thing, or that the entire thing for Harris County is about 7.4 million rows.

I had Claude walk me through it. I described what I wanted to know and asked where that information actually lives, and it took me through what the county publishes, what is in a parcel record, and what the fields mean. That was an afternoon of me asking questions I would have been embarrassed to ask a person.

Then the real work started, and none of it was the AI part.

7.4 million rows do not open in a spreadsheet. They go in a database, which for me meant Postgres, hosted on Supabase so I did not have to run anything myself. That sounds like a technical detail and it is actually the whole decision. A spreadsheet lets you look at data once. A database lets you ask it a different question every day for a year, which is what site selection actually is.

Then the names. Owner names in public records never match anything cleanly. The same company shows up four ways across four parcels, none of them spelled the way you would type it. So the search had to be fuzzy, matching close enough rather than exactly, which is a library called rapidfuzz doing the work in a few lines. Nobody warns you about this. Every real dataset has a version of it.

Then the map, which I assumed would be the easy part.

It was not one decision. I went through several open source mapping options before I had something that put my parcels where they belonged and stayed readable at the zoom I cared about, and I ended up on Google Maps. Every attempt taught me something about what I actually needed, which I could not have written down at the start, because I had never seen my own data on a map before.

Then a problem I did not see coming. I would find something good and then lose it. A search that took twenty minutes to get right lasted until I closed the window. So the next stretch of work was saving. Keeping the parcels I flagged and the searches that worked, so the second session started where the first one ended.

And then the part that turned out to be the actual build. Having 7.4 million records and a map does not narrow anything down. I had to work out what needed to be in front of me at the moment I was making a judgment. Which fields, in what order, next to what. Most of what I built after the data was loaded was not analysis at all. It was getting the right five things on the screen so I could look at a parcel and say no in four seconds.

Here is what to take with you. The intelligence was the last thing I added and the smallest part of the work. Getting the record somewhere it could be questioned was most of it. Deciding what to put in front of a human at the moment of judgment was the rest. And anything you work out that you will want again goes into the tool, not into the conversation.

Your version of this is not a county appraisal district. It is your own asset register, your equipment history, your inspection records, the plant files, sitting in three systems that do not talk and a shared drive nobody has cleaned since 2019. The step is identical. Get it into one place that can be asked a question. Fix the way things are named. Then work out the five fields a person needs on screen to make the call, because that is the part that decides whether anyone uses it.

Step 2: Write the rule down before you ask the model anything.

A convenience store lives or dies on what is on the shelf, so the second build was a screen. Hand it a product, get back whether that product belongs.

The first thing I got wrong was assuming this was a question I could ask. You cannot ask a model what belongs in your store. It does not know what you care about, and if you do not tell it, it will hand you something reasonable and generic, which is worse than nothing because it looks like an answer.

So I had to write the standard down. Mine screens on how heavily processed a food is, what additives it carries, and what it is certified as. Those are my criteria. Yours would be different, and that is not the point. The point is that the standard existed, in writing, before the model touched a single product.

I wrote that value system myself. Claude wrote the prompt that applies it. That division is worth saying out loud, because it is the honest picture of how this work goes and it is the part that should encourage you. I am not a developer and I did not need to become one. What I could not hand to anybody was deciding what good means. What I did not have to work out alone was how to turn that decision into something a model applies the same way every time.

That is the part I would tell any engineer twice. Every argument I have watched about whether an AI answer is right turns out, underneath, to be an argument about a definition nobody wrote down.

Then the screen needed something real to look at. I used Open Food Facts, an open database of packaged products that costs nothing to query. And instead of pasting product details into a chat window, I built a tool that Claude can call directly. Python, using FastMCP, which is a way of handing a model a tool and telling it what the tool does. Give it a product, it goes and looks up the real record, applies my written rules, and comes back with a verdict.

The verdict has three buckets. Aligned, review, off-brand. The middle one is the one that matters. A screen that only says yes or no will force a bad call on every product that does not cleanly fit, and in a real catalog that is a lot of them. Review means the tool is telling me it is not sure and a person should look. I would rather have that than a confident answer I cannot check.

The second half of this build is the one I am proudest of and it does not work yet.

To know whether any of this pencils out, I need real wholesale cost, and real wholesale cost lives behind a distributor account I do not have. So the connector is built, wired, and waiting on an API key. Until it gets one, it returns nothing. It does not estimate. It does not reason its way to a plausible number from what it knows about the industry.

That was a deliberate decision and it is the single most important line of this whole piece. A tool that returns nothing is honest. A tool that returns a plausible number you cannot trace is a liability, and it is worse in industrial work than almost anywhere, because the number does not stay on the screen. It ends up in a capital request.

One more thing about this build, because it is the piece that points forward.

Those same two tools are most of an ordering loop. Somebody checks out and the register drops the count. A level crosses a threshold. Something checks the approved list, checks the cost, places the order with the distributor, and the delivery lands on a schedule the model already knows about.

None of that chain is exotic, and two pieces of it are already built. What is missing is a distributor account, which is a business step rather than a technical one.

I would run the first long stretch of that with a person approving each order. Not because the machine could not do it. Because in industrial work an automatic order is a purchase order with somebody’s name on it, and taking the name off is the fastest way to lose the room.

Your version of this is anything you buy against a spec. Valves, lubricants, coatings, chemicals, spare parts, contractor scopes. Same three steps. Write down what qualified actually means, in a document, before anyone builds anything. Point the tool at the real source of record rather than at the model’s memory. Give it a way to say I am not sure, and a hard wall where it returns nothing instead of inventing a number.

Step 3: Build the operation, one runnable piece at a time.

This is the one that changed how I think.

I found the idea on Twitter. Somebody had built a kingdom simulator that ran in a single web page, with a written chronicle of everything happening in it. Not a dashboard. A world that ran, and told you what it was doing in plain sentences. I looked at it and thought, that is a convenience store.

I had never used Three.js, which is the library that draws 3-D in a browser. I did not know what a deterministic seed was or why anyone would want one. I asked, and what came back was the single most valuable idea in the whole project, so I will give it to you before the phases. If your model uses randomness, fix the random seed so the same run produces the exact same result every time. Otherwise you change something, the numbers move, and you have no idea whether your change did that or the dice did.

Everything below runs in one HTML file. No install, no server, no account. It opens in a browser.

Phase 1: The Lot

The first version had no people, no money, and no store. Cars arrived off the arterial in the platoons a traffic signal actually creates, pulled in, fueled, parked, and left.

That was on purpose. I wanted the smallest thing that visibly ran, because a model you cannot watch is a model you cannot debug.

Two bugs from this phase are worth your time because both are the same shape. Cars would arrive at a pump and freeze there forever, and the lot would slowly clog until nothing moved. The braking curve was stopping cars just outside the window where the fueling behavior triggered. They were parked half an inch from being noticed. Separately, cars that failed to spawn were still consuming their slot in the queue, so traffic thinned to a trickle for no visible reason.

Neither was a modeling error. Both were the kind of thing where the simulation looks plausible and is quietly wrong. That is the real risk in this whole exercise, and it is why the next phases all end in an audit.

Phase 2: The People

Then crew, customers, and a register. Guests walk from their car, pick up different things depending on the time of day, queue, and some of them look at the line and leave without buying anything. Three named crew members work task loops. Eight named regulars come in on schedule.

The regulars are not decoration. Once the log said “Earl Delgado in at 7:13, large coffee and two kolaches,” I started noticing things I would never have found in a table.

The lesson from this phase is the one I would put on the wall. I first wired the staffing decisions to the queue I could see on screen, which is what any normal person would do. It was wrong. The visible queue is a small sample of what is actually happening, so the store would open a second register based on a handful of visible people while the real transaction count said something else. I moved every trigger onto the books, the underlying ledger of what the store is actually doing, and left the visuals as visuals.

If you build one of these, expect that. What you can see is not the data. It is a dramatization of the data.

Phase 3: The Books

Six inventory categories with batches that age. Deliveries on a truck schedule. A full cost stack: labor built up from actual crew hours, power built up from kilowatt hours, card fees charged when the transaction posts, tax accrued.

Here is the rule I held to, and it is the reason any of this was worth doing. Spoilage is not an input. Labor percentage is not an input. Nobody types those in. They fall out of the run. Over a four week baseline, spoilage came out between $98 and $116 a day, because product aged on a shelf and did not sell in time.

Every input that does go in carries a confidence tag, so I can see at a glance which numbers are verified, which are sourced, and which are my guess. That matters more for you than it did for me, and I will come back to it.

Every simulated day ends with an audit that checks the books balance. Twenty eight days, twenty eight audits. When I pushed the store to two crew, the model showed about $720 a day walking out the door because of the line, with the log narrating the waits.

The bug from this phase: I originally posted deliveries when the truck visually arrived. Run the simulation faster and the truck arrives at a different point, so inventory changed depending on playback speed. Deliveries now post to the books on schedule and the truck is theater. Anything that touches the money has to live on the clock, not on the animation.

Phase 4: The Year and The Comparison

A full 52 weeks. Houston seasons with real dates, temperature driving the power bill, school and travel patterns, daily weather, a hurricane week. Then the thing I actually built all of it for.

Take one site. Run it as it exists today. Run it again with the changes I would make. Same seed, same weather, same customers, one difference. Over four weeks, as-is came out at $30,616 and the changed version at $58,618.

That number is not a forecast and I would not defend it as one. What it is, is a disciplined way to argue about a decision. Everything in both runs is identical except the thing under debate, which is almost never true when two people argue about a capital project with two spreadsheets.

The 52 week run closed 364 days out of 364 with clean audits and about $907,000 in net, with the summer power spike and the

hurricane week visible in the ledger.

This phase also produced my favorite failure. At one and a half times normal demand, the lot deadlocked. 147 cars, nothing moving, a queue backed up behind the store. In the real world drivers do three things I had not modeled. They get impatient and take smaller gaps, they see a full lot and drive past, and they give up on the pump and park instead. Adding those behaviors fixed it, and the deadlock check is now part of the daily audit.

I would have found that in the model or I would have found it in concrete.

Phase 5: The Layout

Last, I made the physical site a set of parameters. Number of pump islands. Number of parking stalls. Chargers or none. One curb cut or two. Change them and the lot re-plumbs itself and the traffic finds new paths.

The undersized configuration made about $39,500 a week inside the store against $51,800 for the default. The site was strangling the business, and you could watch it happen.

That is the one thing in this whole build a spreadsheet cannot do for you. Geometry is the constraint you cannot revisit after the concrete is poured.

What the levers are actually for

Every assumption in the model is a lever I can move, and moving one is how the thing earns its keep.

Change the product mix and watch it land on spoilage and on margin at the same time, in opposite directions. Change when the trucks come and see whether the shelf holds through the gap. Change the crew count by daypart and read what the line costs in dollars walking out the door. Move the wage and see whether the better crew pays for itself.

That is a buying decision, a scheduling decision, and a staffing decision, tested before any of them cost anything. It takes a year of operating to learn those the ordinary way, and the ordinary way charges you for every lesson.

And once the model exists, it is not one store. The site geometry is a parameter. So is the traffic, the product mix, the wages, the lease, the power rate. Drop in the details of a different location and it runs that location. The first store is the build. Every store after it is an afternoon of data entry.

Step 4: The Garage

The store needed to look like something. Not for customers. There are no customers. For me, and for anyone I would eventually put it in front of.

So I built the storefront, and the first version was wrong.

Not broken. Wrong. It aimed at a feeling that had nothing to do with what I actually wanted the place to be, and I could not tell that from the idea in my head. I could only tell once it existed and I was looking at it. So I threw it out and rebuilt it, and the rebuild took a fraction of the time, because by then I knew what I was looking at.

It did not stop at a website. The concept needed a world, so I built one.

The site in isometric at dusk and in daylight. An aerial of the parcel. The interior. A night hero. The store as it exists today, before any changes, sitting next to the version after them. Five characters, because a store is people and not a building: a lead, a cashier, a barista, a wellness associate, an attendant working the fuel and the EV canopy. Then scenes with those characters in the space, at the register and at the coffee bar. Marketing aerials of Houston at dusk and at rush hour. Trade area discs at two kilometers and at ten. A pole sign. A brand sheet holding all of it together.

The archive folder is the honest record of how that went. There is a winter version of the world in there, retired, and the filename says why: no snow in Houston. There is a pole sign that was rectangular before I understood what I was looking at, and a second one that was too tall. There is an interior that came out sparse and empty. None of those were planned as drafts. Each one was going to be the final version right up until I looked at it.

That is the part I want to hand to the engineers reading this, and I mean the mechanical, civil, chemical and industrial engineers specifically.

Every one of you has software in your head. Better software than what you have been issued. You know exactly what the tool should do, because you have worked around the one you have for eleven years. Some of you have already written a piece of it. A Python script that pulls the report and cleans it up, running on your machine, that four people at the plant quietly depend on and nobody in IT knows exists.

That is where it always stopped. The distance between a script that works for you and something you can hand to another person was enormous, and the queue for real development time was measured in quarters, and by the time your idea reached the front of that queue it had been rewritten by somebody who had never stood on the unit.

That distance is a lot shorter now. You can build the thing. Not a description of it, not a slide about it. A working version, this month, that other people can open and react to.

And when they react, you find out fast which parts of your idea were right. My first storefront was wrong in a way no amount of thinking would have shown me. Six days of building told me in an afternoon of looking.

None of this makes you a software company, and I would not pretend otherwise. A prototype is not a system. It has no security, no support, no one on call at two in the morning. What it does is turn the thing in your head into something real enough to be argued with, which is the only way it ever gets built properly by the people who build things properly.

What it caught, and what it still cannot do

Two numbers I had written down before I built anything turned out to be wrong, and the model is how I found out.

I had assumed that about 38 percent of the people who buy fuel come inside. The published range for the industry is 57 to 67 percent. I was not a little off. I was off by enough that everything downstream of it in my thinking was wrong, and I had been reasoning confidently from that number for weeks.

I had property tax at a figure that turned out to be three to four times too low. That one is worse than it sounds, because it is fixed and monthly. Get it wrong and every scenario you run is optimistic in a way you will not notice until you are living in it.

Neither of those was caught by intelligence. They were caught because building the model forced me to write the number down somewhere it could be compared against a published one. Most of the value of this exercise is that plain.

Now the limits, flat.

The model is not the store. It is a set of arguments about a store, arranged so they run. Where the inputs are verified it is worth trusting. Where they are my estimate it is worth exactly what my estimate is worth, which is why every one of them carries a tag saying which it is. If you build one of these and skip the tags, you will end up with a machine that turns your own guesses into confident output and hands them back to you looking like findings.

The wholesale cost is still not real. It is waiting on an account. Everything I believe about the actual margin is inference until that connects.

And the whole thing runs on behaviors I decided were true. Customers give up on a line at the point I said they give up. That number came from somewhere reasonable. It is still mine.

Where this goes

I am going to keep building things like this.

Not because I am going into the convenience store business. Because it is the best way I have found to help the people I work with build out their own vision. You cannot advise somebody well on a thing you have never made. Every hour I spend building something I do not need teaches me something I can hand to somebody who does.

So there will be more of these, and they will not all be gas stations. Books for my daughter are next! Notre Dame books! (Go Irish!).

Where to start

Start with a website. Your own. Nobody is watching it and nothing breaks if it comes out ugly, which makes it the cheapest place in the world to find out what these tools actually do.

Then build something for your family. An app only the five of you will ever open.

Then replicate your house. Put it in 3-D and make it run, the same way I did with a store, on a building you already know better than anybody.

Then write your kid a book. More on that one next month ;).

The pattern under all of it is the same. Start with what is already in your head. Tell Claude or Codex plainly that you are not technical and that you want to be walked through every step no matter how small. Then go. I asked questions I would have been embarrassed to ask a person, and every one of them got answered the same way.

And when you do not know what you want it to look like, go to Twitter. Find a few designs you like, feed them in, and say I like this style. That is a legitimate way to start. It is what I did.

You will not end up with a system. You will end up with a working thing instead of a description of one, and a much better vision for what could be vs what exists.

- Marty Dytrych

Tools Used

AI and agents

• Claude, as the thing I actually built with, through Claude Code

• Anthropic Python SDK (anthropic), for the natural language query layer over the property data

• MCP, the Model Context Protocol, with FastMCP in Python, for tools Claude calls directly

• Three custom MCP servers: HCAD property data, Open Food Facts product screening, UNFI wholesale cost

Data sources

• Harris County Appraisal District bulk property data, about 7.4 million rows, free

• Open Food Facts, the open packaged product database, free

• UNFI Harmony Core wholesale API, built and gated on an account

• NACS published industry benchmarks, for the simulation defaults

• TxDOT traffic counts, for real road volume

• Google Maps, for the locator

Data and backend

• Supabase, which is hosted Postgres, for the property records and the signup capture

• psycopg2, for the bulk load

• rapidfuzz, for fuzzy matching on owner names that never spell the same way twice

• pydantic, httpx, requests, python-dotenv

The simulation

• Three.js r128, drawing 3-D in the browser

• One single HTML file, no build step, no server, opens from disk

The website and the intel area

• Next.js 16 with the App Router, React 19, TypeScript

• Tailwind v4, for layout only, with the brand tokens as plain CSS variables

• DM Serif Display and Hanken Grotesk, through Google Fonts

• ESLint

Hosting and plumbing

• Vercel, deploying on push from GitHub

• Namecheap, for DNS

• GitHub, private repos

• Basic Auth in Next.js middleware, gating the intel area

• Linear, tracking the build phases

Image and brand

• Nano Banana, for the renders, the characters and the marketing aerials

The cast list is new. The buyers are Microsoft, Amazon, Dow, Nucor — not utilities. The vendors are NuScale, X-energy, GE Hitachi, TerraPower — most of them haven't built a commercial unit yet. The regulator is the NRC, working through a new framework while the deal flow accelerates around it. Every seat at the table is filled by someone the industry has barely worked with before.

The most overlooked thing about the SMR moment is who’s actually doing the work. The participants are not the people who built America’s last reactor fleet. The buyers used to be regulated utilities with rate-base recovery and decades of nuclear operating history. Now they’re hyperscalers with multi-decade compute demand curves and balance sheets that can underwrite twenty-year industrial PPAs without state approval.

The vendor side has flipped too. The companies racing to be first to commercial deployment — NuScale, X-energy, TerraPower, Kairos, BWXT, GE Hitachi — are a mix of nuclear veterans and venture-backed startups, but almost none of them has actually delivered a commercial U.S. unit. Each project is first-of-a-kind for the company, the customer, and the supply chain simultaneously. The relationship history baked into a traditional reactor project — the utility’s lobbyists, the vendor’s nuclear veterans, the state PSC’s familiarity with how a license modification gets reviewed — is just gone.

That changes the politics of every project and it changes where risk lives. The customer is now an investment-grade corporate balance sheet. The vendor is staking the company on the first units. The lender is underwriting industrial infrastructure rather than a regulated asset. The success or failure of the first ten projects will be determined less by reactor physics than by how quickly the new participants learn to work with each other and with the NRC.

To read the rest of this guide — What, When, Where, Why, How, plus the frames and why-it-matters sections — head to the full version: → The Friction Layer’s Guide to SMRs in the US Industrial Corridor

Read time · 12 minutes

Works with · Claude, Gamma, Manus AI, Perplexity, Canva AI, ChatGPT, Gemini, Grok

What you get · 60+ terms · translation table · 3 worked examples

When you ask an AI tool for a slide deck, a LinkedIn carousel, or a one-pager, the words you choose are the job. "Make it look professional" gets you a stock photo and a gradient. The vocabulary in this guide gets you something that looks intentional, premium, and unmistakably yours — built for the VP of O&M, the plant manager, the engineer, and the operator who never went to art school but ships visual work all day.

Pattern · 01 / The Premise

Why words are the lever.

The bottleneck isn’t the AI. It’s you describing what you want.

The model has the talent. It has seen millions of decks, magazine spreads, annual reports, billboard campaigns, and editorial layouts. It can produce something genuinely good — when you tell it what good looks like.

The problem is that most people ask the way they’d ask a junior assistant. “Make it look professional.” “Make it pop.” “Add some color.” The model has no idea what you mean, so it averages across every “professional slide” it has ever seen and gives you the average. The average is terrible. Stock photos. Drop shadows. Three colors in a row that nobody chose. A pie chart nobody asked for.

Designers don’t talk that way. They name specific things — weight, leading, contrast, hierarchy, focal point, density, alignment, mood — because those are the dials you actually turn to make something look like something. When you learn the same vocabulary, the AI stops guessing. It executes.

This guide is the vocabulary. Every section names the terms designers use, what they mean, and how to drop them into a prompt the next time you’re staring at a screen at 11pm trying to make a turnaround proposal not look like every turnaround proposal.

Pattern · 02 / Frame the Ask

The brief itself.

Before you ask for anything visual, give the AI the brief. Five short lines beats a paragraph of vibes every single time.

The Five-Part Brief.

aka the only template you need

What it is. Who it’s for. What it should feel like. What it must contain. What it must not do. Five lines, and the AI has more direction than most marketing departments give a designer.

What: 6-slide LinkedIn carousel.
Who: maintenance planners at refineries.
Feel: calm, technical, credible.
Contain: 3 reasons turnaround packages drift.
Don’t: icons, stock photos, gradients.

The Reference Move.

aka “make it look like X”

Naming a known visual style is the fastest cheat code in prompting. The AI has indexed every magazine, brand, and museum on the internet — point at one and it knows what to do.

Naming the Feeling.

aka mood words

Designers reach for emotional words because they cluster a hundred decisions at once. “Calm and credible” rules out neon, drop shadows, and bold gradients without you having to list them. Pick two adjectives. Use them every time.

Constraints as a Feature.

aka the “do not” list

Half the work of looking premium is what you removed. Telling the AI what NOT to do is faster than describing what to do — and it’s the single biggest difference between a prompt that produces something polished and a prompt that produces a Christmas tree.

Pattern · 03 / The Bones

Structure & layout.

How the page or slide is divided. Get this right and most other things fall into place.

Hero.

aka the opening, the cover slide

The first thing someone sees. On a slide deck it’s the cover. On a carousel it’s slide 1. On a one-pager it’s the top third. Big headline, supporting line, one visual element. No more.

Section.

aka content block, a slide

A horizontal band of related content with its own headline. A 6-section page is a 6-slide deck is a 6-card carousel. Same logic, different format.

Grid.

aka columns system, layout grid

Invisible vertical lines that everything snaps to. A 12-column grid is the standard. Telling the AI to “snap everything to a 12-column grid” eliminates the thing that makes amateur layouts feel off — elements that almost align.

Columns.

aka content columns

Vertical sections that hold content side by side. Three equal columns is the most common card layout — comparison, three steps, three pillars. Two columns is for compare-contrast.

Above the Fold.

aka first viewport, the cover

What you see before you scroll. The most valuable real estate on any page or any slide. If the message isn’t here, most people never see it.

Full-Bleed vs. Contained.

aka edge-to-edge vs. boxed

Full-bleed = visual runs to the edges. Contained = content stays inside a centered box with margins. Full-bleed feels modern and immersive. Contained feels editorial and structured. Most premium decks alternate.

Slide Layout.

aka the master template

Every premium deck uses 4–6 layouts on repeat: title-only, title plus body, full-bleed photo with overlay, two-column, callout, and end-card. Naming the layout is more powerful than describing what should go on it.

Pattern · 04 / The Secret Sauce

Spacing & rhythm.

Designers will tell you 80% of the difference between cheap and premium is just spacing. They’re not exaggerating.

Padding.

aka inner space, internal spacing

Space INSIDE an element, between its edge and its content. Big padding inside a card = roomy and premium. Tight padding = compact and dense. The single fastest way to make a slide feel expensive: increase padding.

Margin.

aka outer space, external spacing

Space OUTSIDE an element, between it and its neighbors. Pushes things apart. The dashed area is the margin around the green blocks. Margin is what creates breathing room between sections.

Whitespace.

aka negative space, breathing room

Empty space. Not a mistake — the point. Whitespace tells the reader where to look and makes the content that IS on the page feel important. Premium brands use a lot of it. Discount brands cram every pixel.

Density.

aka information density

How much stuff is packed into a given area. Low density = roomy, premium, easier to read. High density = data-dense, technical, harder on the eyes. A board memo wants low density. A reliability dashboard wants high density. Match the density to the use.

Vertical Rhythm.

aka spacing scale

The repeating beat of space between elements. Good design uses a consistent scale (8, 16, 24, 32, 48, 64) instead of random numbers. The AI gets this right when you tell it to. It guesses when you don’t.

Pattern · 05 / Type

Typography.

The voice of the page. Most “this looks bad” judgments come from type before anything else.

Font Weight.

aka how thick the letters are (300–800)

Modern type families have 5–8 weights. Weight does the heavy lifting of hierarchy — you don’t need a second font, you need the right weights of one. 800 for display, 700 for headers, 600 for emphasis, 400 for body, 300 for captions.

Type Scale.

aka size hierarchy

The set of font sizes you use. Pick 4–5 sizes and stick to them: 11, 14, 17, 24, 44 is a fine scale. The mistake is using 12 different sizes — the page feels chaotic.

Leading.

aka line-height, line spacing

Vertical space between lines of text. Tight leading (1.1–1.2) for big headlines. Loose leading (1.5–1.7) for body copy. Bad leading is the #1 reason long text on a slide looks like a wall.

Tracking.

aka letter-spacing

Space between letters. Negative tracking (tight) on big headlines makes them feel modern. Positive tracking (wide) on small uppercase labels makes them feel editorial. Wrong tracking instantly says “amateur.”

Eyebrow → Headline → Support.

aka the editorial stack

The premium pattern at the top of every section. A small uppercase label (eyebrow) tells you the category. A big headline tells you the point. A short subtitle adds context. Three lines, all the work.

One Family, All Weights.

aka the no-second-font rule

You don’t need a second font. Geist, Inter, IBM Plex Sans, Söhne, or Helvetica Now in 5 weights does more than any pairing. The “designer who picks two fonts” thing is the wrong fight 95% of the time.

Pattern · 06 / Color

Color & mood.

Color is mood. Get the mood right and the rest follows.

Palette.

aka the whole color set

The full set of colors you’ll use. A premium palette is small — usually 3–5 colors. A page background, a content surface, one accent, charcoal text, and maybe a faded version of the accent. That’s it.

Accent.

aka the one color that pops

The single color that draws the eye. One accent per page is the rule. Two accents is a compromise. Three is a clown suit. Use the accent on what matters most — a CTA, a key number, a section divider.

Neutral.

aka the supporting cast

The grays, off-whites, and tans that hold the page together. Pure black on pure white feels harsh. Charcoal on warm stone feels human. Pick neutrals that are slightly warm or slightly cool — never neutral-neutral.

Contrast.

aka readability, accessibility

The difference in lightness between text and background. High contrast is readable. Low contrast looks pretty in a Figma file and unreadable in an email. The block on the right below is what bad contrast looks like.

Mood Words.

aka the shortcut to a palette

Asking for “a calm, credible palette” gets you something usable. Asking for “blue and gray” gets you a 1998 corporate intranet. Mood words encode dozens of decisions — saturation, temperature, pairing — into two adjectives.

No Gradients, No Shadows.

aka the modern minimalism rule

Both gradients and drop shadows date a design instantly. They were the look of 2010s startup decks. The current premium look is flat color, hairline borders, and generous whitespace. If you want to look modern, just say no.

Pattern · 07 / Composition

Composition.

Where the eye goes, in what order, and why. The invisible directing of attention.

Alignment.

aka edges that line up

Things on a page should share invisible left, right, or center edges. Misalignment by even 4 pixels is the thing your eye hates and your brain can’t name. Left-aligned is editorial. Center-aligned is for one-line statements only.

Hierarchy.

aka what reads first, second, third

The order the eye picks things up. Big and bold reads first. Small and gray reads last. Most amateur work has no hierarchy — every element is fighting for attention, so none of them get it.

Focal Point.

aka the hero element

The one thing on the page that wins. There can only be one. Make it bigger, bolder, or the only thing in the accent color — but only one of those, not all three.

Negative Space.

aka let it breathe

The empty area around your content. The most underused tool in industrial decks. A slide with one sentence and a lot of empty space around it lands harder than a slide with seven bullets. Always.

Balance.

aka does it tip over

When you squint at the page, do the visual weights feel even — or does one corner feel heavy? Symmetric balance is calm and formal. Asymmetric balance is dynamic and modern. Both are fine; “off-balance” is not.

Pattern · 08 / Imagery

Imagery.

When you do use a photo, here’s how to ask for one that doesn’t look like LinkedIn 2014.

Aspect Ratio.

aka the shape of the image

Square (1:1) for social. Portrait (4:5) for LinkedIn carousels. Wide (16:9) for slides. Naming the ratio up front saves you from getting an image that’s been mangled to fit.

Full-Bleed Image.

aka edge-to-edge photo

A photo that covers the entire slide with text overlaid. Premium move for cover slides and section dividers. Looks expensive when paired with a darkening overlay so the type stays readable.

Candid vs. Stock.

aka real vs. fake

Stock photos of “factory workers smiling” are uniformly terrible. Always have been. Always will be. Either use real photos from your site, real iPhone photos from a job site, or skip the photo entirely and let typography do the work.

Monochrome Treatment.

aka the editorial photo trick

Convert any photo to black-and-white or a tinted single color. Instantly takes a mediocre image and makes it look intentional. Editorial magazines do this all the time. Almost no industrial decks do it. They should.

The Industrial Photo Problem.

aka why stock falls apart for our world

There are maybe twelve good stock photos of refineries on the internet, and you’ve already seen all of them. Same with pump skids, well sites, and control rooms. If imagery matters, get a real one. If it doesn’t, replace it with a typographic slide and a single accent shape. That looks better anyway.

Pattern · 09 / Voice on the Page

Voice on the page.

Industrial folks over-explain. Slides should be condiments, not the meal.

One Idea Per Slide.

aka the discipline rule

Every slide has one idea. If you have two ideas, you have two slides. The most common bad-deck mistake is cramming three points onto one slide because someone is afraid of “too many slides.” Nobody is afraid of too many slides. They’re afraid of bad ones.

Punchy Declarative.

aka stop hedging

Headlines on premium slides are short, declarative, and have a point of view. “Three Pumps Killed Our Turnaround” is a headline. “An Overview of Pump Performance Issues During Q2” is a section in a textbook.

No Bullets (Almost).

aka the bullet ban

Bullet points are where ideas go to die. They flatten everything to the same weight. If you must have a list, make it three items max, each a complete sentence. Otherwise: turn each bullet into its own slide.

Specific Numbers.

aka the credibility shortcut

“$56K/year in lost engineering time” lands. “Significant cost savings” doesn’t. The AI defaults to vague unless you push it. Tell it to use specific numbers, and if you don’t have them, tell it to leave the placeholder visible so you remember to fill them in.

The Last Slide.

aka NOT “Questions?”

A “Thank You” or “Questions?” slide is the most wasted real estate in any deck. The last thing on the screen should be the takeaway you want them to remember. Patrick Winston’s MIT lecture rule: the last slide highlights contributions, not gratitude.

Pattern · 10 / Vague → Precise

The translation layer.

Vague words on the left. The same idea, said the way an AI tool can act on it, on the right. This is the page worth bookmarking.

Pattern · 11 / In the Wild

Three industrial examples.

The same vocabulary applied to three real industrial use cases. Vague prompt on the left, precise prompt on the right, and what each one will actually produce.

Pattern · 12 / Across Every Tool

A note on tools.

The vocabulary in this guide is portable. The tool you happen to use this week matters less than you think.

laude PPT, Claude Design, Gamma, Manus AI, Perplexity, Canva AI, Beautiful AI, Tome — every one of them is a thin layer on top of a large language model that has read every design book and brand book on the internet. They differ in interface and in how they format the output, but they all respond to the same vocabulary.

Each one weights certain words slightly differently. Gamma loves the word editorial. Claude responds best when you give it explicit constraints (the “do not” list). Perplexity wants source-aware framing — tell it where its information should come from. Manus AI does well when you describe the layout in spatial terms (top-left, full-bleed, two columns).

None of that matters if you can’t name what you want. Once you can — the language in this guide — you’ll get usable output from any of them. And when a new tool launches next month that’s better than all of them, you’ll know exactly how to talk to that one too.

The model is not the bottleneck. It hasn’t been for a while. The brief is.