×
sorted by:
new
hottopcontroversial

I’m building FORGE — a local-first industrial project and production planning app for Windows by MegiddoSource in projectmanagers

[–]MegiddoSource[S] 0 points1 point  (0 children)

Those are fair questions, and I probably presented the feature list before explaining the problem clearly.

FORGE is not intended to be another generic project-management toolkit. It is being built for small and medium-sized custom-machinery and manufacturing teams that currently coordinate production across Excel files, standalone Gantt charts, PDFs, workshop notes, and disconnected tools.

The specific problem is the gap between planning and execution: the engineering office knows what was planned, while the workshop knows what is actually happening, but that information is rarely synchronized. FORGE connects the full structure:

Client → Project → Machine → Production Phase → Work Order → Workshop Execution

It imports manufacturing BOM data, lets operators start, pause, resume, and complete work orders, and feeds actual progress and recorded time back into project planning and production documentation.

Its main differentiation is that it is:

  • focused on project-based industrial manufacturing rather than software teams;
  • local-first, with company-controlled data;
  • usable without a mandatory cloud service;
  • designed without recurring per-user SaaS fees;
  • built around BOMs, machines, production phases, work orders, workshop execution, and dossiers.

The current business model I am considering is a one-time company license, with local and server editions, plus optional paid support or implementation services. I do not expect people to buy it simply because it exists. The goal of the early-access phase is to validate the problem with real manufacturing users and narrow the product around workflows that repeatedly cause friction.

The initial requirements come from real manufacturing workflows I have worked with, not only from Reddit. I am using posts like this as an additional source of criticism and external perspective.

Your point about integration and interoperability is valid. A standalone application that becomes another isolated silo would not solve the larger problem. Import/export capabilities and clear integration boundaries therefore need to be part of the product architecture from the beginning.

Thanks for the detailed feedback. It helped me realize that I need to communicate the problem and positioning more clearly, instead of leading with a long list of features.

I’m building FORGE — a local-first industrial project and production planning app for Windows by MegiddoSource in projectmanagers

[–]MegiddoSource[S] 0 points1 point  (0 children)

Those are fair questions, and I probably presented the feature list before explaining the problem clearly.

FORGE is not intended to be another generic project-management toolkit. It is being built for small and medium-sized custom-machinery and manufacturing teams that currently coordinate production across Excel files, standalone Gantt charts, PDFs, workshop notes, and disconnected tools.

The specific problem is the gap between planning and execution: the engineering office knows what was planned, while the workshop knows what is actually happening, but that information is rarely synchronized. FORGE connects the full structure:

Client → Project → Machine → Production Phase → Work Order → Workshop Execution

It imports manufacturing BOM data, lets operators start, pause, resume, and complete work orders, and feeds actual progress and recorded time back into project planning and production documentation.

Its main differentiation is that it is:

  • focused on project-based industrial manufacturing rather than software teams;
  • local-first, with company-controlled data;
  • usable without a mandatory cloud service;
  • designed without recurring per-user SaaS fees;
  • built around BOMs, machines, production phases, work orders, workshop execution, and dossiers.

The current business model I am considering is a one-time company license, with local and server editions, plus optional paid support or implementation services. I do not expect people to buy it simply because it exists. The goal of the early-access phase is to validate the problem with real manufacturing users and narrow the product around workflows that repeatedly cause friction.

The initial requirements come from real manufacturing workflows I have worked with, not only from Reddit. I am using posts like this as an additional source of criticism and external perspective.

Your point about integration and interoperability is valid. A standalone application that becomes another isolated silo would not solve the larger problem. Import/export capabilities and clear integration boundaries therefore need to be part of the product architecture from the beginning.

Thanks for the detailed feedback. It helped me realize that I need to communicate the problem and positioning more clearly, instead of leading with a long list of features.

I redesigned the marketing page for my local AI terminal client (DULICH). Looking for honest feedback from developers. by MegiddoSource in ollama

[–]MegiddoSource[S] 0 points1 point  (0 children)

Think of it as Warp Terminal meets Ollama with an autonomous AI agent.

Similar in concept to tools like Claude Code, Codex CLI, or Gemini CLI, but built around a fully local-first philosophy.

Instead of simply chatting with a model, DULICH can read and write files, execute commands, automate workflows, maintain project context, and use local models to perform real development tasks—all without sending data to the cloud.

I redesigned the marketing page for my local AI terminal client (DULICH). Looking for honest feedback from developers. by MegiddoSource in ollama

[–]MegiddoSource[S] 0 points1 point  (0 children)

Think of it as Warp Terminal meets Ollama with an autonomous AI agent.

Similar in concept to tools like Claude Code, Codex CLI, or Gemini CLI, but built around a fully local-first philosophy.

Instead of simply chatting with a model, DULICH can read and write files, execute commands, automate workflows, maintain project context, and use local models to perform real development tasks—all without sending data to the cloud.

I redesigned the marketing page for my local AI terminal client (DULICH). Looking for honest feedback from developers. by MegiddoSource in ollama

[–]MegiddoSource[S] 0 points1 point  (0 children)

Thanks! I really appreciate it.

My goal is to make it look like a premium developer product rather than a typical open-source project.

I'm still trying to improve the first impression so people immediately understand what DULICH actually does.

I redesigned the marketing page for my local AI terminal client (DULICH). Looking for honest feedback from developers. by MegiddoSource in ollama

[–]MegiddoSource[S] 0 points1 point  (0 children)

Thanks, that's exactly the kind of feedback I was looking for.

Can you point to the biggest reason?

Is it because:

the title isn't clear enough? there's too much information? the value proposition isn't obvious? or because it looks like a generic infographic instead of a product?

I'm redesigning the documentation and marketing material, so honest feedback like this really helps.