One AI feature in your product, shipped with your engineers.
For software companies with 10 to 80 engineers. Summaries of long records, drafted replies, triage of what comes in, fields pulled out of documents. We pick the feature with you, decide what the model may see under rules you can show your customers, build it with your engineers in one team, and leave behind the tests, the pipeline and the release rhythm that let them ship the next one. Lead time, how long a ticket takes from start to production, is measured in your own Jira and Git, before and after.
Read the measurement method. It is the lead-time definition every pilot contract uses.
The feature, and what the model is allowed to see
One feature, in one team. Named in the contract, with the data it reads and the data it never sees. Built by your engineers with us, so they can build the next one without us.
Data rules you can publish. Customer details are swapped for placeholders before a model sees them and put back on your side afterwards, the mapping stays on your servers, and the model runs on an endpoint you approve in writing: an EU business endpoint that keeps nothing after the request, or an open model on your own machines. The rules go in your terms and your DPA.
Tested before it ships. A test set from your real cases, with names removed, that the feature has to pass before release and after every model change.
Cost per request, known. The model bill is in your account, with a limit set, and the report says what the feature costs to run per thousand requests.
In your team's workflow too. Review assistance, test generation and ticket triage for your engineers, on the same models, under the same rules.
Making your team able to ship it
A feature that calls a model needs a test suite, a release every week or two, and a team that owns it. The diagnostic says which of these are missing. The pilot includes only those, named in the contract, and the quote says what each one costs, so you are not buying a reorganisation to get a feature.
Team shape. Small teams with product, design, backend, mobile and QA skills together, each owning one part of the product, so fewer tickets cross team lines.
Release rhythm. A release every week or two, with the regression checks automated.
Manual QA to automated tests. We set up the test framework in your pipeline and write the first tests with your engineers. They write the rest and own them, and your QA people move to exploratory testing.
Engineers in product decisions. Engineers join discovery and see the usage of what they ship, so less work comes back from product.
Performance and the cloud bill. Slow endpoints, app start-up, page loads and the hosting cost, measured before and after.
Security posture. Dependency and secret scanning in your pipeline, an access review, and the gaps a customer's security questionnaire or a buyer's diligence would find, fixed in order of risk.
How lead time is measured
The lead-time query, the statuses it counts and the team it covers go into the contract as an appendix before the baseline is pulled. The result is measured over the last 4 weeks of the pilot and reported next to the baseline.
One of your engineers runs the lead-time query, in your Jira, before and after, so the number comes from your systems and your people. We read it with you.
We also report lead time per epic and throughput, so splitting tickets can't pass for speed. Where tickets aren't tagged well, we use Git and pull-request dates, and the report says which numbers are estimates.
How it goes
Two weeks, €6,500
The diagnostic. Where a model fits in your product and your workflow, what data it would touch, a baseline from your Jira and Git, and five changes ranked by what they save. The report is yours either way.
Six to eight weeks, €18–30k
A pilot with one team. The feature ships behind your release, with its test set. Half when we start. The other half once the feature and the changes named in the contract have run for two weeks with your people. Lead time is reported before and after, and nothing is paid on it.
Then
Handover. Playbooks and scripts your people re-run. You keep everything, and you can stop after any step.
Mostly in writing, with a call when it helps
A pilot is 60 to 80 hours of ours over six to eight weeks, split by name in the contract. Your engineers do the hands-on work with us, so the skills stay when we leave: usually the team lead for 2 h a week and one engineer one day a week. If one of us is away for more than a week, the other takes over.
For your security team
We read your Jira, Git and CI with read-only access, through your own accounts, and the scripts write their output into your storage. The feature, and any review or test tools, run only on models you approve in writing, on EU business endpoints that keep nothing after the request, or on your own servers. Customer details in tickets are swapped for placeholders before a model sees them. All access ends on handover day, confirmed in writing. Security summary
Selling the company in the next two years? Start with the R&D baseline
Tell us what the feature is, or where the work waits.
A few lines are enough: what you'd like a model to do for your customers, how many engineers you have, and how often you release. On the call we'll tell you what the diagnostic would look at first, and whether it's worth doing.