We bill for what ships, not for time logged. That model only works if everyone — including you — has the same answer to one question: what counts?
A delivery is a discrete, validated unit of work that produces a measurable change in a business objective — shipped, tested, and observable in production.
This is not a general description. It is a precise commitment. Each term below rules something in and rules something out.
A clear start and end. One delivery does not bleed into another. You can point to it and see exactly when it entered the system and when it shipped.
Someone other than the person who built it confirmed it does what it was supposed to do. It passed the agreed acceptance criteria defined before implementation started.
Before this delivery, the business or user could not do something — or did it worse, slower, or at greater risk. After it ships, something observable is different.
Staging does not count. A demo does not count. A delivery is live, accessible, and doing its job in the real environment where it creates value.
Before any piece of work enters the delivery system, it must satisfy all three of these conditions. Two out of three is not enough.
Every delivery must trace back to a real business outcome — revenue, retention, activation, risk reduction, cost savings, time savings. Not a technical objective. A specific, observable result.
"When this ships, [specific business outcome] improves because [mechanism]."
If you cannot complete that sentence with a concrete answer, the work is not ready to be committed as a delivery.
The delivery must have agreed acceptance criteria written in plain language, verifiable by a non-engineer, and defined before implementation begins. These are the contract between Nolte and the client.
Acceptance criteria written after the fact are not acceptance criteria. They are retrospective rationalization.
A delivery must be completable within a single week of active work. If a piece of work is too large, it must be broken into smaller deliveries — each with its own business objective and acceptance criteria.
This rule protects forecast accuracy. Consistent sizing is what makes throughput data meaningful.
All three types must satisfy the three requirements above. The type determines the nature of the work — not whether the definition applies.
A new behavior, feature, or experience that an end user or business stakeholder can observe directly.
Infrastructure work, dependency upgrades, integrations, and configuration that produces a concrete, observable output.
A confirmed defect that causes the system to behave differently from agreed acceptance criteria, resolved and confirmed in production.
The definition is abstract. These examples are concrete. Each one shows what qualifies and — equally important — what does not.
A CPG insurance broker wants to reduce friction for small brands seeking general liability coverage. Prospects currently contact the team by email and wait 2–3 days for a quote.
Enable prospects to submit a GL quote request via a structured online form that routes directly to the broker's intake workflow, with a confirmation sent within 60 seconds.
The platform is running Node.js 16, which reaches end-of-life and will no longer receive security patches.
Upgrade Node.js runtime from v16 to v20 LTS across all services, validate that all existing test suites pass, and deploy to production with a rollback plan documented.
A client reports that the password reset flow silently fails for accounts created via Google OAuth. Users receive no error and no email.
The bug is verified against the original acceptance criteria, reproduced, fixed, and confirmed resolved in production.
Before any item is committed as a delivery, it goes through this test. If any answer is no, the work is not ready to enter the delivery system.
Check each question as you confirm it. All six must be answered yes before the work is a delivery.
Hourly billing was built around activity. Log the hours, bill the hours. Whether the work moved the business forward was someone else's problem.
Predictive software delivery is built around commitment. We commit to a delivery, define what done means before we start, validate it in production against those criteria, and stand behind the forecast with a guarantee.
Every forecast we make, every invoice we send, every conversation about what you got for your investment — it all rests on this definition being clear, consistent, and lived.
Describe your product idea in plain language. NolteOS analyzes it against 20 years of experience and historic delivery data and surfaces: