How does a project with you start?
With a 20-minute technical call, no strings attached: we work out the problem you're facing and tell you straight away which of the seven packages covers it, or whether it needs clarifying first. If the package fits, you receive a written proposal with the scope defined, the price and the delivery date, ready to sign.
Are the published prices final?
For audits and the PoC, yes: the scope is fixed and so is the price, agreed before the work starts. For refactoring, feature development and AI work we publish the starting threshold instead, because the final cost depends on how wide a scope we agree on together.
Do you work remotely?
Yes, we work entirely remotely and don't offer an on-site option: we don't travel to a client's office, and we don't ask anyone to work from ours. We collaborate with companies in Italy and abroad, with no office or geographic constraints. The registered office listed in the site footer is a company-registry fact, not a place where any work actually happens.
Do you offer support after the release?
Yes. Every package can include maintenance, monitoring and evolution of the software after delivery: we don't disappear on release day. Software needs managing over time because the data, the traffic and the dependencies around it keep changing, not writing once and leaving it to run on its own. We talk about it at the end of each engagement, based on what's actually needed.
Do you also work on existing systems?
Yes. Most of our work starts from software that already exists, not from a blank page: we read it with an audit, secure it, evolve it with new features, or put it right with a targeted refactor, without unnecessary rewrites. The code you already have in production stays the starting point, not an obstacle to throw away and rebuild from zero.
What kind of contract do you work under?
Every package starts from a scope written down before we sign: what is in, what is out, what we deliver and by when. Price and date are agreed upfront, inside that scope, and don't change once work has started. If something outside the scope shows up while we work, we flag it when it happens, with a separate estimate: it never lands as a surprise line at delivery. That holds on every package, not just some.
Who owns the code you write?
Yours, whenever a package produces code: we don't retain rights over what we write, and being able to use it later never depends on keeping a contract with us running. Depending on the package, the code either lands straight in your own repository as we go, or we hand over the source at delivery: nothing we write stays accessible only by going through us. What stays ours is the technical responsibility for that code, not a claim over it.
Who actually works on the project?
Not two fixed developers who work every project: we assemble the team around the project, drawing on our network of senior developers, and the work decides the size, not an org chart set in advance. Whatever composition we choose, technical responsibility for that code stays with CODEPRESS, not with whoever happened to write it that day: that responsibility is what you're buying alongside the package, not a specific name pencilled into a calendar.
In which phases of the work do you use AI?
In all of them: from analysis to development, from release to team coordination. We use it where it removes repetitive work without removing control, for example to condense scattered inputs, write code and tests or draft release notes. Where we use it and where we don't is written into the scope, before we start.
Who is responsible for code written with the help of AI?
We are. AI is a tool and our engineers are the ones governing it: what it produces goes through review and tests like any other change, and no finding enters a report or a release without a person having checked it. Technical responsibility stays with CODEPRESS, whatever tool was used to write that code.
Can I add AI to my product without rewriting it?
It depends on the system, but often yes: an AI feature plugs into what you already have, without rewriting it. We know how to integrate it and how to govern it: it starts from a single measurable use case, with a pilot, and at the end you know whether it holds up on your process before extending it. If the case is about your documentation, the starting point is the enterprise RAG package.
