A lot of software vendors sell a discovery phase before they sell anything real: weeks of workshops, a requirements document, a slide deck describing the system that will eventually get built. We don't run engagements that way, and it's worth explaining why — not as a marketing line, but as an actual operational choice with tradeoffs.
A requirements document isn't evidence anyone can build the thing
A well-written spec proves someone can write a spec. It doesn't prove the team behind it can turn that spec into working software, doesn't surface the integration problems that only appear once real data hits a real database, and doesn't tell a client anything about how fast the team actually moves once building starts. We'd rather spend the first week producing a scoped plan and the second week producing working software a client can click through — because that's the evidence that actually de-risks the engagement.
AgencyOS: what four sprints actually looked like
When we built AgencyOS for ISHC — replacing a recruitment operation running on WhatsApp groups and Excel sheets — we didn't spend six weeks in requirements gathering. We scoped the core entities (candidates, deals, roles, documents) in the first week, had a working candidate-pipeline view by the end of sprint one, and layered in role-based access, document generation, and team performance tracking over the next three sprints. The client was using real (if incomplete) software from week two onward, which meant every subsequent sprint was informed by actual usage, not a hypothesis from a workshop.
Sprints surface the exceptions a spec can't
Every nontrivial system has exception paths nobody thinks to mention in a kickoff call — the deal that gets reassigned mid-pipeline, the candidate with two overlapping visa applications, the approval that needs a second signer only sometimes. A requirements document written in isolation will miss these, because nobody is looking at real data yet. A working system in a client's hands by week two surfaces them naturally, because someone hits the edge case and tells you.
No retainers means the incentive is finishing, not billing hours
We scope a fixed engagement, not an open-ended retainer. That's a deliberate incentive structure: our interest is in shipping a system that works and handing over full code ownership, not in extending an engagement indefinitely. A client who owns their repo and infrastructure from day one isn't locked into us to keep the lights on — which is exactly the leverage we'd want if we were the one hiring a vendor.