Agile Systems Engineering · Physical Products
The discipline of systems engineering (architecture, interfaces, verification, validation) run with agile's short, iterative build-test-learn loops. One full lifecycle that scales to the work in front of it.
See the processEvery engagement maps to this lifecycle. You don't have to run all six — just the ones your project actually needs.
Inside every design and prototype phase runs the same three-beat cycle. This is the real unit of work — and the rhythm that keeps you in the loop the whole way through.
Physical phases add Test between Build and Review — real-world data feeds the revision. A revision round is built into every milestone. Bigger new requests become their own scope.
Six clear phases from idea to launch. Gold chips mark the systems-engineering rigor that separates a real product development process from winging it.
First, we talk. I learn your idea, what you actually need, and what "done" looks like — then turn it into a clear scope, an honest quote, and a written spec. We make sure we're building the right thing before anyone touches CAD.
Next, we explore. I sketch a few different ways to solve it, map out how the whole system fits together, and pressure-test whether we can actually build it — including what's available off-the-shelf and whether anyone already owns the idea.
Now we make it real on screen and prove the idea works. Detailed engineering across mechanical, electrical, and software — then fast 3D-printed proofs we test against the spec, round after round, until the concept holds up. This is verification: confirming we built it right against the requirements set in Phase 0.
Then we build something that looks and behaves like the real product — in the actual materials (sheet metal, steel, wood). We test that it holds up, then put it in front of real users to validate it actually solves the original problem. If a material isn't right, we loop back and try another.
With the design proven, we make it manufacturable and get it ready to produce at scale — dialing in the process, locking the design, and lining up suppliers and tooling for launch.
Finally, we hand it off clean (tested, documented, and reconciled), capture what we learned, and stay available to support it: revisions, sustaining engineering, and planning ahead for parts that'll need replacing down the road.
The Forge Method is agile systems engineering: the discipline of systems thinking (architecture, interfaces, requirements) run with short, iterative build-test-learn loops. One DNA. Scales to a quick fab job or a multi-month product launch.
The full six-phase lifecycle is the menu, not the mandate. A small job uses a couple of phases; a new product runs all six. You only pay for the phases your project actually needs.
Before any single part is detailed, the whole solution is mapped as a system — functions split across mechanical, electrical, firmware, and software, with every interface defined. Pieces connect cleanly, not bolted together later.
Work moves in clear milestones. Each one comes to you for review with a revision round already built in, so your feedback is expected and planned for — never a surprise. Bigger new asks become their own scope.
A proof of concept proves the idea works in fast 3D prints. A material prototype proves it holds up in the real materials (metal, steel, wood). Two honest checks, not one hopeful leap.
Verify the product is built right against the spec, then validate it solves your original problem with real users. Building it correctly and building the right thing are two different wins.
Prefer proven off-the-shelf parts wherever they fit. Every custom or unproven component is technical debt paid back later in testing and lead time.
This is the full journey, but you don't have to walk all of it with me. Already have a design that needs prototyping? A prototype that needs a production ramp? We pick it up from there. The process flexes to you, not the other way around.