Each week in , we show how operators design, build, and run systems — from architecture and workflows to the decisions behind them.

Subscribe now

This Is the Highest-ROI Move You Can Make Right Now

The fastest way to get real operational lift from AI—lift you can feel in the very next message—is to write System Instructions. The actual behavioral framework your model will think inside.

You can draft the first version in under fifteen minutes and immediately see a different class of output: sharper, denser, more disciplined, and less improvisational.
It’s simply the difference between a model trying to please the median user and a model forced to operate under the rules you define.

Most people never feel the absence of System Instructions because the defaults are polite enough to pass as “intelligent.”
But the moment you ask the model to execute a multi-step build, maintain internal logic across sections, or work across days without losing context, the cracks appear.
It guesses.
It fills gaps that needed escalation.
It smooths your work instead of sharpening it.
It forgets the shape of your project.

System Instructions fix all of that.
They teach the model how to think for a specific project, which in turn forces you to articulate what you’re actually doing—with a precision that makes your work more legible to both humans and machines.

This is why the ROI is immediate.
The clearer the framework, the better the model performs, and the more clearly you understand what you’re building.

What System Instructions Actually Do

System Instructions define the behavioral posture of the model: how it escalates ambiguity, how it interprets constraints, where it stops, what it refuses to assume, how it guards density, and how it detects drift.
They turn the model from an improviser into an operator.

The reason most people don’t use them is simple: the interface never demands them.
You can chat with a model for a year without realizing the entire interaction is happening on the default operating system—the same one used for poems, recipes, tech support, college essays, and corporate emails.
That framework is fine for one-offs.
It collapses under real work.

Once you define your own, the model no longer optimizes for friendliness, readability, or “engagement.”
It optimizes for the constraints you specify.
And it finally treats gaps in your articulation as structural blockers rather than creative invitations.

This is the part that surprises most builders: writing System Instructions doesn’t just change how the model operates—it changes how you think.
You’re forced to describe your audience, your density expectations, your escalation rules, your drift boundaries, and your referential logic.
This articulation clarifies the project for everyone involved.

Get It Wrong on Purpose, First

The first real step is not “write perfect System Instructions.”

The first step is forcing the model to show you what its defaults look like when pointed at your project—so you can see exactly what you’re fighting against.

System Instructions are always attached to a specific context. They’re not generic rules for “being helpful.” They are rules for this project, this series, this audience.

For this article, we started by opening a fresh Project in ChatGPT and giving it a short description of what the Nitty Gritty series is supposed to be. Nothing mystical. Just a clear paragraph a human operator would understand:

“The Nitty Gritty is for builders who want to see the wiring — the schemas, formulas, and blueprints pulled straight from production. Each piece shows the real logic behind the decisions we make, the systems we design, and the work that actually ships. This isn’t theory or performance; it’s the fingerprints, trade-offs, corrections, and reasoning pulled from live builds, exposed without filters.”

That’s the first move you should make in your own project:
open a new Project, write a single paragraph that describes what you’re doing, who it’s for, and what the work is supposed to expose.

Once that context was in place, we gave the model one simple instruction:

“Draft system instructions for writing Nitty Gritty articles.”

We knew the first draft would be wrong. We needed it to be wrong.

Because that first failure tells you exactly how the model tries to solve your problem before you constrain it.

The Iteration Arc

From that one sentence, we had the model produce three distinct failures before it gave us something structurally usable.

The point of walking through them isn’t to admire the prose. It’s to show you:

• how the defaults behave,

• how we pushed back, and

• how you can run the same loop on your own work.

Iteration 1 — The “Helpful Internet Writer” Default

The first draft looked like this:

“Write in a friendly, supportive tone to keep the reader engaged. Use simple language and analogies. Summarize key points to reinforce understanding…”

Exactly what you’d expect from a model trained to keep the median user comfortable.

The assumptions baked into this draft were obvious:

• The reader needs reassurance.

• Accessibility matters more than precision.

• Repetition and summaries are a default good.

• “Engagement” is a higher priority than exposing the wiring.

For this series, all of that is wrong. Our readers are operators. They don’t need uplift, hand-holding, or performance. They want density and reasoning.

Our response back to the model was not polite nudging. It was a direct correction of the failure mode:

• We removed friendliness, simplification, analogies, summaries, and engagement tactics.

• We told it the audience does not need to be protected or inspired.

• We told it to focus on ambiguity handling, drift control, escalation behavior, and reasoning discipline.

In your own project, this is where you start doing real work:

1. Look at the first draft and name the failure mode in plain language.

2. List what is unacceptable given your audience and use case.

3. Tell the model exactly what to stop doing, and what behavior it should prioritize instead.

You are not editing sentences. You are correcting the model’s picture of the job.

Iteration 2 — The “Corporate Policy Manual” Swing

Once we stripped out “friendly internet writer,” the model overcorrected in the other direction:

“Maintain neutral, readable communication. Ensure clarity and accuracy. Maintain flow between sections…”

This draft looked like a corporate comms style guide. It was still thinking like a writer trying not to get in trouble, not like an operator bound by constraints.

The failure mode shifted, but it was still a failure:

• Neutrality instead of posture

• “Readable communication” instead of behavioral rules

• Flow and aesthetics instead of constraint enforcement

Our response this round:

• We removed every stylistic preference.

• We told the model that System Instructions must govern behavior, not presentation.

• We made it explicit that tone is a side effect of constraints, not a goal.

Again, your move in your own project is the same:

• Strip out anything that sounds like “be pleasant,” “be neutral,” or “maintain flow.”

• Replace it with rules about what the model should do when it hits ambiguity, conflict, or missing information.

Iteration 3 — The First Functional Skeleton

On the third draft, the shape finally started to match the job:

“Treat ambiguity as a blocker and request clarification before proceeding. Identify drift and escalate when constraints conflict. Avoid assumptions and anchor reasoning to user framing…”

This was the first time the model was talking in terms of behavior instead of vibes. It still wasn’t complete:

• No density rules

• No explicit paragraph discipline

• No clear audience definition

• No wiring ethos

• No safeguards against sliding into PMC / thought-leadership voice

But for the first time, the skeleton was right. The draft described how the model should operate inside the project, not how it should sound.

From here, we did one more pass:

• We pulled in missing constraints (density, voice, escalation, failure handling).

• We forced it to collapse everything into a single block of prose instead of numbered rules.

• We removed anything that smelled like “content marketing,” summaries, or key takeaways.

The next output was good enough to ship into this project: a clearly structured System Instruction block we could paste into the Project’s System Prompt and use to help write the article you’re reading now.

It is not “final.” System Instructions are never final. They are stable enough to test until your next round of corrections.

That’s the standard you should aim for: stable enough to test, not perfect.

Once Your System Instructions Exist, the Real Work Starts

Most people stop here. They have a block of text that looks serious, they paste it somewhere, and they move on.

That’s where most of the value is lost.

System Instructions only pay off if:

Read more

Each week in , we show how operators design, build, and run systems — from architecture and workflows to the decisions behind them.

Subscribe now

For no/low-code and self-taught builders, file hosting is always the hidden weak link. URLs expire. Image hosts throttle. Platforms rename your assets or delete them when you hit a plan limit. And the moment you switch tools, half your automations break.

This guide solves that permanently.

Amazon S3 (Simple Storage Service) is the internet’s universal file cabinet — cheap, stable, and fast. Don’t worry if AWS feels intimidating. You don’t need to “learn cloud infrastructure.” You only need one service and six steps.

Let’s get you set up.

What Is an AWS S3 Bucket?

Amazon S3 is an object storage1 system — meaning it stores files exactly as they are, hands-off and uncompressed, until you decide to change or remove them.

If you upload an image, logo, JSON config, video, or tiny HTML file, S3 keeps it:

• permanent

• globally available

• predictable

• and served from a stable URL that never changes

It’s not a web server. It’s not a database. It’s not “file hosting” in the cutesy startup sense. It’s industrial-grade storage you’ll never have to think about again.

Why We Use It

Most no-code platforms eventually hit the same limits:

• File URLs break

• File hosts rate-limit you

• Assets get renamed

• Storage gets expensive

• Switching platforms creates chaos

S3 avoids all of that. It’s stable, boring, and reliable — exactly what you want from the thing holding all your assets.

It scales down to pennies and behaves the same whether you’re storing five files or five million. And when you update a file, every automation, email, or app using that URL updates instantly.

Why You Need It

S3 gives you a universal home for anything your workflows depend on — separate from whatever app or tool you’re using. That separation is the whole point.

The short version:

1. Your URLs never break.
Files don’t expire, change names, or disappear when a platform updates something.

2. Your stack gets faster.
S3 serves assets at global speed.

3. Your costs drop to almost nothing.
Hosting common assets usually costs under $1/month.

4. Everything in your stack can use it.
Make, Zapier, Bubble, Webflow, n8n, Retool, Framer — all of them accept a public S3 URL.

5. Your system becomes cleaner and more modular.
Files live where files belong. Everything else becomes easier.

Why not store files in your app or hosting provider?

Because those systems are built to run code, not hold assets.

They’re slower, more fragile, and way more expensive for the same job.

S3 gives you speed, stability, and a permanent centralized place for the parts of your system that shouldn’t ever move.

What you can actually do with S3

• Host images for emails, automations, or landing pages

• Store JSON configs for workflows

• Serve icons, brand assets, or videos

• Keep a permanent, versioned library of files

• Use one stable URL everywhere

You’re not becoming an AWS engineer.
You’re simply using the one AWS service that makes everything else in your stack easier.

Creating an AWS Account and S3 Bucket

Before You Start
The AWS Console looks messy the first time you see it. That’s normal. AWS hides simple things behind complicated menus.

Ignore 95% of what you see — you don’t need it.

Just follow these steps exactly. We’ll tell you what matters and what you can safely disregard.

Step 1: Create Your AWS Account

1. Go to: https://portal.aws.amazon.com/billing/signup

2. Verify your email, payment method, and phone

3. You’ll be signed in as the root user

You only use the root user for billing and top-level account operations. Everything else happens from a safer admin account.

Step 2: Create a Secure Admin User (IAM)

1. Open IAM

Search for IAM in the console → open Identity and Access Management.

2. Add MFA to the Root Account

• Click your name (top-right) → My Security Credentials

• Under MFA, choose Activate MFA

• Select Virtual MFA device

• Scan with Authy/Google Authenticator

• Enter both codes

Your root account is now secure.

3. Create a New Admin User

Go to: IAM → Users → Add users

• Username: admin or your name

• Enable: Provide user access to the AWS Management Console

• Use Autogenerated password

• Require a password reset

Click Next.

4. Create an Admin Group

• Add user to group → Create group

• Name: Admin

• Policy: AdministratorAccess

• Confirm and create

5. Save Your Sign-In URL

AWS gives you a login link like:

https://your-account-alias.signin.aws.amazon.com/console

Bookmark it.

6. Log In as the Admin User + Add MFA

Log out of root → log in via your new URL → create a new password → activate MFA again.

Your daily-use admin identity is ready.

Step 3: Create Your S3 Bucket

1. Search for S3 in the AWS Console

2. Open it → click Create bucket

3. Name your bucket (lowercase, hyphens allowed)

4. Choose your nearest region

5. Leave ACLs disabled

6. Keep Block Public Access ON for now

7. Click Create bucket

This is your permanent asset home.

Step 4: Make the Bucket Public (For Non-Sensitive Files)

If you’re storing images, logos, or static assets, making the bucket public is safe and gives you universal, easy URLs.

1. Disable Block Public Access

Bucket → Permissions → Edit
Turn off all four toggles → Confirm.

2. Add This Bucket Policy

Replace YOUR-BUCKET-NAME:

{
  “Version”: “2012-10-17”,
  “Statement”: [
    {
      “Sid”: “PublicReadGetObject”,
      “Effect”: “Allow”,
      “Principal”: “*”,
      “Action”: “s3:GetObject”,
      “Resource”: “arn:aws:s3:::YOUR-BUCKET-NAME/*”
    }
  ]
}

Save.

Note: Do not change the Version date to match the date you paste it. Leave it as-is.

3. Test It

Upload a test image → open the Object URL → try it in Incognito.

If it loads instantly, you’re set.

Step 5: Add Cache Headers (Optional but Recommended)

Caching makes your files load faster and reduces costs.

1. Open your file → Properties

2. Edit Metadata

3. Add:

   • Key: Cache-Control

   • Value: max-age=86400

Save.

Step 6: Verify Access and Understand Cost

Test your file’s URL in a private window.

For typical no-code/automation usage, your monthly cost is usually under $12 — often covered entirely by the AWS Free Tier.3

Just keep public assets separate from private data.

You’re Done

You now have:

• A permanent home for your assets

• Stable URLs that never break

• A faster, cleaner, more reliable automation stack

• A future-proof system that won’t collapse when you switch platforms

Top Object Storage Alternatives to AWS S3

If you want the deeper layers of this work — the wiring, configs, edge-case failures, and the full iterations — you can unlock all of it by becoming a member.

And if you’re at the point where you’d rather have this built inside your business instead of trying to replicate it yourself, start with our $5K Starter System:
10 days. One workflow. No contracts. Full ownership.

Subscribe now

Share

Leave a comment