Built in about a month
We built Darkworks in about a month. The software factory connects opportunity research, product planning, engineering, review, and release under one operator's direction. The workflow reduced the developers we needed from four to one, a 75% reduction in the development requirement. Our team estimates that development speed and productivity improved roughly fivefold.
Darkworks addresses the work between having an idea and knowing whether the resulting software is useful. A customer request can describe a frustration without defining a product. A specification can be complete while leaving a dependency unresolved. Code can pass a check while the intended user journey still fails. The factory organizes these different questions into stages with outputs that the next contributor can use.
In a conventional manually coordinated process, a person carries the reason for a feature between research notes, requirements, engineering assignments, and review. When that reason changes, the person has to find every affected handoff. Darkworks addresses this coordination work between stages.
The operator sets the business goal, priorities, and expected result. Darkworks connects the specialist work needed to reach it and returns material for decisions along the way. That gives an idea several possible destinations: further investigation, a smaller first version, implementation, or rejection before engineering time is spent.
Deciding which opportunity deserves engineering time
Ideas enter through market intelligence, business analysis, or a direct request. Market intelligence includes competitor changes, trends, changing requirements, new opportunities, and user feedback. Direct requests can include strategic goals, references, specific tasks, and feedback on existing software. These inputs explain why a subject deserves attention; they do not automatically establish what should be built.
Research examines users, constraints, existing solutions, and unanswered questions. Business analysis compares the expected value and impact of initiatives against available resources. The useful handoff to Product is therefore evidence for a choice. A competitor's feature may warrant investigation, while evidence that users cannot complete an existing workflow may point to a narrower change with a clearer purpose.
The distinction affects how estimates are used. An early value estimate depends on assumptions about who has the problem and whether the proposed change would help. Keeping those assumptions with the estimate lets the operator revisit the comparison when research changes the scope. Otherwise, a number attached to the original idea can continue justifying work that has become a different project.
Product planning turns the selected opportunity into requirements, scope, an architectural approach, and a task breakdown. Acceptance criteria describe what must be true for the work to count as complete. They connect the original business question to a reviewable implementation: Engineering receives a defined job, and Review receives a basis for assessing it.
How the factory coordinates delivery
The architecture separates Research, Product, Engineering, Review, and Deploy. Engineering implements, tests, fixes findings, and iterates. Review checks quality, security, and conformance to requirements against a particular version. Deploy covers release, monitoring, and optimization. Feedback after release supplies observations for another cycle of research and improvement.
Hermes directs this work. It interprets the goal, builds a plan, assigns tasks, coordinates contributors, and reports progress. Nox Infra provides the connections, shared context, permissions, observability, and execution history. Darkworks defines the product-development process that uses those capabilities. The distinction helps explain why a change to a requirement, a failed source connection, and a release decision belong to different parts of the same workflow.
Independent work can run in parallel. A task that needs an agreed requirement must wait for that input, even if an engineering agent is available. Resource allocation therefore depends on the work's dependencies as well as the number of contributors. Starting more tasks can increase unfinished work if all of them eventually wait for the same unresolved product decision.
The orchestration design also allows model selection by task type, cost, quality requirements, and constraints. A routing choice needs evaluation on comparable completed tasks before its benefit can be claimed. Telegram, web, and mobile interfaces provide ways for the operator to inspect status, approve a decision, or adjust direction. The architecture names GitHub, cloud services, databases, monitoring, analytics, and payments as integration categories; an individual workflow still needs the appropriate connection and authority.
An illustrative request becomes a first product workflow
Consider one illustrative request carried through the rest of this walkthrough: build an internal service that collects requests from several sources, preserves their context, and shows the owner the next step. This example develops the factory's operating model; it does not describe an additional customer deployment or an observed implementation episode.
Research would first clarify what a request means to the people handling it. A short message may contain the immediate question, while an attachment or earlier conversation explains why it matters. If the intended owner has to reopen several sources to decide what to do, merely collecting message titles would not answer the brief. The research output would identify which context is necessary for the first useful decision.
That investigation would also distinguish the request's origin from responsibility for acting on it. The person who submitted an item may not be its owner. A service that displays a name without resolving that distinction could look complete while still leaving work unassigned. Research would give Product this uncertainty explicitly, so the operator could decide the intended ownership rule before implementation relied on it.
For this example, Product might propose a first journey in which an authorized user opens a collected request, reads its retained context, identifies its owner, and sees the next action. The operator would review whether that journey addresses the original problem. More source types or additional views could wait if the first version already supported the essential decision.
The acceptance criteria would then need to make "preserves context" testable. In the walkthrough, a reviewer could trace an item back to its source material and check that a qualification in the original request survives the displayed summary. If the source says the requester is considering a change, the service should not turn that into an approved instruction. This connects the product's central promise to something Review could actually inspect.
The resulting specification would include the chosen journey, its scope, and the questions still awaiting a decision. Engineering could assess an implementation approach against that agreement. The architectural discussion would have a concrete purpose: support the selected sources and preserve the information needed for ownership and next-action decisions.
Engineering and review use the same agreement
Continuing the request-service example, the task breakdown would follow the agreed behavior. Work to collect an item and work to display it would need a shared understanding of what information passes between them. If each contributor invented that structure independently, the parts could work in isolation yet fail to produce the agreed user journey.
Once that shared understanding was settled, some implementation and test preparation could proceed in parallel. A change to a core assumption would require a different response. If the operator decided that the first version should only display an owner already present in the source, any proposed automatic assignment would leave the current scope. Hermes would need to carry that decision to the affected work and review criteria.
Review would examine the resulting version against the specification. For the same illustrative request, a complete check would follow collection through to the owner's decision. A working list screen alone would not establish that context had survived collection, or that the next action accurately represented the request. Quality checks would also need to consider the selected access boundaries, because gathering information from several sources can change who can see it.
A finding would return to Engineering with the failed criterion and the affected behavior. Suppose, within this example, that the request appeared but its qualifying attachment did not. The correction would concern the missing context, and the next review would inspect the corrected version. A prior positive review of another version would not settle whether this change worked.
The operator could also decide that a finding exposed an unclear requirement. If the team had never agreed which attachments belonged in the first workflow, Product would need to resolve that scope question. Sending Engineering through repeated fixes without settling it would consume capacity without moving the product toward a stable definition of done.
Release produces new evidence about usefulness
Release preparation in the walkthrough would target an agreed environment and the required human decision point. The operator would receive the implementation's current state, review evidence, and any unresolved limitations before deciding whether it should proceed. Preparing release material would not itself grant authority to change a connected environment.
The deliverable would include a working product and documentation sufficient to understand its supported workflow. For the request service, that documentation would explain which sources and ownership behavior the accepted version covered. A later contributor could then distinguish a defect in the promised behavior from a request to expand the product.
Usage metrics belong to the period after release. They answer a different question from implementation checks. In this example, a team might inspect whether owners use the service to reach a next action and whether they still have to reconstruct missing context elsewhere. Those are proposed evaluation questions, not reported usage results.
Feedback could return to Research as evidence of a remaining problem or to Engineering as a reproducible defect. The distinction changes the next investment. A failed collection step may need correction; a request for an additional source needs a value and scope decision. The factory connects release to further development without treating every observation as an instruction to add a feature.
What the staffing and speed results mean
The reported development requirement moved from four developers to one. The difference is three developer positions, or 75% of the original requirement. This describes the capacity needed for the work; it does not establish that three people were dismissed or that an actual payroll expense fell by the same amount.
The roughly 5× improvement in development speed and productivity is the team's estimate. It describes the team's assessment of the workflow, rather than a controlled comparison of identical projects. The approximately one-month build duration is a separate fact. Multiplying it by five would not establish a measured five-month conventional build baseline.
For a business choosing how to staff development, a smaller requirement can change the amount of work it can undertake with available developers. The economic effect depends on what happens to the released capacity: avoiding additional hiring, taking on another initiative, or changing the work allocated to the existing team. Those are possible uses of capacity, not additional outcomes claimed for Darkworks.
Speed and staffing describe related aspects of the same work. The useful comparison keeps the accepted output visible. Faster implementation has business meaning when it brings a reviewable product decision forward, and reduced staffing has meaning when the required quality and scope remain supported.
Estimated salary-equivalent capacity
At a US software-developer salary benchmark, three full-time-equivalent positions represent $33,270 per month, or $399,240 annualized. This is an estimated salary equivalent of the reduced staffing requirement, not net savings, actual payroll, or an observed annual result.
Calculation: 3 FTE × $133,080 annual salary ÷ 12. Benchmark: US Bureau of Labor Statistics, May 2024 median software-developer wage. Annualization assumes the staffing difference continues; tool costs, benefits, and overhead are excluded. BLS source ↗
A net economic assessment would need those execution costs, review effort, and the actual use of the released development capacity. The team's estimated speed improvement adds no extra multiplier to this salary calculation.
Evaluating the next delivery cycle
The next evaluation should follow work from an agreed brief to an accepted result. That interval includes dependency waits, review, and corrections. Measuring only the time spent generating an implementation would omit the coordination work Darkworks is intended to handle. Returned work should be examined alongside the reason for its return: a defect, missing context, or a changed requirement calls for a different improvement.
Cost per accepted task needs execution and review costs as well as developer capacity. Operator supervision time belongs in the comparison because repeated explanations and unresolved decisions consume attention even when specialists are running. After release, usage and defects help establish whether the product performs the job for which it was selected.
The architecture's ambition to support hundreds of projects is a scale objective, not a verified load-test result. Evaluating that ambition would require evidence about concurrent work, waiting, and review capacity. For the next product cycle, the concrete record to retain is the approved scope, the version accepted, the resources it required, and what happened when people used it.