Why I'm Building Build w/ Greg

I keep coming back to the same kind of project.

Around 2009, the first real website I made was called Plans4Ramps. I modeled skateboard ramps in SketchUp, generated flyovers of the construction process, and published material lists and instructions for each design.

Years later, after making my first cutting board, I started thinking about building a cutting board designer that could generate different patterns and glue-up instructions.

I've written tutorials about things I've learned, including extremely serious subjects such as making a wallet from a sheet of paper and a rubber band.

I built a truck camper from scratch. I started making an acoustic guitar. I built a small keyboard macro pad from individual components, even though I knew very little about electronics when I began.

For a long time, these felt like unrelated interests.

I'm starting to realize that they're all expressions of the same impulse:

Find something I don't fully understand. Learn it deeply. Build it. Make mistakes. Then leave a better trail for the next person.

Build w/ Greg is an attempt to turn that impulse into a place.

I like learning difficult things

I seem to be drawn toward projects that sit slightly beyond what I currently know how to do.

Sometimes that means building a camper. Sometimes it means learning electronics. Once it meant training for an ultramarathon, mostly because the process seemed difficult and interesting and I wanted to know what it felt like to get there.

The finished object or achievement matters, but it's rarely the entire point.

I want to understand it.

I want to understand why something is built the way it is, which decisions matter, where the common advice falls apart, and what only becomes obvious after making several mistakes.

Then, once I understand it, I naturally want to organize what I learned into a form that makes the journey easier for someone else.

That may be the thing I enjoy doing most.

Code was always a means to an end

I've spent most of my career building software, but I've never been especially attached to writing code for its own sake.

Code was the material I used to create products, solve problems, and make ideas real.

AI is changing how software gets built. A lot of implementation work that once took days can now happen in hours. I understand why that feels threatening to some developers, but I find it surprisingly liberating.

It lets me spend more time on the parts I care about most:

• product design
• interaction design
• problem solving
• teaching
• visual communication
• engineering decisions
• deciding what should exist in the first place

Build w/ Greg isn't really a move away from software.

It's an attempt to apply software to the physical world.

What Build w/ Greg is

The simplest description I have so far is:

Build w/ Greg is an interactive publication for people who love making things.

Each project combines a few things that normally live separately:

• a story about why the project exists
• an explanation of the important design and construction decisions
• interactive figures that can be rotated, animated, and changed
• a configurable design studio
• a complete, scrubbable build timeline
• generated material lists, cut information, and plans

The experience follows a simple progression:

Pick a project. Understand it. Customize it. Build it.

A project page should initially feel like a thoughtful article. As you read, the illustrations come alive. You can rotate an assembly, move through its construction, change a dimension, or compare two techniques.

Eventually, the article opens into a full design tool.

The goal isn't merely to explain how an object works. It is to explain how it works in the context of building it.

Why was this joint chosen?

Why does this operation happen before that one?

How does changing the material affect the construction process?

Which dimensions can safely change, and which relationships need to remain fixed?

What shortcuts work well, and which ones create trouble later?

That practical construction knowledge is often scattered across forum posts, videos, old plans, and the memories of people who have already made the mistakes.

I want to bring it together and make it explorable.

Starting again with ramps

The first public project is a kicker ramp, which brings the idea back to where it began with Plans4Ramps.

A kicker looks simple, but building a good one involves a surprising number of details.

You need to understand what a transition radius is and how it affects the shape and feel of the ramp. You need to know how to lay out the curve on plywood, including how to offset it for multiple surface layers so the finished transition meets the ground correctly.

You can draw the curve with a temporary pivot and a long piece of wood or string. Once one side is cut, you can flip it over and use it as a template so both sides match. The same template can be reused if you're building several ramps.

The front, top, and rear framing members need to be positioned carefully. The intermediate cross members need sensible spacing. When the ramp is wide, the framing becomes hidden as soon as the first plywood layer is installed, so even placing the screws accurately requires a technique. One option is to leave screws slightly proud at each edge and stretch a string between them to reveal the centerline of the hidden framing.

Then there are the riding surfaces.

How thick should the plywood be? When should you add Masonite? What changes for outdoor use? How should a metal transition plate meet the ground, and how thick should it be for a skateboard wheel to roll onto it smoothly?

Some of these things I already know well. Others, particularly the skateboard-specific details, I still need to research and test.

That is part of the point.

I don't want the project to contain only the knowledge I happened to have before I started writing it. I want the process of creating the project to deepen my own understanding too.

Over time, the Ramp Studio could expand beyond a single kicker. A kicker, quarter pipe, and mini ramp are not entirely separate ideas. They are related points in the same design space.

It would be fascinating to let someone watch one form evolve into another, while the structure, material requirements, and build process change with it.

A future lesson about selecting a transition radius might even include a simple physics simulation showing how speed, radius, launch angle, distance, and forces relate to one another.

Not because every project needs a simulator.

Because sometimes interaction is the clearest way to understand an idea.

Studios are design spaces

I don't think every project should be one fixed object.

Some subjects naturally want to become small, focused design applications.

A Cutting Board Studio could explore:

• edge grain and end grain
• wood species
• patterns
• dimensions
• glue-up sequences
• material waste
• juice grooves
• handles
• feet and hardware

A Box Studio could explore:

• dimensions
• materials
• dovetails
• box joints
• rabbets
• lids
• hinges
• drawers
• hardware

A Mechanical Keyboard Studio could eventually combine:

• case design
• switch layouts
• plates
• PCBs
• firmware
• soldering
• mounting styles
• acoustics
• materials

A Lamp Studio could go beyond geometry and let someone experiment with light: beam angle, diffusion, brightness, color temperature, shadows, electronics, and thermal design.

A Guitar Studio might explore body geometry, scale length, neck profiles, bracing, wood selection, bending, and acoustics.

These are large subjects. That is precisely what makes them interesting.

The goal would not be to generate an arbitrary object from a sentence and pretend it is good. It would be to create a carefully designed space in which meaningful choices can be explored safely and clearly.

Projects, concepts, and courses

Projects naturally refer to knowledge that is useful elsewhere.

A ramp project might need an explanation of transition radius.

A plant stand might introduce half-lap joints.

A box might use dovetails.

Several projects might need the same explanation of wood movement, router setup, sanding, finishing, or choosing fasteners.

Those ideas should be able to live on their own as reusable concept pages.

A concept page could answer:

1. What is this?
2. Why would I use it?
3. How do I make it?
4. Where is it used?

It could include its own interactive figures, comparisons, practical advice, and links to projects that use the technique.

Eventually, those concepts and projects could be assembled into broader learning paths.

A beginner woodworking course would not need to duplicate all the content. It could be a thoughtful sequence through existing concepts and projects:

• learn how to make accurate crosscuts
• use them in a small project
• learn how dados work
• apply them to shelves
• learn about wood movement
• use that understanding in a cutting board or box

The projects provide a reason to learn. The concepts make the knowledge reusable. A course provides a path through both.

I don't need to begin as the expert

Some Build w/ Greg projects will come from subjects I already understand.

Others will begin with me as a relative beginner.

I think that can be an advantage.

Someone who recently learned a subject still remembers which parts were confusing. They remember the wrong assumptions, the unclear terminology, and the details that experts sometimes skip because those details have become automatic.

But learning in public does not mean presenting every first attempt as authoritative.

For unfamiliar subjects, the process needs to include research, prototypes, testing, revisions, and honest uncertainty. Designs that affect safety need to be treated with particular care. A generated model or simulation is not proof that something is structurally sound.

The goal is not to pretend I knew the answer all along.

The goal is to document the process of finding a reliable answer.

The plans are alive

Traditional plans are frozen.

They describe one version of one object, built with one set of assumptions.

Build w/ Greg projects are generated from materials, dimensions, operations, and relationships. Change an important parameter and the entire project can respond:

• geometry changes
• parts change
• cuts move
• material quantities update
• dimensions update
• the build timeline regenerates
• the downloadable plans reflect the new design

The same project definition can also create the animated walkthrough, interactive article figures, thumbnails, build previews, and other visual material.

That leverage is one of the things that makes this possible for me as an independent creator.

Instead of separately producing an article, animation, configurator, cut list, and set of plans, they can all be different views of the same underlying project.

Curiosity should remain accessible

I don't yet know exactly how Build w/ Greg will make money.

I'm comfortable with that for now.

The first goal is to make something genuinely useful, interesting, and delightful. I want to see which parts people return to, what they try to build, and what they ask for next.

I do have one principle that feels important:

Curiosity should not hit a paywall.

People should be able to discover a project, read its story, manipulate the figures, explore the studio, and understand how the build comes together.

If there is a paid layer, it should begin when someone decides to move from exploring into actually making.

That might eventually include:

• detailed manufacturing outputs
• printable shop drawings
• generated templates
• STL, STEP, DXF, or CNC files
• saved designs and version history
• workshop progress tracking
• offline build mode
• notes and photos
• printed parts or hardware packs
• support, membership, or community features

I don't want to charge people for being curious.

I want to charge for making the difficult parts of building easier.

A library, not a content treadmill

I'm also not interested in building a business that requires me to publish a disposable video every week forever.

These projects should remain useful.

A good explanation of how to lay out a ramp transition can still be useful five or ten years from now. So can a box-joint guide, a cutting board designer, or an explanation of how a keyboard matrix works.

Over time, the site can become a library of deeply explored subjects.

Each project adds knowledge.

Each concept supports more projects.

Each improvement to the underlying engine improves everything built with it.

The goal is not to publish the largest number of projects.

It is to make each project worth returning to.

The "you have to see this" test

Even though these projects can become very deep, the first interaction should remain simple and delightful.

Every studio should contain at least one moment that makes someone want to send it to a friend.

For a ramp, it might be changing the height and watching the entire structure and build regenerate.

For a cutting board, it might be switching patterns and seeing a physically buildable glue-up appear.

For a lamp, it might be adjusting the shade and watching the light change across a virtual desk.

The interaction is not decoration around the content.

The interaction is part of the explanation.

And sometimes it is the best invitation into a subject.

Where this goes

I don't have a ten-year editorial calendar.

I don't want one.

The roadmap is my curiosity.

I want to keep choosing things that are difficult enough to change me:

• a ramp
• a keyboard
• a lamp
• a guitar
• a piece of furniture
• some strange combination of wood, printed parts, aluminum, electronics, and software that I haven't thought of yet

Not every difficult pursuit belongs on Build w/ Greg. I probably won't make an interactive ultramarathon studio.

But the same philosophy applies:

Become a beginner on purpose.

Do the work.

Understand the subject.

Then leave a trail.

That is what I want Build w/ Greg to become: a place where I can explore difficult things deeply, turn what I learn into living tools and explanations, and make the path clearer for whoever comes next.