Today is one of my dearest friends' birthdays.

While talking with him this morning, I showed him an app I've been building. It's a project we've been working on for the last few months, and it's probably the first app I've built that we will try to sell (more to come!)

During that conversation, I realized something: I've been building apps constantly. Some are big. Some are tiny. Some never make it past a prototype. But I'm creating things almost every week, and while I've shared a lot about what I'm building, I haven't shared much about how I'm building them.

That feels like a miss.

The purpose of this newsletter has always been to be human. Yes, I'm excited about AI, software, and new technology, but behind all of that is a person who's simply curious and likes solving problems. And one thing I've come to believe is that far more people should know how to build things for themselves.

We live in a moment where you can have an idea in the morning and have a working version of it by the afternoon. You no longer need to be a software engineer to create useful tools. If you can clearly describe a problem, you can often build a solution.

So today, inspired by that conversation, I promised a birthday present: to walk through the process I use to individual AI tools..

A quick note before I do.

Many people build with highly autonomous AI agents that have access to their email, calendar, files, and other systems. That's a perfectly reasonable approach, but it's not the one I use.

Most of my projects are built on my work laptop using OpenAI's enterprise tools. I started building with Claude and still think it's excellent, but I've largely standardized on OpenAI because that's what I have available through work. In my experience, the underlying principles are similar regardless of which company you choose.

I've also intentionally kept my workflow relatively constrained.

The more access you give an AI system, the more useful it can become; but the more risk you introduce as well. We've already started seeing examples of prompt injection and other attacks designed to manipulate AI-powered systems. As these tools become more connected to our calendars, inboxes, and workflows, I think it's worth being thoughtful about what permissions we grant.

My approach is probably less efficient. Every time I sit down to build, I manually open the tools I need rather than giving an agent broad access to everything.

I timed it recently. The extra setup takes about four minutes. For now, I'd rather spend four minutes opening tools than give away more access than I'm comfortable with.

Most of the time, I start with ONE problem, spend a few hours building an MVP as a means to solve that problem, and see if it's useful. This is the exact workflow I use.

Before you build anything, create accounts with these four services:

I use an OpenAI Enterprise account through work, but a paid $20 ChatGPT subscription should be enough for most projects, you might just need to be thoughtful of your token consumption.

My recommendation: use one email address for everything so it's easy to manage later.

Think of GitHub as the home for your project.

When I start a new tool, I:

A Codespace is simply a cloud-based development environment. It lets you build without setting up a lot of software on your computer.

From there, you’ll see this image above, Github’s cloud terminal, which you could use. But I prefer to open the project in VS Code (Visual Studio Code), which is the editor where I do most of my work. I use a PC, so this might not be available for a Mac. You might be able to download the Codex app itself (I can’t download apps on my work computer).

This is the most important step.

Before writing any code, I open ChatGPT and use the following prompt:

Then I spend about five minutes talking (it’s the prompt + my dictation)

I don't use a template.

I don't worry about structure.

I simply explain:

It's basically a brain dump.

The goal isn't to create a perfect plan. The goal is to get my thoughts out of my head.

ChatGPT then turns that messy thinking into a much clearer product specification.

Once I have a cleaned-up specification, I move that updated prompt ChatGPT wrote for me into my development environment. Make sure you’re actually using Codex if you’re in a terminal, you can add it by going to extensions then adding Codex.

I usually add a couple of project files that help keep the AI organized on my left toolbar:

These aren't required, but they've become part of my workflow.

From there, I start building.

Whether you're using Codex, a terminal, or another AI coding tool, the process is essentially the same: give the AI a clear specification and begin iterating.

This is where most people make things harder than they need to be.

Don't build Version 10.

Build Version 1.

Focus on the smallest possible version that proves the idea works.

As I'm building, I regularly:

Most of my projects reach a usable state within one to three hours.

If I've spent more than three hours and still don't have something working, I usually simplify the idea.

Many of my recent apps use Supabase.

A database is simply a place where your app stores information.

For example:

Not every app needs a database.

But if your app needs a source of truth that persists between sessions, you'll probably want one.

Some projects need access to outside services.

For example:

In those cases, you'll need an API key.

Think of an API key as a permission slip that allows your app to communicate with another service.

Many projects don't need this immediately, so don't let it stop you from getting started.

Once the app is working, I deploy it to Vercel.

Deployment simply means taking the app you've built and putting it online.

This is usually the hardest part for beginners, but once you've done it a couple of times, it becomes routine. Ask Codex to deploy your project to Vercel and it will prompt an authenticator and you can log in.

After deployment, you'll have a public link you can send to friends, coworkers, or potential customers.

That's when your idea becomes a real product.