[{"data":1,"prerenderedAt":290},["ShallowReactive",2],{"articles-list":3},[4,102,191],{"id":5,"title":6,"accentColor":7,"body":8,"category":15,"coreIdea":16,"crossLink":19,"ctaBody":25,"ctaLinkText":26,"ctaLinkTo":27,"datePublished":28,"description":12,"extension":29,"headline":30,"headlineAccent":31,"heroParagraph":32,"meta":33,"navigation":34,"ogDescription":32,"ogTitle":35,"path":36,"publishedAt":37,"readTime":38,"sections":39,"seo":74,"seoDescription":75,"seoTitle":76,"sidebarLink":77,"stem":79,"summaryCards":80,"tags":96,"teaser":100,"__hash__":101},"articles\u002Farticles\u002Fbad-scoping.md","Bad Scoping","teal",{"type":9,"value":10,"toc":11},"minimark",[],{"title":12,"searchDepth":13,"depth":13,"links":14},"",2,[],"Scoping",{"heading":17,"body":18},"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":7,"label":20,"title":21,"description":22,"linkText":23,"linkTo":24},"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",[40,46,54,64],{"id":41,"navLabel":42,"paragraphs":43},"intro","The pattern",[32,44,45],"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":47,"navLabel":48,"pillLabel":48,"pillColor":7,"heading":49,"paragraphs":50},"spec-sheet-trap","The spec sheet trap","The request is often not the problem.",[51,52,53],"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":55,"navLabel":56,"pillLabel":57,"pillColor":58,"heading":59,"paragraphs":60},"good-scoping","Good scoping","What good scoping looks like","lime","Map the real process before designing the solution.",[61,62,63],"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":65,"navLabel":66,"pillLabel":67,"pillColor":68,"heading":69,"paragraphs":70},"cost","The cost","The cost of skipping it","blue","The shortcut usually becomes the expensive part.",[71,72,73],"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":12},"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":78,"to":27},"Scope a project","articles\u002Fbad-scoping",[81,86,91],{"label":82,"value":83,"body":84,"icon":85,"accentColor":7},"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":87,"value":88,"body":89,"icon":90,"accentColor":58},"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":92,"value":93,"body":94,"icon":95,"accentColor":68},"The fix","Scope the reality","Map the process, constraints, workarounds, edge cases, users, and decisions before designing anything.","i-lucide-search-check",[15,97,98,99],"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",{"id":103,"title":104,"accentColor":68,"body":105,"category":109,"coreIdea":110,"crossLink":113,"ctaBody":119,"ctaLinkText":120,"ctaLinkTo":27,"datePublished":121,"description":12,"extension":29,"headline":122,"headlineAccent":123,"heroParagraph":124,"meta":125,"navigation":34,"ogDescription":126,"ogTitle":127,"path":128,"publishedAt":129,"readTime":130,"sections":131,"seo":163,"seoDescription":164,"seoTitle":165,"sidebarLink":166,"stem":169,"summaryCards":170,"tags":186,"teaser":189,"__hash__":190},"articles\u002Farticles\u002Freal-time-dashboard-problem.md","Real Time Dashboard Problem",{"type":9,"value":106,"toc":107},[],{"title":12,"searchDepth":13,"depth":13,"links":108},[],"Data platforms",{"heading":111,"body":112},"A dashboard can feel fast and still be too stale for the decision.","The question is not whether the dashboard refreshes often. The question is what happens when someone acts on data that is already old.",{"accentColor":68,"label":114,"title":115,"description":116,"linkText":117,"linkTo":118},"Real-world example","A genuinely real-time data platform — built in production.","Live agricultural commodity pricing, WebSocket feeds, and charting that holds up under load for a South African market data provider.","Read case study","\u002Finsights\u002Fcase-studies\u002Fsa-market-data-charting-platform","SSS builds data platforms and dashboards for South African businesses, including genuinely real-time systems where the use case demands it. We scope the data requirements before we design the architecture.","Talk about your data problem","2026-03-01","The hidden problems with real-time dashboards","and why most of them aren't actually real-time.","'Real-time' is one of the most overloaded terms in software. The gap between what it means in a marketing context and what it means in a technical context causes real problems for businesses that depend on live data to make decisions.",{},"'Real-time' is one of the most overloaded terms in software. The gap between the claim and the technical reality causes real problems for businesses that depend on live data.","Real Time Dashboard Performance — What 'live' actually means","\u002Farticles\u002Freal-time-dashboard-problem","March 2026","8 min read",[132,137,146,154],{"id":41,"navLabel":133,"paragraphs":134},"The claim",[135,136],"\"Real-time\" is one of the most overloaded terms in software. The gap between what it means in a marketing context and what it means in a technical context causes real problems for businesses that depend on live data to make decisions.","\"Real-time\" often means \"faster than the thing you had before\", which isn't the same as actually live. When a vendor says their dashboard is \"real-time,\" they might mean the data refreshes every 30 seconds. Or every minute. Or that it updates live, but only after a human uploads a file.",{"id":138,"navLabel":139,"pillLabel":140,"pillColor":68,"heading":141,"paragraphs":142},"meaning","What real-time means","What real-time actually means","Real-time is event driven, not just frequent refreshes.",[143,144,145],"A genuinely real-time system is one where data changes on the client are driven by events on the server, not by the client periodically asking \"has anything changed?\" The technical implementation is usually WebSockets or Server-Sent Events: a persistent connection where the server pushes updates as they happen, rather than waiting to be asked.","Polling, where the client asks the server for new data every N seconds, is not real-time. It's close to real-time, depending on the polling interval, but there's always a delay between when something happens and when the dashboard shows it. For commodity trading, or live dispatch management, or any system where decisions need to be made on current information, that gap matters.","The problem is that polling looks like real-time to most users, right up until it doesn't. When the polling interval is 30 seconds and you make a decision based on data that's 28 seconds old, the consequences aren't always obvious until something goes wrong.",{"id":147,"navLabel":148,"pillLabel":149,"pillColor":7,"heading":150,"paragraphs":151},"why","Why most are not live","Why most dashboards aren't actually live","Polling is easier. Real-time takes more engineering.",[152,153],"Building a genuinely real-time system is harder than building one that polls. WebSocket connections need to be managed. They disconnect, they need to handle reconnection, they need to maintain state across connection drops. The backend needs a pub\u002Fsub architecture to broadcast updates to multiple clients efficiently. Under load, the connection management becomes a significant engineering concern.","Polling is simpler. It works. For a lot of use cases, it's good enough. The problem is when businesses are sold on \"real-time\" dashboards that are actually polling every minute, and only discover the gap when they're making decisions that depend on the data being current.",{"id":155,"navLabel":156,"pillLabel":157,"pillColor":58,"heading":158,"paragraphs":159},"matters","When it matters","When it actually matters","The architecture should match the cost of stale data.",[160,161,162],"The honest answer is that real-time isn't always necessary. For most reporting use cases, weekly sales figures, monthly P&L, end-of-day operations summaries, a dashboard that refreshes every few minutes is perfectly adequate. The data doesn't need to be live because the decisions aren't live.","But for commodity pricing, live dispatch visibility, active trading, or any system where a decision made on stale data has a real cost, genuine real-time matters. The question to ask isn't \"is this dashboard fast?\" It's \"what's the cost of making a decision on data that's 30 seconds old?\"","If the answer is \"nothing significant,\" polling is fine. If the answer is \"we could lose a trade, miss a dispatch, or make a wrong call\", then the architecture needs to be built for the actual requirement, not the easier implementation.",{"description":12},"Real time dashboard performance depends on architecture, not marketing claims. Most dashboards sold as 'real-time' aren't. Here's how to tell the difference and why it matters.","Real Time Dashboard Performance — What 'live' actually means | Sharp Software Solutions",{"text":167,"to":168},"View data platforms","\u002Fservices\u002Fdata-platforms","articles\u002Freal-time-dashboard-problem",[171,176,181],{"label":172,"value":173,"body":174,"icon":175,"accentColor":68},"Polling","Close, not live","The dashboard asks for updates every few seconds or minutes. There is always a delay.","i-lucide-refresh-cw",{"label":177,"value":178,"body":179,"icon":180,"accentColor":7},"WebSockets","Event driven","The server pushes updates to the client as the data changes.","i-lucide-radio-tower",{"label":182,"value":183,"body":184,"icon":185,"accentColor":58},"The question","What does stale data cost?","If 30 seconds changes the decision, the architecture needs to be truly live.","i-lucide-timer",[187,188,177,109],"Real-time","Dashboards","'Real-time' is one of the most overloaded terms in software. The gap between the marketing claim and the technical reality causes real problems for businesses that depend on live data to make decisions.","6BSBfg9rOp5wN177Brh5kQJ554xlosrz7x1HSQUMuXA",{"id":192,"title":193,"accentColor":58,"body":194,"category":198,"coreIdea":199,"crossLink":202,"ctaBody":207,"ctaLinkText":208,"ctaLinkTo":27,"datePublished":209,"description":12,"extension":29,"headline":210,"headlineAccent":211,"heroParagraph":212,"meta":213,"navigation":34,"ogDescription":214,"ogTitle":215,"path":216,"publishedAt":217,"readTime":218,"sections":219,"seo":264,"seoDescription":265,"seoTitle":266,"sidebarLink":267,"stem":269,"summaryCards":270,"tags":285,"teaser":288,"__hash__":289},"articles\u002Farticles\u002Fspreadsheets-costing-sa-business.md","Spreadsheets Costing Sa Business",{"type":9,"value":195,"toc":196},[],{"title":12,"searchDepth":13,"depth":13,"links":197},[],"Operations",{"heading":200,"body":201},"The spreadsheet is not the problem until it becomes the operation.","Once the workaround becomes business-critical, the cost is no longer the tool. The cost is the manual work, risk, bottlenecks, and missing visibility around it.",{"accentColor":7,"label":20,"title":203,"description":204,"linkText":205,"linkTo":206},"Ready to replace the spreadsheet? Here is what we build instead.","Custom fleet and operations management systems for South African businesses that have outgrown manual coordination.","Fleet management service","\u002Fservices\u002Flogistics-operations","SSS builds systems that replace spreadsheet operations for South African businesses. We scope the replacement properly before we build anything, so you end up with a system that fits, not a generic solution that creates new problems.","Talk about your spreadsheet problem","2026-02-01","When spreadsheets stop being enough","and what it's costing you to ignore it.","The spreadsheet is South Africa's most popular business system. It's flexible, familiar, and crucially free. Most businesses start on spreadsheets because spreadsheets work. The problem is what happens after they stop being enough.",{},"The spreadsheet is South Africa's most popular business system. The problem is what happens after it stops being enough — and most businesses don't notice until the damage is done.","Replace Spreadsheets With Custom Software — When to make the switch","\u002Farticles\u002Fspreadsheets-costing-sa-business","February 2026","11 min read",[220,225,249,255],{"id":41,"navLabel":221,"paragraphs":222},"The hidden shift",[212,223,224],"And most businesses don't notice when that moment arrives. The transition from \"spreadsheet that works\" to \"spreadsheet that's holding us back\" is gradual. Formulas get more complex. The file gets shared with more people. Version conflicts start happening. Someone overwrites someone else's work. The person who built the original formula leaves, and nobody understands how it works anymore.","By the time the problem is obvious, the spreadsheet has become so embedded in the operation that replacing it feels more dangerous than living with the pain.",{"id":226,"navLabel":227,"pillLabel":228,"pillColor":58,"heading":229,"paragraphs":230,"items":236},"signs","The signs","The signs it's time","The spreadsheet starts managing the business.",[231,232,233,234,235],"There are a few patterns we see repeatedly in South African businesses that have outgrown their spreadsheets:","\u003Cstrong>The reconciliation ritual.\u003C\u002Fstrong> At the end of every day, week, or month, someone manually reconciles two or more spreadsheets to produce a single version of the truth. This process takes hours and is prone to errors that are discovered too late to fix cleanly.","\u003Cstrong>The single-person bottleneck.\u003C\u002Fstrong> There's one person who understands the spreadsheet well enough to maintain it. When they're on leave, the process either stops or produces unreliable results. When they leave the business, a critical piece of institutional knowledge walks out the door.","\u003Cstrong>The multi-file problem.\u003C\u002Fstrong> Data about the same thing lives in multiple files. Keeping them consistent requires manual intervention. When they diverge, nobody is sure which one is correct.","\u003Cstrong>The growth ceiling.\u003C\u002Fstrong> The business is turning away opportunities or limiting its own growth because the spreadsheet can't handle more volume. Hiring more people to manage the spreadsheet more isn't solving the constraint. It's scaling the workaround.",[237,240,243,246],{"title":238,"body":239},"The reconciliation ritual","Someone manually reconciles two or more spreadsheets to produce one version of the truth.",{"title":241,"body":242},"The single-person bottleneck","One person understands the spreadsheet well enough to keep the process running.",{"title":244,"body":245},"The multi-file problem","Data about the same thing lives in multiple files and drifts out of sync.",{"title":247,"body":248},"The growth ceiling","The business is limiting growth because the spreadsheet cannot handle more volume.",{"id":65,"navLabel":250,"pillLabel":250,"pillColor":7,"heading":251,"paragraphs":252},"The actual cost","The cost is not the spreadsheet. It is the work around it.",[253,254],"The cost of an over-stretched spreadsheet operation is rarely calculated explicitly. It shows up as staff time, the hours spent on manual reconciliation, on double-checking data, on answering the question \"which version is current?\" It shows up as errors, the wrong figure in a report, the invoice that didn't match the job sheet, the driver who got the wrong address. And it shows up as opportunity cost, the work that didn't get done because the operations team was managing the system instead of running the business.","In our experience, South African businesses running critical operations on spreadsheets are typically spending 15–25% of their operational capacity managing the system rather than using it. That's not a wild estimate. It's what we find when we map the actual process.",{"id":256,"navLabel":257,"pillLabel":258,"pillColor":68,"heading":259,"paragraphs":260},"transition","The transition","What the transition looks like","Replace the operation carefully, not recklessly.",[261,262,263],"The good news is that replacing a spreadsheet-based operation isn't as disruptive as most businesses fear. The key is scoping the replacement properly, not building a generic system, but building something that addresses the specific constraints that are causing the pain.","The first step is always mapping what the spreadsheet actually does. Not the official version, the real one, including the manual steps, the workarounds, and the things only one person knows how to do. That process usually surfaces the exact constraints that need to be solved, which makes the build scope much clearer and the estimate much more accurate.","The transition period, running the old system and the new system in parallel, typically takes two to four weeks. After that, the spreadsheet can be retired. The businesses that handle this well are the ones that treat it as a process change, not just a technology change.",{"description":12},"When to replace spreadsheets with custom software: the signs, the cost of waiting, and what a purpose-built system actually looks like for South African businesses.","Replace Spreadsheets With Custom Software — When to make the switch | Sharp Software Solutions",{"text":268,"to":206},"View operations systems","articles\u002Fspreadsheets-costing-sa-business",[271,276,280],{"label":272,"value":273,"body":274,"icon":275,"accentColor":58},"The signal","Version chaos","Multiple files, manual reconciliation, and nobody fully trusts the current number.","i-lucide-files",{"label":87,"value":277,"body":278,"icon":279,"accentColor":7},"Single-person knowledge","One person understands the spreadsheet. When they leave, the process leaves with them.","i-lucide-user-lock",{"label":281,"value":282,"body":283,"icon":284,"accentColor":68},"The move","Replace the process","The goal is not a prettier spreadsheet. It is a system that fits the real operation.","i-lucide-table-properties",[198,286,287,97],"Spreadsheets","Process risk","The spreadsheet is South Africa's most popular business system. It's flexible, familiar, and free. The problem is what happens after it stops being enough — and most businesses don't notice until the damage is done.","KejTe3i3pWGBHbXytzVfwZcO4FNPc5jqgv2alhBRsps",1778227874060]