An early version does not need to do everything. It does need to be clear about the things it does do.
One boundary that should not move
NIST's Secure Software Development Framework recommends integrating security practices into the software lifecycle. It is guidance for reducing risk, not a certification or a guarantee that a product is secure.
That distinction gets lost when “minimum viable” becomes shorthand for a rough screen connected to a hopeful promise. A small product can be thoughtful. A narrow feature can be reliable. The scope may be limited, but the person using it still has to understand what happened, what did not happen, and what they can do next.
Choose one complete job
A first version is easier to judge when it handles a recognizable piece of work from beginning to end. That does not mean automating every surrounding step. It means a person can start, make a meaningful choice, see the result, and recover when something goes wrong.
For example, a small writing helper might support one specific transformation of material the person provides. It should make clear what material it received, what it changed, and how to keep or reject the result. It does not need to become a complete publishing suite to do that job well. This is an illustrative design example, not a description of a launched Einhar product.
The task should be narrow enough that we can explain it in a sentence and inspect it in real use. If we need a long list of exceptions to describe what the feature is for, we may have combined several jobs too early.
Make state legible
People should not have to guess whether an action started, finished, or failed. Show the state where the decision is being made. If a process takes time, say that it is underway. If it cannot continue, explain the blocker in language that helps someone act.
This sounds ordinary because it is ordinary. It is also where many early experiences feel unfinished. A button changes color, but nothing confirms the result. A request fails and the entered text disappears. A process completes, but the result is hidden below the screen. These are not missing decorations. They break the user's understanding of the task.
A useful error message answers three practical questions: what happened, what was preserved, and what can happen next. “Something went wrong” is rarely enough. If retrying might repeat an irreversible action, the message should say so. If a person can safely try again, make that path easy to find.
Preserve choice and a way back
Automation should not take control away without a clear reason. When an action can overwrite, send, publish, spend, or expose something, its consequences should be understandable before it happens. Where possible, give the person a preview, a chance to review, and a route to undo or revise.
The right safeguard depends on the action. A reversible formatting change can be lightweight. Sharing private material with another service deserves a clear explanation and explicit choice. A system that produces uncertain output should make the uncertainty visible and let a person inspect the result before relying on it.
An early version can choose not to support some cases. It should not quietly pretend to support them. State the boundaries in the moment they matter, and make the next available option clear. This helps people decide whether the product fits the task without reading a separate manual.
Treat failure as part of the path
Every real system has limits: a connection can drop, an input can be malformed, a service can be unavailable, a person can change their mind. Designing the happy path and calling the rest edge cases simply moves the burden onto the person who encounters them.
For each important action, consider what the person sees when it is waiting, when it succeeds, and when it cannot succeed. Ask what information should be saved, what can be tried again, and whether someone needs to be told about a partial result. The answer does not always require a complicated fallback. Often a clear message and preserved work are enough.
Spend attention where mistakes matter
Clarity is not the same as adding a warning to every action. Too many prompts turn important choices into routine clicks. Put the most attention around decisions with real consequences, and keep ordinary steps easy to understand.
We can ask: what might surprise someone here? What could they lose? Who else could be affected? Can they reverse it? The answers help us choose whether the interface needs a preview, confirmation, permission control, or simply more useful wording.
The same questions apply to AI-assisted work. A draft or suggestion is different from an action taken on someone's behalf. A generated answer should not be presented as verified fact just because it is fluent. A useful early product shows where a person can inspect, adjust, and decide.
“Early” is a promise about what comes next
Calling something an early version sets an expectation. The team is still learning, and the product may change. That should be paired with a responsible way to hear what happened and decide whether the next version is worth making.
We should be careful not to promise a roadmap we cannot support. Better to say what the current version does, how to report a real problem, and what information we collect to improve it. If we cannot support a feature reliably yet, we can leave it out and explain the boundary.
The first version is a relationship with a person doing actual work. It asks for their time and trust. In return, it owes them a coherent task, understandable behavior, respect for their choices, and an honest account of its limits. Keeping that promise is more valuable than making an unfinished product look large.
Sources and scope
The product examples and first-version checklist are Einhar's design principles. The external reference is NIST SP 800-218, which recommends incorporating secure-development practices into the software lifecycle and describes their intended risk-reduction benefits. It does not certify an individual product or guarantee that a particular implementation is safe.