Work

From idea to v1: A walkthrough

What the process actually looks like when we work together. Not a rigid methodology—just the pattern that's worked for me over twenty years.

This is a realistic timeline for a typical idea-to-v1 project. Your project might be faster or slower depending on scope. The important part isn't the exact timeline—it's the pattern of how we work and what we're optimizing for at each stage.

Throughout this process, my goal is to keep things radically simple. No unnecessary meetings. No ceremony for the sake of ceremony. Just clear communication, small decisions, and steady progress.

First conversation

What happens

We talk. Not a sales call—just an honest conversation about your idea. I need to understand what you're trying to build, who it's for, what problem it solves, and what success looks like to you.

At the end of this conversation, we both know if this makes sense. If I don't think I can help you, I'll tell you. If the idea doesn't add up, we'll talk about why.

Questions that come up

  • "How much will this cost?"
  • "How long will it take?"
  • "Do I need to know exactly what I want before we start?"
  • "What if my idea changes?"

On keeping it simple

No long proposals. No multi-page contracts at this stage. Just a conversation. If we're both in, we'll agree on a small first phase—usually 1-2 weeks of work—so we can start without committing to the whole project up front.

Understanding and shaping

What I'm doing

Asking questions. Lots of them. Who are your users? What are they doing today to solve this problem? What's the minimum version that would actually be useful? What can we cut and still have something valuable?

I'm taking your rough idea and distilling it down to its core. We're figuring out what v1 actually needs to be—not what it could be six months from now, but what it needs to be to test if this idea has legs.

Questions that come up

  • "What if users need feature X?"
  • "Should we build this for mobile or web first?"
  • "How do we know if we're cutting too much?"

On keeping it simple

I'm not writing a 40-page spec document. Usually this is just notes in a doc. Bullet points. Rough sketches. The goal is clarity, not documentation. We're making sure we're building the same thing in our heads before we start building it for real.

First working version

What I'm doing

Building the core. Not everything—just the part that proves the idea works. This might be a single user flow. It might be the main screen and one key interaction. It's rough, but it's real.

The goal here is to show you something tangible as fast as possible. Not perfect. Not polished. But real enough that we can both look at it and say "yeah, that's it" or "no, that's not quite right."

Questions that come up

  • "Can we change the way this works?"
  • "What about edge case X?"
  • "When can I show this to someone?"

On keeping it simple

We're not doing daily standups. We're not using JIRA. I'll send you updates when there's something worth seeing. You'll give me feedback when you have it. That's it. The simpler we keep communication, the more time I have to actually build.

Building the rest of v1

What I'm doing

Filling out the product. Adding the other screens, the other flows, the things we agreed were must-haves for v1. This is where the product starts to feel like a product instead of a prototype.

I'm making small decisions constantly. Do we need this button? How should this error work? What happens if the user does this weird thing? Most of these I'll just make. The important ones, I'll ask you about.

Questions that come up

  • "Can we add just one more feature?"
  • "What if we change this part of the plan?"
  • "How much longer until launch?"

On keeping it simple

This is where scope creep kills projects. We're tracking changes, but loosely. A doc. A list. Not a complex project management system. If something new comes up, we decide: does it go in v1, or does it wait? Most things can wait.

Testing and polish

What I'm doing

Breaking things on purpose. Clicking buttons in weird orders. Entering bad data. Trying to use the product the wrong way. Finding the bugs before your users do.

Also making it feel finished. Better error messages. Smoother transitions. Little touches that make it feel like you cared. Not overdesigning—just making sure it doesn't feel sloppy.

Questions that come up

  • "Should we show this to a few people first?"
  • "What if we find a big bug right before launch?"
  • "Is it ready, or does it need more polish?"

On keeping it simple

I'm not writing 1000 unit tests. I'm testing the happy paths and the obvious failure cases. Automated tests where they make sense. Manual testing for everything else. The goal is "works reliably," not "100% test coverage."

Launch prep

What I'm doing

Setting up hosting. Configuring domains. Making sure emails work. Setting up analytics. All the boring infrastructure stuff that nobody thinks about until it breaks.

Also: making sure you can actually operate this thing. How do you add a user? How do you see what's happening? How do you know if something breaks? Basic admin tools, basic monitoring.

Questions that come up

  • "What happens if the server crashes?"
  • "How do we know if people are using it?"
  • "Should we have a backup plan?"

On keeping it simple

We're not building a complex deployment pipeline for v1. We're not setting up Kubernetes. Simple hosting. Simple monitoring. Simple tools. We can get fancy later if the product actually takes off.

Launch day

What happens

We flip the switch. The product goes live. This is exciting, but it's not the finish line—it's the starting line.

I'm not disappearing the second you launch. I'm watching for bugs. I'm available if something breaks. We're monitoring how people actually use it, because they never use it the way you expect.

Questions that come up

  • "What if nobody uses it?"
  • "What if people find bugs?"
  • "How long until we know if it's working?"

On keeping it simple

Launch is not an event. It's a process. No big unveiling. No "launch day checklist" with 47 items. We ship when it's ready. We fix issues as they come up. We learn from real users. Simple.

Learning and iterating

What happens

Now we watch. How are people using it? What's confusing? What's broken? What features do they actually want versus what we thought they'd want?

This is where the real product development happens. v1 was our best guess. Now we have data. Now we can make smarter decisions about what to build next.

Questions that come up

  • "Should we build feature X that users are asking for?"
  • "Do we need to rewrite this part?"
  • "When do we start working on v2?"

On keeping it simple

We keep making small bets. Small changes. Small additions. We're learning what works. We're not committing to a giant roadmap. We're staying flexible so we can respond to what we learn from real users.

This is the pattern. Some projects move faster. Some take longer. But the philosophy stays the same: small commitments, clear communication, and keep it simple.

If you want to talk about working together: [email protected]