Project Overview
Business Plan Drafted
8 spec nodes · 43 business artifacts · needs validation
Financial Model
36-month forecast · three horizons aligned · assumptions visible
Top Business Decision
Approve revenue, runway, and Horizon 2 pilot assumptions
Critical Business Risk
Technical choices may raise burn or support burden
Welcome to the OpenIOTAI Business Case Study
This interactive prototype represents the complete validated business case and viability study for the OpenIOTAI concept — a low-cost, self-hosted IoT operations service designed to give operators early awareness and peace of mind.
Use this dashboard to audit the business plan completeness, test cash-flow forecasts using the simulator, inspect key requirements, and review compliance and strategic horizons.
Explore the Business Study
Review the core business strategy, customer problem validation, target segment SWOT, and value propositions.
Audit financial assumptions, tweak growth rates, CAC, churn, and run interactive sensitivity simulations.
Inspect the Risk Impact Map and audit the Verdict Evidence Chain to find weak assumptions and validation gaps.
Check the readiness matrix and checklists required for pre-seed funding or grant applications.
Audit the product's functional scope, MVP requirements list, and deferred roadmap items.
Explore the interactive relationship map linking all strategic, customer, and component nodes.
Understanding Audit Verdicts
Business Case Database Statistics
OpenIOTAI
OpenIOTAI helps technical small-site operators and Internet of Things integrators see device problems earlier, understand what happened, and keep operational data under their own control. The service is planned as a low-cost, self-hosted operations concept whose first job is to prove clear monitoring value before scaling into pilots or commercialization.
Executive Summary
Analysis Foundation
Customer Problem and Value Proposition
Problem From Customer View
Uncertainty, missed events, unclear history, and unclear failure ownership.
Value Proposition
- Value promises are prepared from the business model.
Customer Segments
Customer & Adoption View
Best First Customer Recommendation
Recommendation is prepared from customer segment assumptions.
Ability to Pay vs Willingness to Pay
Switching Friction
Buyer, User, and Budget Owner
| Segment | Type | Buyer | User | Budget Owner | Horizon |
|---|
Hover a row to inspect who buys, who uses, who controls the budget, and what the row means for adoption.
Customer Alternatives
10% vs 10X Value
Customer SWOT
Money View
Concrete euro assumptions for customer value, pricing, customer-level cost, founder salary, and owner/investor return. These are planning assumptions unless marked as source-supported.
Willingness to Pay
| Segment | Setup Fee | Monthly Fee | Confidence |
|---|
Competitor and Alternative Prices
| Provider | Public Price | Euro Monthly Anchor | Notes |
|---|
Customer-Level Cost Breakdown
| Item | One-Off | Monthly | Notes |
|---|
Gross Margin
| Scenario | Price | Cost | Margin |
|---|
Founder Compensation
| Phase | Gross Salary | Side Costs | Total Monthly Cost | Start Condition |
|---|
Owner / Investor Return
| Scenario | Initial Investment | Founder Salary Paid | Retained Cash | Payback | Return on Investment |
|---|
Money Validation Questions
Industry Application Opportunities
Potential first markets and the practical use cases customers would buy the service for.
Strategic Business Tests
Optimized Business Plan
Optimized Cash-Flow Forecast
SourceRevenue, Costs, and Cash
Assumptions
| Month | New Customers | Active Customers | Setup EUR | Recurring EUR | Revenue EUR | Outreach EUR | Infrastructure EUR | Personnel EUR | Total Costs EUR | Net Cash EUR | Cumulative Cash EUR |
|---|
Reasoning Audit
| Claim | Source | Reasoning Type | Confidence | Simulation Impact | Validation Action |
|---|---|---|---|---|---|
| Validate before scaling | Business visualization data | Inference | Medium | Stops premature Horizon 2 growth | Validate paid customer and support effort |
| Narrow pilot offer | Optimized business plan | Hypothesis | Medium | Improves early-cash testability | Interview 10 qualified customers |
| Setup revenue helps early cash | Optimized cash-flow forecast | Assumption | Low to medium | Moves first positive month to M4 | Test EUR 500-1,500 setup price |
| Founder pay remains risky | Founder compensation plan | Inference | High | Creates hidden funding pressure | Set minimum acceptable pay timing |
| Reference ladder limits growth | Customer size ladder | Human rule plus inference | Medium | Constrains customer count growth | Define reference gate per horizon |
| Support effort can break margin | Unit economics | Risk inference | High | Raises personnel cost and funding need | Measure setup and support hours |
Business Simulation
Growth model: previous month's marketing budget divided by customer acquisition cost estimates new customers; churn reduces active customers; revenue and costs scale with active customer count.
Simulated Revenue, Costs, and Cash
Customer Acquisition and Churn Assumptions
Monthly Simulation Snapshot
| Month | Size class (employees) | Reference status | Marketing (€) | Customer acquisition cost (€) | New customers | Active customers | Churn % | Revenue (€) | Infrastructure (€) | Personnel (€) | Total costs (€) | Net cash (€) |
|---|
Product Value Traceability
Business-Driven Technology Constraints
Business Model and Go-To-Market
Proposed Model
- Open-source core
- Documentation-led adoption
- Consulting and setup support
- Later support contracts or managed service if demand appears
Shared Horizon Model
- Horizon 1, months 1-6: prove local operational value
- Horizon 2, months 7-18: prove repeatability with external users
- Horizon 3, months 19-36: decide platform, service, or reference architecture path
Financial Forecast
Draft forecast using the shared horizon model. Values are assumptions in euros, not actuals.
Revenue Forecast
Cash-Flow Forecast
Executive Market View
Market intelligence checked 2026-06-07. Pricing and packaging must be rechecked before customer-facing use.
Ecological Niche
Market niche is prepared from market assumptions.
Market Potential
Market Sizing Terms
Competitive Positioning: Price vs Deployment Complexity
Niche Scorecard
Top Opportunities
Top Market Risks
Technical Cost Scenarios
| Option | Horizon Fit | Cash Impact | Support Impact |
|---|---|---|---|
| Local self-hosted machine | Horizon 1 | Low monthly burn | Medium setup/support work |
| Single cloud virtual machine | Horizon 2 | Medium recurring cost | May improve repeatability |
| Managed database, message broker, and Grafana | Horizon 2 to Horizon 3 | Higher burn and runway need | Can reduce operations work |
| Enterprise data platform | Horizon 3 | Major cost increase | Only justified by validated revenue |
Three-Horizon Scenario Analysis
| Horizon | Base | Optimistic | Pessimistic |
|---|---|---|---|
| Horizon 1 minimum viable product | Local pipeline works with manual setup. | Dashboard and alerts become trusted daily tools. | Stack remains fragile or not clearly better than alternatives. |
| Horizon 2 external pilot | 1-3 users test with support. | Install and value repeat with limited help. | Users prefer existing tools or need too much custom work. |
| Horizon 3 platform | Maintained open-source reference with optional services. | Support, managed service, or ecosystem path becomes credible. | No sustainable differentiation or support model appears. |
Validation Questions
Customer: Which business-to-business, business-to-consumer, or business-to-government focus and first segment should be validated?
Adoption: Which customer alternative must OpenIOTAI beat first?
Value: Is the service 10% better, 2X better, or 10X better for the first segment?
Revenue: What pilot price and support price should be used in the base forecast?
Cash: What runway is acceptable for Horizon 1 and early Horizon 2?
Technology: When is higher technical cost justified by lower support burden?
Product-Market Fit Evidence
This section is the evidence base for the Product-Market Fit verdict card on the Business Risks view. Each item exposes evidence status, source type, and the verdict concept it feeds. Items shown here are evidence inventory; they do not create a separate verdict story.
If a Product-Market Fit verdict concept (customer problem, value proposition, customer alternatives, switching friction, payment willingness, retention or repeat demand) has no matching evidence item above, the Business Risks Product-Market Fit verdict card shows it as a missing evidence relation rather than silently treating the verdict as complete.
Customer Adoption and Economics Evidence
This section is the evidence base for the Customer Economics verdict card on the Business Risks view. It joins an Adoption View (who buys, who uses, why they switch) and an Economics View (CAC, churn, LTV, payback, margin). The Customer Economics verdict must read adoption and unit-economics evidence from here, the simulator outputs, and the shared concept layer. It must not maintain its own separate adoption or economics story.
Adoption View
Economics View
If a Customer Economics verdict concept (CAC, churn, payment willingness, distribution channel) has no matching evidence item above, the Business Risks Customer Economics verdict card shows it as a missing evidence relation and keeps the verdict partial or unchecked rather than treating it as complete.
Evidence Status
Source-supported: open-source posture, self-hosted minimum viable product, low-cost constraint, Internet of Things data stack, dashboard and alerting goals.
Inferred: customer segments, value proposition, go-to-market path, and service-based business model.
Assumed: 36-month revenue forecast, cash-flow forecast, runway need, pilot pricing, and support burden.
Needs human validation: first external segment, revenue model, willingness to pay, runway target, and Horizon 2 gate.
Per-evidence-item status: see the Product-Market Fit Evidence and Customer Adoption and Economics Evidence sections above; each card carries its own evidence status and the verdict concept it feeds.
Business Risks & Dependencies
See how business analyses depend on each other, which assumptions create feedback loops, and which business-plan items still need evidence before the plan can support a start-up grant style application.
Risk Impact Map experimental
Verdict Evidence Chain represented as a risk map: how damaging a hidden error in each concept or subquestion would be. Risk = downstream blast radius to Verdicts × evidence fragility (derived from status and check count). Hover a node to light up its blast radius.
Verdict Evidence Chain
Verdict-level audit chain: conclusions read shared concepts, concepts are fed by concrete questions, and validation checks show where evidence still needs strengthening.
Funding Readiness Audit
Application-readiness audit for a pre-seed grant or starttiraha discussion. This view does not decide eligibility; it shows what the current business-plan package contains, what still needs evidence, and what must be confirmed externally.
Readiness Snapshot
Readiness Matrix
Founder Inputs and External Confirmations
Founder Inputs Needed
External Confirmations
Financial Readiness
Next Actions
Cash-Flow Simulator
Audit the recursive cash-flow model by changing parameters and comparing the current plan with the optimized plan. The controls change only parameters; both models use the same simulator engine.
Simulation Readout
Revenue, Costs, and Cash
Model Controls
Founder Playbook
The selected acquisition scenario translated into founder actions, economic trade-offs, and Horizon 3 ownership value.
Current vs Optimized Plan
Both plans run through the same engine at their default parameters, ignoring the interactive overrides above. The comparison does not automatically prefer the optimized plan; weaker metrics stay visible.
| Metric | Current Plan | Optimized Plan | Delta |
|---|
Simulation Rows
| Month | Customer Class | Marketing Target | Marketing Budget EUR | Allocated Marketing EUR | Lagged Allocated EUR | Acquisition Balance EUR | Customer Acquisition Cost EUR | Churn % | New Customers | Churned Customers | Active Customers | Revenue EUR | Partner Commission EUR | Total Costs EUR | Net Cash EUR | Funding Received EUR | Funding Gap EUR | Cumulative Cash EUR | Evidence |
|---|
Customer Economics by Group
Each customer group combines acquisition cost, monthly revenue, churn, and the underlying marketing plan. The cards show the unit economics; hover text explains the tactics and assumptions behind them.
Infrastructure Cost Structure
Infrastructure cost is shown as a concrete monthly cost stack so the simulator assumptions can be audited against the technical plan.
Personnel Cost Structure
Personnel cost is shown by phase and role. Founder time is treated as unpaid effort unless founder compensation is explicitly paid by the model.
Reasoning Audit
Each major assumption links to its evidence status, simulation impact, and a concrete validation action. Weak-evidence inputs mean the run should be read as a hypothesis, not a reliable forecast.
| Assumption | Evidence | Simulation Impact | Validation Action |
|---|
Audit Log
Concepts
Project terminology as a mind map. The graph shows only preferred terms; hover a term or relationship to read the explanation, and select a term to inspect its role in the business study.
Requirements
Source-backed requirement audit. Cards show only the implementation promise; hover exposes source, evidence status, connected features, components, risks, and review meaning.
Requirement Detail
Select a requirement card above to inspect details.
Governance
Governance turns policy into product constraints. Each card summarizes a practical constraint; hover for review context.
Three Horizons
The horizons define what to build now, what to keep possible next, and what must remain optional for later.
Horizon Detail
Select a horizon card to inspect goals, constraints, validation gates, risks, and decisions.
Integrated Analysis Network
Interactive concept map of business, requirements, features, components, risks, questions, sources, and the integrated analysis network. The view shows whether analysis outputs are connected into one decision structure.
Integrated Analysis Network
Node Catalog
Every node in the integrated analysis network, grouped by domain. Hover a node for its details; if a node carries no extra content, the tooltip says the details are empty.
Node Quality Review
Declared synonyms, duplicate candidates, and parent-child review from the report-only post-build checks. Thin parent-child profiles require an explicit phenomenon-level reason before acceptance.
Concept Catalog
Concepts grouped into the operational hierarchy and business hierarchy. Hover a concept card to view its definition, evidence, and connected relationships.
Attribute Catalog
All attributes in the integrated analysis network, sorted alphabetically. Hover an attribute card to view its measurement question, type, and connected relationships.
Implementation
The operational counterpart of the verdict view. The cards follow the seven-level 01.10 hierarchy (End Goal, General requirement, Project requirement, Architecture, Solution, Component, Building block) and the bottom-up graph runs from the lowest operational concepts up to the end goals at the top.
End-Goal Coverage
End goals (level 1) are the 01.10-mandatory target outcomes (Customer Promise, Three Horizons, Operational Fit, and OpenIOTAI's data-pipeline + self-hosted platform goals). General requirements (level 2) sit under them, not merged with them. Technologies, protocols, databases, frameworks, components, configuration files, libraries, and architecture patterns are NOT end goals unless source evidence explicitly treats them as the promised outcome.
7-level hierarchy from 01.10-decomposition-requirements-and-subtests.md: End Goals → General requirements → Project-specific requirements → Architecture / Overall approach → Major solution choices → Components and parts → Building blocks. All seven levels are shown as cards below (filterable); the bottom-up graph renders the full hierarchy.
Bottom-Up Concept Map
From concrete building blocks (configs and code) up through components and solutions, then to project requirements, then to general requirements, and finally to the end goals at the top. Edges are derived from declared satisfied_by and shared concepts; a concept carrying the same capability implies compatibility. Honest missing_relation nodes are shown when an end goal has no general requirement in its coverage.
Coverage and Coherence
Implementation (DRAFT)
Interactive Scrollable & Zoomable Concept Map. Renders the implementation-model.json with dynamic spacing, horizontal orphan stacking, and search filtering. Production Implementation tab remains unchanged.
Raahaa hiirellä panoroidaksesi ja zoomaa hiiren rullalla. Klikkaa solmua keskittääksesi sen näkymään. Hakukenttä suodattaa ja kohdistaa graafin osumiin.
Validation Decisions
These are the decisions where the system flags strategic questions or grounding gaps; hover for compact context.
Validation Decision Detail
Select a decision card to inspect the decision topic, affected artifacts, expected output, and candidate retrieval evidence when available.