[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fW99p5zBpPai5eBHsPE8dunj3NRFrM1ONlZUEO6DV6rs":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":29,"hasDownload":30,"fileName":8,"youtubeId":29,"domainCrumb":31},"310","592F5828-A0A3-B740-9B42-F2CD1BCE04DE","8F2761C8-348C-C649-BC16-18822CE2D198","","cluster","necessity-driven-development-start-with-what-must-exist","Necessity-Driven Development: start with what must exist","Stop over-engineering software. Necessity-Driven Development helps you identify must-have features, validate early, and expand only when the core proves its value.","Your new business software project has been in planning for six months. The requirements document is 47 pages long. The development team is asking about edge cases that won't affect a single real user for the next two years. And the launch date keeps moving. Sound familiar?\n\nThis article gives you a practical framework — Necessity-Driven Development — for cutting through that noise, identifying what truly must exist on day one, and building software that delivers real business value before it delivers a feature catalogue.\n\n## Why do software projects grow before they even start?\n\nMost over-engineered projects don't fail because of bad intentions. They fail because of a very human instinct: when given the opportunity to build something, stakeholders add. A sales manager adds a reporting dashboard. Finance asks for automated invoicing. Someone in operations mentions that \"it would be nice\" to have a supplier portal. Each request sounds reasonable in isolation. Together, they transform a focused solution into a platform that takes eighteen months to ship and solves every problem except the one that was urgent.\n\nThis is sometimes called scope creep, but that term misses the root cause. The real problem is the absence of a forcing question: **what must exist for this solution to be useful at all?**\n\n\n\n## What is Necessity-Driven Development?\n\nNecessity-Driven Development (NDD) is a product and software development mindset that treats \"necessary\" as a hard filter, not a preference. It draws from principles found in Lean Startup (build-measure-learn), the MoSCoW prioritisation method (Must have, Should have, Could have, Won't have), and Jobs-to-be-Done theory — but it applies them specifically to the moment of scoping a custom business software project.\n\nThe central question is not \"what do we want?\" but **\"what must exist for the core job to be done?\"**\n\nEverything that doesn't answer that question gets scheduled for later — or dropped entirely.\n\n## How do you identify what \"must exist\" on day one?\n\nThis is where most teams get stuck. \"Must have\" becomes a label everyone applies to their own wish list. Here is a concrete method to make it rigorous:\n\n### Step 1 — Name the one job the software must do\n\nWrite one sentence describing the primary job. Not a list. One sentence. For example:\n\n> *\"The system must allow our service team to register, track, and close customer complaints without touching a spreadsheet.\"*\n\nIf your team can't agree on that sentence in under thirty minutes, that disagreement is your most important finding — and no amount of additional features will fix it.\n\n### Step 2 — Apply the \"without this, the job fails\" test\n\nFor every proposed feature, ask: *if this feature is missing on launch day, does the primary job become impossible?*\n\n- A field to log the complaint? **Yes — must exist.**\n- A status workflow (open → in progress → closed)? **Yes — must exist.**\n- An automated email to the customer when status changes? **Useful, but the job doesn't fail without it. Schedule for phase 2.**\n- A management dashboard with SLA analytics? **Valuable, but not necessary on day one. Phase 3.**\n\nThis test is uncomfortable because it forces stakeholders to say \"not yet\" to things they genuinely want. That discomfort is the point.\n\n### Step 3 — Map dependencies, not features\n\nDraw a simple dependency map. What does the core job require in terms of data, process steps, and integrations? An order management system might need:\n\n1. A product catalogue (must exist — can't create an order without it)\n2. A customer record (must exist — can't assign an order without it)\n3. An order form (must exist — this is the core job)\n4. A connection to the warehouse system (must exist — otherwise orders pile up unprocessed)\n5. Automated PDF invoicing (nice to have — a manually exported PDF works for now)\n6. A customer-facing order portal (future phase)\n\nDependencies belong in phase one. Everything else belongs in a prioritised backlog.\n\n### Step 4 — Set a hard scope boundary before development starts\n\nWrite a one-page scope document that lists:\n- The primary job (one sentence)\n- The must-exist features (the short list)\n- The explicit out-of-scope items for phase one (just as important)\n\nHaving the out-of-scope list signed off by stakeholders prevents the \"but we mentioned this in the kickoff meeting\" conversations that derail sprints later.\n\n\n\n## How do you validate the core before expanding it?\n\nBuilding only what must exist is half the framework. The other half is proving it works before adding more.\n\n**Real-world example:** A logistics company needed a custom shipment tracking system. The initial scope included real-time GPS integration, automated customer notifications, a mobile app for drivers, and a billing module. Using NDD, the team stripped the phase-one scope to: create a shipment record, assign a driver, update status manually, and view open shipments on a simple dashboard. That version went live in six weeks. Dispatchers used it every day. Within three weeks of live use, the team discovered that the most urgent unmet need was not GPS — it was the ability to attach delivery photos to a shipment record. That feature hadn't appeared anywhere in the original 47-page requirements document. It became the first phase-two addition. GPS came in phase three, after the core workflow was stable.\n\nWithout the NDD approach, the team would have spent four months building GPS integration for a workflow that turned out to need something entirely different first.\n\n**The validation loop looks like this:**\n\n1. Launch the must-exist core to real users (even if it feels unfinished)\n2. Observe where users hesitate, work around the system, or ask for help\n3. Interview them: *\"What did you expect the system to do that it didn't do?\"*\n4. Use that data — not the original requirements document — to prioritise phase two\n5. Repeat\n\n## What makes a feature \"must have\" vs. \"should have\"? A working checklist\n\nUse this checklist when evaluating any proposed feature for phase one:\n\n- [ ] **Job-critical:** Without this feature, the primary job literally cannot be completed\n- [ ] **No workaround exists:** There is no manual or temporary substitute that would work for the first 90 days\n- [ ] **Upstream dependency:** Other must-have features cannot function without this one\n- [ ] **Data integrity risk:** Omitting this feature would corrupt or lose data that cannot be reconstructed later\n- [ ] **Regulatory or legal requirement:** The system cannot legally operate without it\n\nIf a feature passes two or more of these checks, it belongs in phase one. If it passes zero or one, schedule it.\n\n## What are the most common mistakes when applying this framework?\n\n**Mistake 1: Calling everything \"must have\" to protect it from cuts.** This is political, not analytical. The \"without this, the job fails\" test in Step 2 is designed to counter this. If a stakeholder can't demonstrate that the job fails without their feature, it doesn't qualify.\n\n**Mistake 2: Skipping real user validation and going straight to phase two.** Two weeks of live usage by real users is worth more than two months of requirements workshops. Don't rush to expand before the core is proven.\n\n**Mistake 3: Treating phase two as a fixed plan rather than a validated backlog.** The whole point of NDD is that phase two should be shaped by what you learn from phase one. If your phase-two plan looks identical after six weeks of live usage, you probably didn't learn anything — or didn't act on what you learned.\n\n**Mistake 4: Building a minimum viable product that isn't actually viable.** There's a difference between lean and broken. The core must genuinely do the primary job well. Cutting corners on data reliability, basic usability, or critical integrations in the name of \"keeping it simple\" produces something users reject — and that sets the entire project back further than a longer phase one would have.\n\n## How does this apply to existing systems, not just new builds?\n\nNDD is not only a greenfield strategy. When modernising or extending an existing system — say, a FileMaker application that has grown organically over ten years — the same forcing question applies: *what must exist in the new version for the business to keep running?*\n\nThis matters because legacy modernisation projects often fail for the same reason as over-scoped new builds: the team tries to replicate every existing feature before going live, including features that nobody uses. Mapping [modern software development](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fmodern-software-development) practices onto an existing system starts with identifying which parts of the current system are genuinely business-critical and which are historical accidents that accumulated over time.\n\nA useful exercise: pull the usage logs from the existing system. In almost every legacy application audit, 20–30% of the screens or modules account for 80–90% of daily usage. Those are your must-exist features. The rest can be rebuilt gradually, or not at all.\n\n## FAQ\n\n**Q: Doesn't this approach risk launching something that feels unfinished to users?**\nA: Yes — and that's a feature, not a bug. The goal is to learn from real usage as early as possible. The risk of launching something lean is far smaller than the risk of spending a year building something users don't actually need. Manage expectations clearly at launch: tell users what is coming and give them a channel to report what's missing.\n\n**Q: How do I handle stakeholders who insist their feature is \"must have\"?**\nA: Use the checklist above in a group session. Walk through each criterion together. When a stakeholder cannot demonstrate that the primary job fails without their feature, the checklist makes the exclusion a logical outcome rather than a political decision.\n\n**Q: What's a realistic phase-one timeline using NDD?**\nA: For most custom business software projects, a well-scoped phase one should be deliverable in six to twelve weeks. If the estimate is longer, the scope is probably not narrow enough. Push the \"without this, the job fails\" test harder.\n\n**Q: Does NDD work for complex enterprise systems with many interdependencies?**\nA: Yes, but it requires decomposing the enterprise problem into independently deliverable jobs first. An ERP replacement, for example, should never be treated as a single phase-one scope. Start with the one process that is most broken or most valuable — say, purchase order management — apply NDD to that slice, and expand from there.\n\n**Q: How do we make sure phase two actually happens and doesn't get forgotten?**\nA: Maintain a visible, prioritised backlog from day one. After each phase-one validation cycle, run a thirty-minute backlog review with stakeholders. The backlog is a living document, not an archive.\n\n---\n\nIf your team is facing a build that keeps growing before it ships — or a legacy system where nobody is sure what still matters — Loggix works with business owners and IT managers to map out exactly what must exist, build it cleanly, and expand it on evidence. Whether that means a tailored FileMaker solution, a custom web application, or connecting existing systems through smart API integrations, the starting point is always the same: one honest conversation about what the business actually needs on day one.","\u003Cp>Your new business software project has been in planning for six months. The requirements document is 47 pages long. The development team is asking about edge cases that won't affect a single real user for the next two years. And the launch date keeps moving. Sound familiar?\u003C\u002Fp>\n\u003Cp>This article gives you a practical framework — Necessity-Driven Development — for cutting through that noise, identifying what truly must exist on day one, and building software that delivers real business value before it delivers a feature catalogue.\u003C\u002Fp>\n\u003Ch2>Why do software projects grow before they even start?\u003C\u002Fh2>\n\u003Cp>Most over-engineered projects don't fail because of bad intentions. They fail because of a very human instinct: when given the opportunity to build something, stakeholders add. A sales manager adds a reporting dashboard. Finance asks for automated invoicing. Someone in operations mentions that "it would be nice" to have a supplier portal. Each request sounds reasonable in isolation. Together, they transform a focused solution into a platform that takes eighteen months to ship and solves every problem except the one that was urgent.\u003C\u002Fp>\n\u003Cp>This is sometimes called scope creep, but that term misses the root cause. The real problem is the absence of a forcing question: \u003Cstrong>what must exist for this solution to be useful at all?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>What is Necessity-Driven Development?\u003C\u002Fh2>\n\u003Cp>Necessity-Driven Development (NDD) is a product and software development mindset that treats "necessary" as a hard filter, not a preference. It draws from principles found in Lean Startup (build-measure-learn), the MoSCoW prioritisation method (Must have, Should have, Could have, Won't have), and Jobs-to-be-Done theory — but it applies them specifically to the moment of scoping a custom business software project.\u003C\u002Fp>\n\u003Cp>The central question is not "what do we want?" but \u003Cstrong>"what must exist for the core job to be done?"\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Everything that doesn't answer that question gets scheduled for later — or dropped entirely.\u003C\u002Fp>\n\u003Ch2>How do you identify what "must exist" on day one?\u003C\u002Fh2>\n\u003Cp>This is where most teams get stuck. "Must have" becomes a label everyone applies to their own wish list. Here is a concrete method to make it rigorous:\u003C\u002Fp>\n\u003Ch3>Step 1 — Name the one job the software must do\u003C\u002Fh3>\n\u003Cp>Write one sentence describing the primary job. Not a list. One sentence. For example:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>\u003Cem>"The system must allow our service team to register, track, and close customer complaints without touching a spreadsheet."\u003C\u002Fem>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>If your team can't agree on that sentence in under thirty minutes, that disagreement is your most important finding — and no amount of additional features will fix it.\u003C\u002Fp>\n\u003Ch3>Step 2 — Apply the "without this, the job fails" test\u003C\u002Fh3>\n\u003Cp>For every proposed feature, ask: \u003Cem>if this feature is missing on launch day, does the primary job become impossible?\u003C\u002Fem>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A field to log the complaint? \u003Cstrong>Yes — must exist.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>A status workflow (open → in progress → closed)? \u003Cstrong>Yes — must exist.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>An automated email to the customer when status changes? \u003Cstrong>Useful, but the job doesn't fail without it. Schedule for phase 2.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>A management dashboard with SLA analytics? \u003Cstrong>Valuable, but not necessary on day one. Phase 3.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This test is uncomfortable because it forces stakeholders to say "not yet" to things they genuinely want. That discomfort is the point.\u003C\u002Fp>\n\u003Ch3>Step 3 — Map dependencies, not features\u003C\u002Fh3>\n\u003Cp>Draw a simple dependency map. What does the core job require in terms of data, process steps, and integrations? An order management system might need:\u003C\u002Fp>\n\u003Col>\n\u003Cli>A product catalogue (must exist — can't create an order without it)\u003C\u002Fli>\n\u003Cli>A customer record (must exist — can't assign an order without it)\u003C\u002Fli>\n\u003Cli>An order form (must exist — this is the core job)\u003C\u002Fli>\n\u003Cli>A connection to the warehouse system (must exist — otherwise orders pile up unprocessed)\u003C\u002Fli>\n\u003Cli>Automated PDF invoicing (nice to have — a manually exported PDF works for now)\u003C\u002Fli>\n\u003Cli>A customer-facing order portal (future phase)\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Dependencies belong in phase one. Everything else belongs in a prioritised backlog.\u003C\u002Fp>\n\u003Ch3>Step 4 — Set a hard scope boundary before development starts\u003C\u002Fh3>\n\u003Cp>Write a one-page scope document that lists:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>The primary job (one sentence)\u003C\u002Fli>\n\u003Cli>The must-exist features (the short list)\u003C\u002Fli>\n\u003Cli>The explicit out-of-scope items for phase one (just as important)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Having the out-of-scope list signed off by stakeholders prevents the "but we mentioned this in the kickoff meeting" conversations that derail sprints later.\u003C\u002Fp>\n\u003Ch2>How do you validate the core before expanding it?\u003C\u002Fh2>\n\u003Cp>Building only what must exist is half the framework. The other half is proving it works before adding more.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Real-world example:\u003C\u002Fstrong> A logistics company needed a custom shipment tracking system. The initial scope included real-time GPS integration, automated customer notifications, a mobile app for drivers, and a billing module. Using NDD, the team stripped the phase-one scope to: create a shipment record, assign a driver, update status manually, and view open shipments on a simple dashboard. That version went live in six weeks. Dispatchers used it every day. Within three weeks of live use, the team discovered that the most urgent unmet need was not GPS — it was the ability to attach delivery photos to a shipment record. That feature hadn't appeared anywhere in the original 47-page requirements document. It became the first phase-two addition. GPS came in phase three, after the core workflow was stable.\u003C\u002Fp>\n\u003Cp>Without the NDD approach, the team would have spent four months building GPS integration for a workflow that turned out to need something entirely different first.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>The validation loop looks like this:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Col>\n\u003Cli>Launch the must-exist core to real users (even if it feels unfinished)\u003C\u002Fli>\n\u003Cli>Observe where users hesitate, work around the system, or ask for help\u003C\u002Fli>\n\u003Cli>Interview them: \u003Cem>"What did you expect the system to do that it didn't do?"\u003C\u002Fem>\u003C\u002Fli>\n\u003Cli>Use that data — not the original requirements document — to prioritise phase two\u003C\u002Fli>\n\u003Cli>Repeat\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>What makes a feature "must have" vs. "should have"? A working checklist\u003C\u002Fh2>\n\u003Cp>Use this checklist when evaluating any proposed feature for phase one:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Job-critical:\u003C\u002Fstrong> Without this feature, the primary job literally cannot be completed\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>No workaround exists:\u003C\u002Fstrong> There is no manual or temporary substitute that would work for the first 90 days\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Upstream dependency:\u003C\u002Fstrong> Other must-have features cannot function without this one\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Data integrity risk:\u003C\u002Fstrong> Omitting this feature would corrupt or lose data that cannot be reconstructed later\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> \u003Cstrong>Regulatory or legal requirement:\u003C\u002Fstrong> The system cannot legally operate without it\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>If a feature passes two or more of these checks, it belongs in phase one. If it passes zero or one, schedule it.\u003C\u002Fp>\n\u003Ch2>What are the most common mistakes when applying this framework?\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Mistake 1: Calling everything "must have" to protect it from cuts.\u003C\u002Fstrong> This is political, not analytical. The "without this, the job fails" test in Step 2 is designed to counter this. If a stakeholder can't demonstrate that the job fails without their feature, it doesn't qualify.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Mistake 2: Skipping real user validation and going straight to phase two.\u003C\u002Fstrong> Two weeks of live usage by real users is worth more than two months of requirements workshops. Don't rush to expand before the core is proven.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Mistake 3: Treating phase two as a fixed plan rather than a validated backlog.\u003C\u002Fstrong> The whole point of NDD is that phase two should be shaped by what you learn from phase one. If your phase-two plan looks identical after six weeks of live usage, you probably didn't learn anything — or didn't act on what you learned.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Mistake 4: Building a minimum viable product that isn't actually viable.\u003C\u002Fstrong> There's a difference between lean and broken. The core must genuinely do the primary job well. Cutting corners on data reliability, basic usability, or critical integrations in the name of "keeping it simple" produces something users reject — and that sets the entire project back further than a longer phase one would have.\u003C\u002Fp>\n\u003Ch2>How does this apply to existing systems, not just new builds?\u003C\u002Fh2>\n\u003Cp>NDD is not only a greenfield strategy. When modernising or extending an existing system — say, a FileMaker application that has grown organically over ten years — the same forcing question applies: \u003Cem>what must exist in the new version for the business to keep running?\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>This matters because legacy modernisation projects often fail for the same reason as over-scoped new builds: the team tries to replicate every existing feature before going live, including features that nobody uses. Mapping \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fmodern-software-development\">modern software development\u003C\u002Fa> practices onto an existing system starts with identifying which parts of the current system are genuinely business-critical and which are historical accidents that accumulated over time.\u003C\u002Fp>\n\u003Cp>A useful exercise: pull the usage logs from the existing system. In almost every legacy application audit, 20–30% of the screens or modules account for 80–90% of daily usage. Those are your must-exist features. The rest can be rebuilt gradually, or not at all.\u003C\u002Fp>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Q: Doesn't this approach risk launching something that feels unfinished to users?\u003C\u002Fstrong>\nA: Yes — and that's a feature, not a bug. The goal is to learn from real usage as early as possible. The risk of launching something lean is far smaller than the risk of spending a year building something users don't actually need. Manage expectations clearly at launch: tell users what is coming and give them a channel to report what's missing.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Q: How do I handle stakeholders who insist their feature is "must have"?\u003C\u002Fstrong>\nA: Use the checklist above in a group session. Walk through each criterion together. When a stakeholder cannot demonstrate that the primary job fails without their feature, the checklist makes the exclusion a logical outcome rather than a political decision.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Q: What's a realistic phase-one timeline using NDD?\u003C\u002Fstrong>\nA: For most custom business software projects, a well-scoped phase one should be deliverable in six to twelve weeks. If the estimate is longer, the scope is probably not narrow enough. Push the "without this, the job fails" test harder.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Q: Does NDD work for complex enterprise systems with many interdependencies?\u003C\u002Fstrong>\nA: Yes, but it requires decomposing the enterprise problem into independently deliverable jobs first. An ERP replacement, for example, should never be treated as a single phase-one scope. Start with the one process that is most broken or most valuable — say, purchase order management — apply NDD to that slice, and expand from there.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Q: How do we make sure phase two actually happens and doesn't get forgotten?\u003C\u002Fstrong>\nA: Maintain a visible, prioritised backlog from day one. After each phase-one validation cycle, run a thirty-minute backlog review with stakeholders. The backlog is a living document, not an archive.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>If your team is facing a build that keeps growing before it ships — or a legacy system where nobody is sure what still matters — Loggix works with business owners and IT managers to map out exactly what must exist, build it cleanly, and expand it on evidence. Whether that means a tailored FileMaker solution, a custom web application, or connecting existing systems through smart API integrations, the starting point is always the same: one honest conversation about what the business actually needs on day one.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901673000,[19,20,21,22,23,24,25,26,27,28],"software development","custom business software","necessity-driven development","scope management","MVP","prioritization","FileMaker","ERP","lean development","product strategy",null,false,{"title":32,"slug":33},"Modern Software Development","modern-software-development"]