A tool can look like a web application without needing accounts or a database. The important question is what it has to remember, who can change that information, and whether everyone needs the same authoritative version.
CraftNet is a useful example. It calculates crafting costs and material shortfalls for a FiveM roleplay community. The player provides the inputs, the browser calculates the result, and a link can carry the configuration to someone else.
That is a different job from running a staff console with private records. The architecture should reflect the difference.
01 / FIELD NOTESThe tool that does not need an application server
CraftNet's documented inputs are the crafting queue, recipes, prices and stock on hand. It returns a bill of materials that accounts for the shortfall, alongside the costing work described in the project.
The source account puts the configuration in the URL. Opening that link reconstructs the same setup in another browser. There is no account required to retrieve a record because the link carries the inputs used to calculate it.
This shares a snapshot. It does not mean two people are editing one continuously synchronized build, and it does not establish access to live game inventory.
03 / FIELD NOTESFewer services does not mean nothing can go wrong
Leaving out an account database removes that particular database and login flow from the design. It does not remove every security, privacy, delivery or maintenance concern from a website.
In CraftNet's case, the URL is part of the sharing mechanism. Anyone given the configuration can read or reconstruct it. Sensitive information should not be placed there merely because it is encoded. For query strings specifically, OWASP describes exposure through history, logs and other URL handling. The original account does not supply CraftNet's complete URL schema, so that is a general privacy consideration, not a finding about its logs.
A static application also still depends on its delivery path and client code. “No application backend” describes a responsibility that was left out; it is not a guarantee that the entire system cannot fail.
04 / FIELD NOTESWhen the requirements change
Navarro and Southside Records serve a different purpose. Their published accounts include staff workflows and stored records, not just calculations a visitor can reproduce from a set of inputs.
For a tool like CraftNet, adding private inventory history, shared editing or server-controlled decisions would change the brief. Those features should be evaluated directly rather than added because a web app is expected to have a login screen.
A useful starting question is: what must be true for this result to be useful to its reader? If the reader needs a calculation from a known setup, the browser may be enough. If the result depends on restricted, durable, shared or authoritative state, that responsibility needs an explicit design.
05 / FIELD NOTESKeep the architecture close to the task
CraftNet's strongest decision is not simply having fewer services. It is matching the implementation to an understandable task: configure a queue, calculate the missing materials, and share the setup.
Start there. Add persistence, permissions and shared infrastructure when the work calls for them, and state their costs and limits just as clearly as the benefits.
Source, dates, and what this page verifies
This page describes the supplied project account and related full article. Original publication dates remain attached to the source version. No production repository, message provider, Google Sheet, user account or game service was accessed.
The diagrams are newly implemented teaching examples, not screenshots or re-creations of complete application logic. They use fictional data and memory-only state; the CraftNet fragment carries bounded numeric example settings only. Original code excerpts are preserved and are not executed as production code here.
Technical clarifications and source corrections are identified in the article and in docs/batch-3/SOURCE-REVIEW.md. They do not constitute a new application security, performance or deployment audit.