Every engagement I take on follows the same seven steps: discover, compile, specify, build, test, iterate and ship. What changes is who does the building.

There are two ways I get a product live. Either I build it myself, or I lead the product and AI work alongside your designers and developers. Both end in the same place, a working product in front of real users. They get there differently, and choosing the wrong one costs time.

Option one: I build it

I design, build and ship the product myself, as a live working app on your accounts.

This works best when you need a v1 fast and do not have a team yet. There are no handoffs. The person who sat in the discovery calls is the same person writing the code, so very little gets lost between what you said and what gets built.

What you get:

  • Speed. One senior person with modern AI tools can move remarkably fast on a well-scoped v1, with a working preview every few days.
  • Consistency. Product decisions, design and code come from the same head, so the product feels like one thing.
  • A clean handoff later. Everything lives in your accounts, documented, so the team you hire can pick it up without starting over.

The trade-offs are real, too.

  • One person is one person. There is a limit to how much gets built in parallel.
  • Knowledge sits with me until it is written down. That is why documentation is part of the work, not an extra.
  • Eventually you need a team. "I build it" is a great way to reach a v1 and early traction. It is rarely the long-term shape of a company.

My own products are built this way. Mentor Intelligence went from a static prototype to production with me doing the product, design, front-end, back-end, data and deployment, and BackTrack was designed and built the same way.

Option two: with your team

I lead the product and AI work alongside your designers and developers, and stay until it is implemented and live.

This works best when you have a team and need senior direction. Your engineers may be excellent, but no one owns product decisions, the user experience, or how AI should behave in the product.

What you get:

  • Capacity. Your team builds in parallel, so larger products move faster than one person could.
  • Ownership stays in-house. The people who will maintain the product are the ones building it, and they learn the reasoning behind every decision.
  • A shared picture from day one. Your product, design and engineering leads join the discovery calls, so everyone starts from the same understanding of the problem.

And the trade-offs:

  • Coordination takes time. More people means more alignment, reviews and conversations.
  • Decisions need a clear owner. Without one, a team can debate the same question for weeks. Part of my job is making sure that does not happen.
  • I am only as close to the code as you want me to be. Some teams want reviews and pairing, others want direction and specs. We decide that up front.

How to choose

A few questions usually settle it.

  1. Do you have designers or developers who will own this product long term? If not, start with "I build it." If yes, lean toward "with your team."
  2. How fast do you need something in front of users? For a first v1 under time pressure, one senior builder with no handoffs is hard to beat.
  3. How big is the first release, honestly? A tightly scoped v1 suits one builder. A broad platform with many integrations suits a team.
  4. Where is the gap? If the gap is building capacity, add people. If the gap is product direction and judgment, add leadership.

It is also common to do both in sequence. I build the v1, you hire a small team once it has users, and I stay on for a while to lead them through the next releases. The handoff is smooth because the code, documentation and decisions were written for a team from the start.

The question is not who writes the code. It is who owns the decisions, and whether the product will still make sense to the people who maintain it next year.

Signs you picked the wrong one

It is worth knowing what a mismatch looks like, so you can change course early.

  • You chose "I build it," but the backlog keeps growing faster than anyone can ship. That is usually the moment to hire, not to push one person harder.
  • You chose "with your team," but every week ends with the same open questions. The team has capacity. What it lacks is someone who decides.
  • Nobody outside the build can explain what the product does. In either shape, that means the spec and documentation have fallen behind.

Changing shape mid-stream is normal. A product that starts as a solo build often grows into a team engagement, and that is a good sign, not a failure of the plan.

What stays the same either way

Whichever way we go, a few things do not change. The work starts with discovery and a sourced spec, not a guess. Real users test every preview. AI does the heavy lifting where it helps, and people make the calls. The code and IP are yours, in your accounts, with no lock-in.

If you are trying to decide which shape fits your product, email me with what you are building, where it is today and whether you have a team. That one answer usually makes the choice obvious.