From Idea to MVP: What Actually Happens in the First 30 Days of a Software Project

Cover design: Vishvajeet Shukla

Founders asking "how long until we have something real" almost always mean something more specific: what happens between signing on and seeing a working product. Here's what the first 30 days actually look like on our engagements — not a sales-page timeline, the real one.

Week 1 — Discovery, not design

The first week isn't spent in Figma. It's spent understanding the actual business process the software has to replace or support — who touches the workflow today, where the current bottleneck actually is (not where it's assumed to be), and what "done" looks like for a first usable version. Most scope creep later in a project traces back to skipping this step and jumping straight to screens.

Week 2 — Scoping the MVP down, not up

Every founder's first feature list is a v2 list wearing a v1 costume. Week two is spent cutting it down to the smallest slice that lets real users do the core task end to end — not the smallest slice that looks impressive in a demo. Those two are usually different, and the difference matters: an MVP that handles the core workflow for five real users teaches you more than a polished demo that handles zero.

Week 3 — First deployable slice

By the end of week three, there's a real, deployed (even if unstyled) version of the core workflow — not mockups, not a prototype that lives only on someone's laptop. Getting something deployable this early forces architecture decisions to happen when they're cheap to change, instead of three months in when they're not.

Week 4 — First real feedback loop

The fourth week is where the MVP goes in front of actual intended users, not just the founding team. This is usually where the most valuable scope changes happen — not because the original plan was wrong, but because watching a real person hit a real workflow surfaces friction that no amount of internal review catches.

What determines whether the rest of the build goes smoothly

Almost every project that runs into trouble later traces back to one of two things skipped in this first month: scope that wasn't actually cut down in week two, or a "first deployable slice" that was really just a polished-looking mockup with no real data flowing through it. Both feel like they save time upfront. Both cost far more later.

The first 30 days aren't about how much gets built. They're about proving the smallest real version of the idea actually works before committing months to the rest of it.

If a vendor's first-month plan is entirely design files with no deployed, working slice by week three or four, that's worth asking about directly — it's usually the clearest early signal of how the rest of the timeline will go.