Brief to working software in days: what it actually takes

By Nick Beaugeard · 6 minute read · ← All posts

Clients sometimes read "brief to working software in days" on our site and assume it is a tagline rather than a commitment. It is a commitment, but it is a commitment with preconditions. This post lists them, so you can tell whether your engagement is one we can actually ship that fast.

The five preconditions

1. A real decision-maker on your side

Speed collapses the moment a decision has to wait for a committee. The engagement needs a single person on the client side who can answer questions like "is this screen good enough for beta?" within hours, not days. The decision-maker doesn't need to be technical; they do need to be able to say yes or no without going away to align four stakeholders.

2. A scope that fits the timebox

"Working software in days" does not mean a full enterprise platform in five days. It means a meaningful, usable slice that proves the core assumption and lets the next week start from a real thing rather than a deck. We spend the first meeting narrowing scope until a working version is achievable. If you came for a three-platform, ten-integration launch day-one, we will tell you, and propose a different shape.

3. Clean access to the environments that matter

Most of the delay in traditional consulting is waiting for access: repos, Azure subscriptions, identity provider, test data, domain names, DNS. Our Symphony pipeline can write code faster than your IT team can grant permissions. The fix is to start the access paperwork on day one, in parallel with the kickoff, not after it.

4. A willingness to trade polish for truth

In week one we ship something ugly that works. In week two we ship something closer to production. In week three it starts looking the way the final product should. Clients who want production polish in week one are better served by a twelve-week engagement — we will tell you so up front. Clients who want to see the core assumption survive contact with real users in week one are a good match.

5. A stack we already know

We are fast because our default stack is opinionated: .NET, Blazor, ASP.NET Core, Azure, GitHub. If your target stack is React Native with a Golang backend on GCP, we might be the wrong firm for the timebox. We will say so; we'd rather recommend a better-matched firm than take work we cannot ship cleanly.

What we actually do in those first days

Inside the pipeline, day one is scope compression, architecture shape, environment setup and a Symphony-assisted skeleton. Day two is feature one, with tests and documentation alongside. Day three is feature two and a first client review. Day four is refactor, edge cases, and the first external users trying it. Day five is a first production candidate. That is the rhythm. It is not miraculous; it is the default output of a well-run senior pipeline where the mechanical work happens at machine speed while the principal stays present for the decisions.

Working software in days is not about typing faster. It is about removing the gaps between decisions.

Briefs where this does not work

We are honest about the briefs where the five-day promise breaks:

• Enterprise procurement-led engagements. If week one is dominated by MSA and data-protection impact assessments, "working software in days" measures from the wrong start.
• Regulated clinical or financial products where compliance sign-off is the gating factor and not the build.
• Multi-team coordination engagements where the primary job is aligning three internal teams rather than shipping code.
• Hardware-dependent products where the device bring-up is the critical path.

Those are real engagements; they are not the shape of engagement Symphony compresses. Treat the "days, not months" promise as a filter. If your brief fits, we are one of the fastest firms in the country at shipping it. If not, we will tell you in the first conversation.