How We Scope Software Before Writing Code

The conversation comes first

Every engagement starts the same way: a conversation about what you actually need, not a sales call. We're listening for whether what you're describing is a genuine fit for what we build -- custom software, AI applications, automation systems, data intelligence -- before anything gets written down as a proposal.

If it isn't a fit, we say so. A scoping call that ends in "this isn't for us" costs both sides less than a signed contract that ends the same way three months in.

Discover, then design

Once there's a real fit, the work follows a fixed sequence: Discover, Design, Build, Launch, Improve.

Discover means understanding the actual problem -- not the first solution you described, but what's underneath it. A lot of "we need an app" conversations turn out to be "we need one specific workflow to stop being manual," which is a much smaller, cheaper, and more honest scope than the original ask.

Design is where cost and timeline get put in writing, before development starts. Not a rough estimate that "might grow" -- a real number, attached to a real scope, agreed before any code exists. If the scope changes later, the number changes with it, visibly, not quietly.

Why this order, specifically

Most failed software projects fail at the boundary between Discover and Build -- someone skips straight to building because the request felt simple, and three weeks in it turns out the simple request was hiding a much larger one.

Writing the scope down before building forces that conversation to happen early, when it's cheap, instead of late, when it's a change order.

What this means in practice

• You get a number before you commit, not after.
• Smaller engagements get a lighter version of this -- a written agreement instead of a formal contract -- but the same upfront clarity on cost and fit.
• Ownership and delivery terms are stated in writing before the engagement starts, not negotiated after the fact.

This is the same process described on our Services page and in more detail on How We Work -- this article is the "why," those pages are the "what."

---

If you're trying to figure out whether your project is a fit before reaching out, the short version is: if you can describe the actual problem (not just the solution you've already decided on), we can tell you honestly whether it's something we'd take on. Get in touch.