Digital Engineering/AI Product Assurance/AI-Assisted Product Development
Build at agent speed, with the engineering underneath it
You have an idea, a deadline and a budget that does not stretch to eighteen months of traditional delivery, or a prototype that proved the idea and now has to become the real thing. We build new products at close to the rate the fast tools manage, with the architecture designed before generation starts and a named engineer accountable for every merge.
Two bad options, and why you do not have to pick either
Anyone commissioning software in 2026 is offered the same two doors. The framing invites you to choose between speed and durability. You are not choosing: those two things have different sources.
Door one: the conventional partner
Discovery workshops, a requirements document, a delivery plan measured in quarters, a rate card, and a team assembled around your project. The work is usually competent. It is also slow in a way that has stopped being explainable to a client who watched a friend put a working product in front of customers in a month, using tools costing less than a day of that rate card.
Door two: raw speed
A small studio, or your own hands, and an agent that turns a description into a running application by Thursday. This works, and the output is not fake. The problem arrives later, in a repeatable order: the schema will not hold the second customer type, nobody can say who is allowed to see what because the permission model was never designed, no test is worth running so every change is a gamble, and it all lives on one deployment nobody can roll back. That bill is deferred rather than avoided, it accrues interest, and it lands in the same month as the first enterprise prospect.
The third door: governed generation
Speed comes from generation. Fragility comes from ungoverned generation, which is a different thing and a solvable one. An agent given a designed data model, an explicit boundary set, a security rule file and a stop condition produces sound code at almost the rate of one given a paragraph and no constraints. The difference in quality is enormous. The difference in elapsed time is days, spent once, at the front.
Governed agentic delivery: what actually controls the generation
“We use AI” is not a method. Here is ours.
An approved model and IDE list.
Client code is written using a defined set of models and development environments, recorded in the engagement note and reviewed quarterly. Where your contracts or customers restrict which providers may process your intellectual property, that restriction is applied at the tooling level before a line is written, and data-retention settings are documented rather than assumed.
Architecture and the data model are designed by engineers before generation begins.
The load-bearing rule, with its own section below: no feature generation starts until entities, ownership, boundaries and the write path exist as a written design in the repository.
House context and rules files, committed to the repository.
Every project carries machine-readable context: the data model, the module boundaries and what each may call, naming and error-handling conventions, the security rules, the test expectations, and the decisions already made with their reasoning. Every agent session starts from that file rather than an empty prompt. Three sessions on three days produce three compatible implementations, because all three read the same instructions. That is the difference between directed generation and drift.
Security-explicit prompting, referenced to OWASP and MITRE CWE.
Generation instructions carry the component's control expectations: how authorisation is enforced, what input is untrusted, how secrets are read, what must never appear in a log or an error. Known weakness classes are named by CWE identifier in the instruction and again in the review checklist. Work is assessed against the OWASP Application Security Verification Standard and the OWASP Top 10, with lifecycle practice referenced to NIST SSDF. We identify gaps relevant to those standards. We do not certify compliance against them.
Automated scanning before a human reads it.
Static analysis, dependency and licence scanning and secrets detection run on every branch, tuned to the stack rather than left at defaults, so review time goes on judgement.
Explicit agent stop conditions.
An agent escalates rather than improvises. Changing the schema, adding a dependency, touching authentication or authorisation, widening a permission, modifying CI or infrastructure definitions, deleting a test, or reaching for a credential: each halts the session and raises it to the engineer who owns that area, because improvisation at those boundaries is where the failures we audit get created.
Human accountability on merge.
A named engineer approves every merge and owns the consequences. “The agent wrote it” is not a review status and appears nowhere in our process. The commit trail records what was generated and by which model, so provenance is answerable a year later.
Built to production standard on day one, not retrofitted at the end
All of it exists from the first working increment, rather than as an end-phase cut when the date moves.
A test suite worth running.
Coverage of the paths where being wrong costs money, across payments, permissions, data deletion and state transitions, written as specifications of intended behaviour rather than descriptions of what the code does. Tests that mirror the implementation give confidence you have not earned.
Continuous integration from the first commit.
Build, test, static analysis, dependency and licence scanning and secrets detection on every branch. A pipeline added in month four ratifies four months of decisions. One present in week one prevents them.
Real environments.
Local, a staging system close enough to production that testing against it proves something, and production. Configuration and secrets are managed per environment through a managed store, never typed into a dashboard.
Deployment and rollback as a process, not a person.
Releases are automated, versioned and traceable to a commit. Going backwards is a tested path, including the database: forward migrations ship with a reverse path executed at least once.
Observability that answers questions at 3am.
Structured logs correlated by request, error collection with alerting routed to a person, and enough signal to distinguish “the whole system is down” from “one dependency is slow”.
Secrets handled properly.
Scoped credentials per service, documented rotation that needs no redeploy, and no long-lived keys in a shared document or terminal history.
Dependency and licence hygiene.
Every package chosen deliberately and recorded with its source, maintenance status and licence. A copyleft dependency found during an acquisition is a legal problem, and far cheaper to avoid at selection than to unpick later.
Every build is assessed against The Noseberry Product Assurance Framework
We assess our own delivery against the six dimensions we apply to software other teams built: Code Health, Application Security, Product Architecture, Scalability & Performance, Cloud & Delivery, Engineering Governance. Same method, same evidence, same status labels.
Read the assessment methodologyCode Health
Structure, duplication, naming and boundary discipline, and a test suite an incoming engineer can trust from the first fortnight.
Application Security
Authorisation and tenancy designed before generation, secrets handled through a managed store, and every branch scanned before a human reads it.
Product Architecture
An entity model that owns the truth about a record, boundaries that hold, and a design written down before the first feature was generated against it.
Scalability & Performance
Query behaviour under realistic volume and the load at which today's deliberately simple choices would need revisiting, recorded with the reason.
Cloud & Delivery
Environments separated, infrastructure defined as code, deployment and rollback automated, and observability that answers a question at 3am.
Engineering Governance
A commit trail recording what was generated and by which model, a named engineer accountable on every merge, and the decisions written down.
The assessment runs before handover, carried out by an engineer who did not write the code. Each dimension receives a status of Critical, Needs Attention or Ready, and every finding carries a class and a business-impact statement, exactly as it would if you had commissioned an AI Code Audit on a system we had never seen.
You receive that report whatever it says. Where you chose to launch with a deliberately simple approach, the dimension is recorded as Needs Attention with the reason and what would change it. A build report with six Ready statuses and no findings would tell you the assessment was decorative. We audit AI-built software because we submit our own to the same examination, and you can read that standard before hiring us.
Who this is for
Founders who have not built anything yet.
You have the idea, the market knowledge and often the first customers waiting. You have no engineering team and no wish to spend six months acquiring one before software exists.
Founders with a prototype that did its job.
The demo won the round or the pilot. It was never meant to carry real customers, and now it has to. You want version two built properly without losing what version one taught you.
Product leads inside larger companies.
There is an internal idea, a sponsor and a budget, and the in-house engineering queue is eleven months long. You need it built outside, to a standard your architects accept.
Technical founders who need capacity, not direction.
You know what should be built. You want engineers working at agent speed inside your standards and your repository.
Teams whose first supplier delivered something hollow.
A cheap build came back working and unmaintainable. You need an honest view of what can be kept, and someone to continue rather than restart.
Four ways this engagement runs
Discovery and architecture sprint
A short, fixed-scope engagement producing the design before anybody commits to a build: product definition and scope boundaries, the entity and data model, the service boundaries, the security and tenancy model, the stack decision, a build estimate with its assumptions visible, and the decision records that seed the repository. It stands alone: clients have taken it to their own team or another supplier, which is a legitimate outcome and priced as one.
MVP build
A defined first release built end to end and launched: the product, the tests, the pipeline, the environments, the infrastructure definitions, the observability and the documentation. Scope is fixed per increment rather than for the whole project, because the useful thing about building at this rate is responding to what the first users do.
Product team extension and ongoing build
A standing engineering capability against your roadmap. Named engineers working in your repository, to agreed review standards, under the governed generation process. This is where most MVP engagements go next, and it suits a company with a product manager but no development team.
Rescue and continue
For a prototype that has to become a product. We start with an assessment rather than a plan, apply a Retain / Refactor / Replace decision component by component, keep what works and build the rest properly around it. Frequently the data model is replaced while most of the business logic survives.
Where the priority is remediation rather than new capability, Vibe Code Cleanup is the better purchase and we will say so.
From first conversation to launch
Discovery and product definition
define
What the product must do, for whom, and what “done” means for the first release. We push hard on scope, because the most expensive decision in a first build is the feature included by default and used by nobody. Output is a written scope with explicit exclusions, the constraints that matter (regulatory, integration, data residency) and the measures the build is aimed at.
Architecture and data model
design
Engineers produce the entity model, ownership rules, state transitions, boundaries, the security and tenancy model, the stack decision and the deployment topology, written to the repository as decision records and schema and converted into the context files generation runs against. This is where the three days go.
Governed build in increments
build
Working software from the first increment, deployed to a real environment you can use, with pipeline, tests and scanning in place. You see the product every week, and scope for the next increment is agreed against what you have just used rather than a document written before anything existed.
Hardening and pre-launch assessment
harden
Load behaviour under realistic data volume, a security pass referenced to OWASP ASVS, backup and restore executed rather than configured, rollback rehearsed, alerting routed to real people, and the framework assessment run from outside the build team. Findings are classified and either fixed before launch or recorded with an owner and a date.
Launch and handover
launch
Release, then the handover described below: repositories, infrastructure, documentation, decisions record and assessment report, with recorded walkthroughs. A support window follows, so the first weeks of real traffic are covered by the people who built it.
Elapsed time depends far more on scope and on how quickly decisions come back from your side than on our capacity. You get a considered estimate after step one and a firmer one after step two.
What you receive
- A running product in your own cloud accounts, deployed through an automated pipeline, with staging and production separated and configuration managed per environment.
- The complete source code in your organisation's repositories, with a commit history showing how the system reached its current state, not one import commit.
- An architecture and data model document describing entities, ownership, boundaries and the write path, with decision records explaining each significant choice and what was rejected.
- The context and rules files we generated against, so your next engineer or next agent works to the same standards rather than from an empty prompt.
- A test suite and continuous integration configuration running on every branch, including the security, dependency and licence scanning stages.
- Infrastructure defined as code, so environments rebuild from the repository rather than from memory and a hosting dashboard.
- An operational runbook covering deployment, rollback, backup and restore, alert response, and what to check first at 3am.
- A full assessment against The Noseberry Product Assurance Framework, with a status for each of the six dimensions, a classified findings register, and a business-impact statement for anything not Ready.
- A dependency and licence inventory listing what is in the product, where it came from, its maintenance status and any obligation attached.
Handover and ownership
You own the code, the documentation, the infrastructure definitions and the decisions record. Not on completion but throughout.
Ownership starts on day one.
Repositories are created in your organisation and we are granted access to them, rather than the reverse. Cloud accounts are yours from the first deployment, with our engineers holding scoped roles inside them. There is no migration event at the end, because nothing sits on our side to migrate. Take the work elsewhere in week five and you already hold all of it.
No lock-in of any kind.
No proprietary framework, no Noseberry runtime, no hosted component you keep paying us for, no licence in our name. The stack is mainstream, chosen so hiring against it is easy. Anything reusable we bring is delivered under a licence you own outright and named in the dependency inventory.
Access is closed properly.
At handover our roles are removed, credentials we held are rotated by you, and what was revoked is written down. Domain, registrar, cloud, monitoring and CI accounts are confirmed as being in your name before the engagement is complete.
Two recorded walkthroughs.
One engineering session covering architecture, data model, pipeline and runbook; one for whoever makes product decisions without reading code. The engineer you hire in October gets the briefing you had in July.
Where we do not use AI, and where we use it carefully
Generation has known weak points. These are ours, enforced in the rules files rather than left to individual discretion.
Design decisions are not generated.
The data model, the boundary set and the trade-offs behind them are made by an engineer who signs the decision record. We do use models as challengers against a design an engineer has already produced, which is useful for finding cases nobody considered. The decision stays human.
Security controls are specified by hand.
The authorisation model, permission boundaries and tenancy isolation are written by an engineer and reviewed by a second. Generation may implement a specified control. It may not invent one.
No generated cryptography or authentication primitives.
Password storage, token handling, session management and anything cryptographic use vetted, maintained libraries. This is where plausible-looking generated code is most often quietly wrong.
Tests protecting money, permissions or data deletion are written by hand.
Generated tests assert what the code does, which is the wrong direction of proof where being wrong is expensive.
Dependencies are chosen by a person.
Left alone, an agent will import a package with forty weekly downloads, one maintainer and an ambiguous licence. Each is selected against provenance, maintenance and licence.
Extra care, not exclusion, applies in three places.
Database migrations are reviewed line by line and ship with a tested reverse path. Infrastructure changes are diffed against a plan a human reads before anything is applied. Customer data export and deletion are reviewed twice.
Client production data never enters a model.
Not for debugging, not once. Fixtures are synthetic.
How this differs from a development agency and from building it yourself
Versus a conventional agency
The difference is rate and transparency. A team estimating in quarters is pricing an approach agentic delivery has made slower than it needs to be. Meanwhile a growing number of agencies use these tools and do not mention it, which is the worst arrangement available to a client: hand-written rates, generated code, and none of the governance that makes generated code safe. We say where generation is used, we constrain it, and we hand you the assessment.
Versus building it yourself with a tool
The honest comparison is narrower than either side of the argument admits. For a first version, a waiting-list page, an internal utility or a prototype whose job is to win a conversation, the tools are faster than we will ever be, and cheaper, and you should use them. We say so on scoping calls. What the tools do not do is refuse. They will not stop to design your data model before generating against it, decline to widen a permission, hold a dependency to a licence standard, insist on a tested rollback path, or accept responsibility for what shipped. Those refusals are the product here. The speed is the same. Somebody is answerable for the result.
Why Noseberry
We know the failure catalogue because we are paid to read it.
Most of our work is examining AI-built software that did not survive contact with customers. Every control on this page exists because we have seen what its absence costs.
Our own delivery is assessed by the standard we apply to everyone else.
The framework is not a device pointed outward. It is applied to our builds, before handover, by an engineer who did not write the code, and you get the report whatever it says.
Engineers who have operated what they built.
The people designing your data model and approving your merges have carried a pager. That experience turns a design review into specific decisions rather than preferences.
The method is published, and we will tell you not to hire us
The dimensions, the evidence behind each and the classification rules are on the methodology page, so you can read the standard we are held to before signing anything. And if the right next step is another two months on the tool you already use, or a production readiness engagement instead of a rebuild, we say so on the call. That costs us a project and is still correct.
Frequently asked questions
For a first version it often is not, and we will say so if that is the honest answer for you. Those tools are excellent, and for prototypes and internal utilities you should use them. The difference appears when the software must carry real customers. We design the data model and permission boundaries before generating against them, scan every branch, hold agents to stop conditions so they escalate rather than improvise at security boundaries, and put a named engineer's accountability on every merge. You are buying the constraints, not the typing speed.
We will not put a number on a web page, because anyone who does is quoting a scope they have not read. The honest answer is the shape: architecture takes days rather than weeks, usable software appears in the first increment rather than at the end, and elapsed time is driven far more by scope discipline and your decision speed than by our throughput. After a discovery conversation you get a considered estimate with its assumptions visible, and a plain answer if a date promised externally is not achievable.
Yes, entirely, and from the first day rather than the last. Repositories are created in your organisation and we work inside them. Cloud accounts are yours, with our engineers holding scoped roles. You receive the source, documentation, decision records, infrastructure definitions, test suite, pipeline configuration and the context files we generated against. There is no proprietary framework, no hosted component you keep paying for and no licence in our name. End the engagement in week five and you already hold everything.
Because we hand you evidence rather than assurance. Before handover, every build is assessed against The Noseberry Product Assurance Framework by an engineer who did not write it, producing a status for all six dimensions and a classified findings register with business impact attached. That is the same report an external client receives on software we have never seen. You can read the methodology before hiring us, commission a third-party audit against the same standard, and hold us to the difference.
This page is quote-led because build scopes vary by an order of magnitude and a published figure would mislead in both directions. The conversation usually runs in this shape: a fixed price for the discovery and architecture sprint, which stands alone and is yours to take elsewhere; then either a fixed price per increment against a scope agreed at the start of each, or a monthly rate for team extension. Rescue engagements are quoted after an assessment, because nobody can price remediation before reading the code.
It varies by component, and the split is deliberate. Interface work, data access, integrations, routine business logic and much of the test suite are generated under direction and reviewed. The data model, the authorisation and tenancy design, cryptographic and authentication handling, dependency selection and the tests covering payments, permissions and data deletion are written by hand. The commit trail records what was generated and by which model, so provenance is answerable later, which matters more than the percentage does.
Usually not, and the decision is made against evidence rather than instinct. We assess what exists and apply a Retain / Refactor / Replace decision component by component. The common pattern is that the data model is replaced while much of the business logic survives, because that logic encodes product understanding that took months of customer contact. A full restart is occasionally correct, most often when the data model cannot represent the product you now sell, but it should be a finding rather than an assumption.
Mainstream, boring and widely hired for. The choice is made during architecture against your integration requirements, your team's existing skills and where you expect to hire, and the reasoning goes into a decision record rather than being our house preference applied by default. Everything is deliberately conventional, so an engineer you hire next year is productive in days. The handover includes recorded walkthroughs, a runbook and the context files, which is what makes an incoming team effective rather than archaeological.
A support window follows launch, so the first weeks of real traffic are covered by the people who built the system. After that, most clients take one of three paths: their own hires take over using the handover material, we continue as a product team against a roadmap, or periodic reassessment covers the product as it changes. Continuous Product Assurance is the subscription shape of the last. None of them is a condition of the build, and the handover is complete whether you buy any of them or not.
Less than usual, and with fewer surprises, because you will already be holding the findings. A build delivered this way arrives at diligence with a documented architecture, a decisions record, a test suite and pipeline, infrastructure as code, a dependency and licence inventory, and a dated assessment against a published framework. Diligence teams are not unsettled by open findings; they are unsettled by teams who cannot say where they stand. If you want the exercise run properly in advance, Software Technical Due Diligence does exactly that.
Tell us what you are trying to build
Send a paragraph about the product, who it is for and any date you are committed to. We come back within two working days with an honest view of the shape, the sequence and the commercial conversation, including when the right answer is to carry on with the tools you already use.
Related resources
Go deeper with our thinking
From Spreadsheets to a Scalable Platform – building Canada’s Most Tenant- First Coliving System
Read case study
How to Build a SaaS Product
Read guide
The MVP Development Guide
Read guide
Building a Digital Engineering Roadmap That Aligns With Business Goals
Read article
Engineering IoT Products: Key Challenges and Best Practices
Read articleNot sure where you stand?
Take a free two-minute readiness scorecard built for your industry.