Verdict

“A decoupled, lazy‑evaluation property graph that batches CAD API calls and resolves hidden dependencies provides the real, durable differentiation.”

The market already offers several naval architecture suites (e.g., Maxsurf, Orca, DelftShip) that perform ship stability and hydrostatic calculations, often requiring manual input of geometric parameters rather than importing a user‑generated 3D CAD model via API. Your idea’s differentiation lies in providing a lightweight, generic desktop application that leverages any CAD program’s API to import a model and then evaluates only the user‑requested properties, automatically resolving hidden dependencies and batching API calls to minimize cost. This property‑centric, lazy‑evaluation architecture is not commonly exposed as a reusable engine, giving you a potential niche. However, the core functionality (hydrostatic analysis) is commoditized, and durability depends on how robustly you can implement the dependency graph, caching, and API‑call batching without introducing hidden coupling. If the data model and evaluation engine are well‑encapsulated and extensible, the differentiation can be defensible; otherwise, it may be eroded by existing tools that already offer similar capabilities through plug‑ins or scripting.

“The technical challenge is solvable, but the business model hinges on pricing per high-value simulation or enterprise subscriptions.”

The idea targets a niche but high-value market (naval architecture, marine engineering) with clear pain points: expensive API calls, dependency management, and caching. The proposed solution addresses a real need—optimizing computational cost by lazily evaluating only requested properties while respecting dependencies. The current implementation, while functional, has technical debt (mutability, unenforceable assumptions, tight coupling) but the core value proposition is strong. Monetization potential is high: per-simulation pricing (e.g., $50–$500/simulation for commercial shipyards) or subscription tiers (e.g., $2K–$10K/month for enterprises) with margins >80% due to low marginal cost. Channels include direct sales to engineering firms, integrations with CAD vendors (revenue share), and partnerships with maritime classification societies. Unit economics are favorable if API call costs are controlled via batching/caching.

“The key to improving the implementation lies in designing a more robust and maintainable data structure that effectively handles property dependencies and decouples evaluation logic from business logic.”

The proposed desktop application's core functionality revolves around evaluating 160 properties related to ship stability and hydrostatics simulations. The current implementation uses a hierarchical data structure to store these properties and their respective evaluation methods. However, this approach has several drawbacks, including unenforceable assumptions, mutable evaluation data, and a lack of protection against circular dependencies or forgotten solve method assignments. A solo or 2-person team can build a functional v1 in 4-12 weeks, but it will likely require significant refactoring to address the existing code's maintainability issues. The main challenge lies in designing a robust data structure that decouples property evaluation from business logic while handling complex dependencies between properties. To improve the implementation, the team could explore alternative approaches, such as using a graph data structure to model property dependencies or implementing a more functional programming style to reduce mutability. Nevertheless, the core idea is feasible, and with careful planning, the team can deliver a working v1 within the given timeframe.

“The current implementation's complexity and lack of scalability due to tight coupling and mutability will lead to maintenance nightmares and likely cause the project to fail within the specified timeframe due to technical, not market, factors.”

The implementation's tight coupling, mutability, and reliance on unenforceable assumptions at the data structure level introduce significant technical debt. The current approach does not scale well with 160 properties, each having unique dependencies and API call efficiencies. As the system grows, maintaining the solve method assignments, ensuring data integrity, and avoiding circular dependencies will become impractically complex. Furthermore, the evaluation data's mutability and the lack of clear ownership (anything can modify properties outside of Evaluator) increase the risk of bugs and inconsistencies. The API call optimization, while intended to reduce costs, complicates the property-value relationship, making it harder to debug and predict behavior.

“Naval architects will pay premium prices for a tool that seamlessly integrates with their existing CAD tools and automates compliance-critical hydrostatic calculations without requiring them to abandon their workflow.”

The core idea — a desktop app automating marine hydrostatics and stability simulations via CAD APIs — targets a highly specialized, high-value niche: naval architects, ship designers, and offshore engineering firms. These users pay premium fees for accurate, compliant simulations (e.g., IMO, ABS, DNV standards), and manual calculation is time-intensive and error-prone. The 160 measurable properties represent real, documented requirements in industry standards, meaning demand is not hypothetical. The technical challenge (dependency resolution, caching, API optimization) is non-trivial but solvable with proper architecture. However, the current implementation is brittle and tightly coupled, risking maintenance collapse as the property set grows. The real market size is small but lucrative: globally, there are ~5,000–10,000 professional users in ship design firms, each willing to pay $5k–$20k/year for a reliable, standards-compliant tool. Competitors like NAPA or Maxsurf exist but are monolithic, expensive, and lack flexibility for custom CAD integration. Your app’s unique value is API-native interoperability with existing CAD workflows (e.g., Rhino, SolidWorks), which competitors don’t offer. The flaw isn’t market demand — it’s execution risk. If you refactor the architecture using a dependency graph (e.g., topological sorting) with immutable state and pure evaluation functions, this becomes a defensible product. But as-is, the codebase is a liability. The audience is real, the budget is there, and the pain is acute — but only if you solve the software design problem.