DAVINCI. Development AI

How we deliver

The unglamorous part, written down.

This page exists so that your architecture, security and procurement people can answer their questions without a call. It is written plainly and it is what we actually do.

If something here does not match your control framework, say so early. We build to your standards; we do not ask you to adopt ours.

Method

Four phases, in this order, every time.

The order matters. Skipping the diagnostic is how a six-month build becomes an eighteen-month build.

01

Diagnostic

A principal and one senior engineer go through your systems, data and constraints and come back with a written assessment: what the real bottleneck is, what we would build, what we would not, and where the schedule risk sits. Fixed fee, credited against the build if you proceed. You keep the assessment either way.

1–3 weeks
02

Architecture & plan

Target architecture, integration map, data contracts, security constraints, acceptance criteria and a staged delivery plan with named roles against each stage. You get a document your own engineers can argue with — that argument is the point, and it is cheaper now than in month five.

2–4 weeks
03

Production build

Two-week sprints, a demo every sprint, working software in your environment from sprint two. A named technical lead is accountable for velocity and quality; the principal sponsor stays on for architecture and executive reporting. Scope changes are priced in the same week they are raised.

Sized at architecture
04

Launch, stabilize, transfer or operate

Deployment, monitoring and alerting, runbooks, training and a defined stabilization window where we own incidents. Then either we continue under managed support, or we hand over: paired handover, documented system context, and a transfer period where your team drives and we sit behind them. Decided before the build starts, not after.

Agreed at kickoff

Enterprise delivery standards

What you can expect, in writing.

Subject to the final agreement in every case. Nothing below is aspirational.

Client-controlled environments

Where required, we build and deploy inside your AWS, Azure or GCP tenancy rather than ours. Your accounts, your network boundary, your logging. For clients without an existing environment we will stand one up and transfer it, or run it under a managed arrangement — your choice, made before the build starts.

Repository model

We work in client-controlled Git repositories by default. Where a client prefers we host during the build, the repository and full history transfer at handover. We do not keep a private fork of client work.

Source code & IP

Our default position on client-funded work is that the client owns the resulting source code and intellectual property outright, on payment, subject to the final agreement. Pre-existing DaVinci components and open-source dependencies are identified in the architecture document and licensed to you rather than assigned. We will not build you a system you cannot leave with.

Documentation

Documentation is a deliverable with acceptance criteria, not a closing task. Every production engagement includes:

  • Architecture diagrams and decision records
  • Deployment and environment documentation, as infrastructure-as-code wherever possible
  • Operational runbooks, including failure modes and rollback
  • API and integration documentation
  • Handover material written for an engineer who has never met us

Access & secrets

Least-privilege access, requested per role and per environment, with production access limited to the smallest set of people the work requires. Secrets live in your secrets manager, never in code, tickets or chat. Access is reviewed at each phase boundary, and offboarding — ours and yours — is a documented checklist with credential revocation, not an email.

AI data handling

We tell you exactly where your data goes. If a system calls a third-party model provider, that is stated in the architecture document with the provider, the endpoint, the data classification sent and the contractual terms it runs under — normally your own enterprise agreement with that provider, not ours. Where data cannot leave your boundary, we design for models running inside it and say so at architecture rather than discovering it at security review. We do not make claims about a provider’s training or retention behaviour beyond what that provider’s contract and configuration actually support.

Security review

Threat modeling at architecture, dependency and license review in the pipeline, structured logging and auditability built in rather than added, and secure code review on anything touching authentication, authorization, payments or regulated data. We support your security review directly — questionnaires, architecture walkthroughs and remediation are in scope, and we would rather your team found something than a penetration tester did.

Production readiness

Nothing goes live without monitoring, alerting, a tested rollback path and a named incident owner. We hold a stabilization window after launch — typically 30 days, agreed at kickoff — during which production incidents are ours regardless of cause, with the technical lead who built the system on the response. At the end of that window we transition to the support model agreed before the build began.

  • Transfer — your team takes operation, with a paired handover period behind them
  • Managed support — we retain incident response and enhancement against agreed response targets
  • Retained architecture — your team operates, a principal stays on for architectural decisions and quarterly review

Continuity

No single-person dependency on either side. Every engagement runs with role-level redundancy — principal sponsor, technical lead, engineering pod, QA and platform support — and system context is documented rather than held in one head. We staff for the case where someone leaves, because someone eventually does. We do not publish a roster of individual engineers; you get named accountability at the principal and technical lead level, and continuity guaranteed at the pod level.

Confidentiality

We will sign yours, or send ours the same day you ask. Much of our delivery is under mutual non-disclosure and stays that way permanently — we do not name clients, describe systems or use logos without written permission, and the two named references on this site are named because we asked and they agreed.

Insurance & compliance

DaVinci Development carries professional liability (errors & omissions) and cyber liability insurance. Certificates are available on request and we will name your entity as required by your procurement process.

On formal certification we would rather be precise than impressive: we do not currently hold SOC 2 or ISO 27001. We operate to the control set described on this page, we build inside our clients’ certified environments and to their control frameworks, and we support customer security reviews directly. If your procurement process requires a certified vendor of record, tell us at the diagnostic and we will say plainly whether we can meet it.

Commercial shape

What a typical production engagement looks like.

Illustrative and non-binding, so you do not have to spend a call finding out whether we are the right size for the problem.

Scale

Low six figures and up

Most production implementations begin in the low six figures. Exact pricing follows discovery — we do not quote a number before the diagnostic, because anyone who does is either guessing or pricing in the change orders they expect to bill you for.

Shape

Diagnostic, then staged

Fixed-fee diagnostic first, credited against the build. Then either a monthly dedicated pod or milestone pricing against a scope both sides actually understand, decided after architecture.

Accountability

A principal, by name

One of our principals sponsors your program from diagnostic through stabilization, with a named technical lead accountable for delivery. Neither is a title on a proposal that disappears after signature.

What drives cost

In roughly the order they surprise people:

  • Integrations — how many systems, and whether they have real APIs
  • Data quality — the single most common reason a build takes longer than planned
  • Security and regulatory requirements — review gates, data residency, model risk approval
  • Number of distinct workflows in scope, not the number of screens
  • Model usage — volume, context size and whether inference must stay inside your boundary
  • Uptime and support expectations after launch
  • Migration complexity — legacy data, parallel running, cutover strategy
  • Client-side dependencies — access provisioning, subject-matter expert availability, decision latency

Next step

Start with the diagnostic.

One to three weeks, fixed fee, credited against the build. You keep the assessment whether or not you proceed.

Discuss a program with a principal