Building a real production app: what to expect

If you've never commissioned custom software before — or if the last time you did was in the long-contract era — the 30-day version can feel like it shouldn't be possible. It is, but it has a shape, and it helps to know the shape before you start.

Week one is scope and design. You'll spend more time in conversation than you expect. We ask a lot of questions about how the work is done now, who the users actually are, and where the pain is loudest. By the end of the week you should have something you can click through that represents the first version of the product, and a technical plan for how it's going to be built. You'll also have had at least one hard conversation about what *isn't* in the first version. That conversation is the most important part of the week — it's the one that makes the rest of the month possible.

Week two is the core build. The obvious parts — the main screens, the main flows, the main data model — get built out. You'll see things come together quickly because the design and the plan are already settled. Your job in week two is mostly to stay available for questions and to react honestly when you see things. "This doesn't feel right" is a useful piece of feedback at this stage; we can still change direction without breaking anything.

Week three is where most of the real product work happens, and it's the phase most clients underestimate. The software is real enough now that you can actually use it, and using it is different from looking at it. You'll find things that seemed right in the design but feel wrong in practice. We'll rework them. You'll spot edge cases nobody thought of. We'll handle them. This is the iterative loop, and it's where the product actually gets good. Expect to be hands-on — the more time you spend inside the thing, the better the end result.

Week four is launch, but launch isn't a single moment. It's a short sequence: a real environment, real data, real users (usually a handful first), monitoring turned on, and a handover document that tells your team how everything is wired together. By the end of the week you should be running the product, not watching it.

A few things commonly surprise people. The first week is more conversation than code, and that can feel slow. It isn't — it's the reason the rest of the month moves. Your input in weeks two and three matters more than you'd think; software built in a vacuum comes out wrong no matter how fast you go. And the thing that launches on Day 30 is rarely the thing you described on Day 1, which is a feature, not a bug. If the scope didn't change at all, it means nobody learned anything.

A month is a strange unit of time for a software project. It's long enough to build something real, and short enough that you can't hide in process. That's the whole idea.