[{"data":1,"prerenderedAt":101},["ShallowReactive",2],{"article-bad-scoping":3},{"id":4,"title":5,"accentColor":6,"body":7,"category":14,"coreIdea":15,"crossLink":18,"ctaBody":24,"ctaLinkText":25,"ctaLinkTo":26,"datePublished":27,"description":11,"extension":28,"headline":29,"headlineAccent":30,"heroParagraph":31,"meta":32,"navigation":33,"ogDescription":31,"ogTitle":34,"path":35,"publishedAt":36,"readTime":37,"sections":38,"seo":73,"seoDescription":74,"seoTitle":75,"sidebarLink":76,"stem":78,"summaryCards":79,"tags":95,"teaser":99,"__hash__":100},"articles\u002Farticles\u002Fbad-scoping.md","Bad Scoping","teal",{"type":8,"value":9,"toc":10},"minimark",[],{"title":11,"searchDepth":12,"depth":12,"links":13},"",2,[],"Scoping",{"heading":16,"body":17},"A clear spec is not the same thing as a clear problem.","Scoping is where the build either becomes useful or starts drifting. The earlier the real constraints surface, the cheaper they are to solve.",{"accentColor":6,"label":19,"title":20,"description":21,"linkText":22,"linkTo":23},"Related service","How we scope custom software projects at SSS.","Scoping is the first thing we do on every engagement — before design, before estimates, before any code.","Custom software service","\u002Fservices\u002Fcustom-software","Sharp Software Solutions builds custom software for South African businesses. Every engagement starts with a scoping session. We don't write a line of code until we understand the actual problem.","Start a conversation","\u002Fcontact","2026-04-01","md","How bad scoping kills custom software projects","and how to avoid it.","Most custom software projects that fail don't fail because of bad code. They fail because the problem wasn't understood properly before the build started.",{},true,"Custom Software Scoping — Why it fails before development starts","\u002Farticles\u002Fbad-scoping","April 2026","9 min read",[39,45,53,63],{"id":40,"navLabel":41,"paragraphs":42},"intro","The pattern",[31,43,44],"The pattern is familiar. A business has a problem, a broken process, a gap in their systems, something manual that should be automated. They find a development team. They describe what they want. The developer builds it. And three months later, the business has a system that technically does what was specified and doesn't solve the actual problem.","This happens because what people describe as the problem is almost never the full problem. It's a symptom, or a proposed solution, or the version of the problem that's easiest to articulate. The real problem, the one that's actually causing the pain, is usually a layer or two deeper.",{"id":46,"navLabel":47,"pillLabel":47,"pillColor":6,"heading":48,"paragraphs":49},"spec-sheet-trap","The spec sheet trap","The request is often not the problem.",[50,51,52],"When a client says \"we need a dispatch system,\" they're describing a category of solution, not a problem. What they actually need depends on questions that haven't been asked yet: How does dispatch currently work? Where does it break down? Who does it, and what do they need to see? What happens when a driver doesn't get the message? What's the relationship between dispatch and billing?","A developer who skips straight to the build is effectively asking: \"How can I build something that fits the description?\" A developer who scopes properly is asking: \"What problem actually needs to be solved?\"","The difference sounds obvious. In practice, it's easy to skip. Scoping takes time. The client wants to move fast. The developer is eager to start building. And everyone is operating on the assumption that the spec sheet is the problem, rather than a first approximation of it.",{"id":54,"navLabel":55,"pillLabel":56,"pillColor":57,"heading":58,"paragraphs":59},"good-scoping","Good scoping","What good scoping looks like","lime","Map the real process before designing the solution.",[60,61,62],"Good scoping means spending serious time on the problem before you design any solution. It means mapping the actual process, not the idealised version, and finding the places it breaks down. It means asking who uses the system and what they actually need it to do. It means surfacing the constraints that the client didn't think to mention because they've lived with them so long they've stopped noticing.","At SSS, our scoping process typically involves a two-to-three hour session where we walk through the problem end to end. We ask about edge cases. We ask about workarounds. We ask about the things that happened that nobody wants to talk about. This is the session where we find out that the drivers use low-end phones with unreliable data, or that the billing process is manual and disconnected, or that there are three people who can authorise a thing but only one who actually does.","Those details change the design. Sometimes they change the problem statement entirely.",{"id":64,"navLabel":65,"pillLabel":66,"pillColor":67,"heading":68,"paragraphs":69},"cost","The cost","The cost of skipping it","blue","The shortcut usually becomes the expensive part.",[70,71,72],"Bad scoping is expensive in ways that aren't always obvious at the start. The most obvious cost is rework, building something, realising it doesn't fit, and rebuilding it. But there's a subtler cost too: the demoralisation of a team that built something carefully and correctly, only to find that it doesn't actually solve the problem.","The other cost is time. A project that gets scoped properly upfront and takes three months is almost always cheaper than a project that skips scoping and takes six, because every week of a build that's heading in the wrong direction is a week that's hard to recover.","The uncomfortable truth is that most bad software projects are predictable. Not because the developers were incompetent, but because the problem was never understood well enough to solve it. Good scoping is the thing that makes the rest of the build work. Skipping it is the most expensive shortcut in software development.",{"description":11},"Custom software scoping is where most projects fail. Not in development — before it starts. Here's what bad scoping looks like in practice and how to avoid it.","Custom Software Scoping — Why it fails before development starts | Sharp Software Solutions",{"text":77,"to":26},"Scope a project","articles\u002Fbad-scoping",[80,85,90],{"label":81,"value":82,"body":83,"icon":84,"accentColor":6},"The mistake","Building the request","The team builds what was described instead of finding the real business problem underneath it.","i-lucide-file-warning",{"label":86,"value":87,"body":88,"icon":89,"accentColor":57},"The risk","Correct build, wrong fit","The system can match the spec and still fail because the scope missed how the business actually works.","i-lucide-triangle-alert",{"label":91,"value":92,"body":93,"icon":94,"accentColor":67},"The fix","Scope the reality","Map the process, constraints, workarounds, edge cases, users, and decisions before designing anything.","i-lucide-search-check",[14,96,97,98],"Custom software","Discovery","Delivery risk","Most custom software projects that fail don't fail because of bad code. They fail because the problem wasn't understood properly before the build started. Here's what that looks like in practice — and how to avoid it.","ZG8tUZylqxbbVt0sFbc217vYYBcItUlDbDkzLjBqPmA",1778227874060]