The scope is written first
What is in, what is out, what we deliver and by when. If we cannot write it down we have not understood the problem: we go back to analysis instead of starting anyway.
italian software house
Software engineering, with a closed scope.
Engagements with a boundary written before we start: what is in, what is out, what we deliver and at what price.
01: Experience10+ years
02: Engagements6 packages
03: Expertise7 technical areas
04: Delivery100% remote
Engagements with a price and a date
No open-ended consulting billed by the day. Every engagement starts from a precise question and ends with something you can read, use or ship.
- understand
API audit
The APIs you expose to your clients, your partners or your own frontend, read the way whoever has to integrate with them would read them, or whoever wants to break in.
- understand
Code audit
The software you already run in production, looked at by people who could also fix it. No questionnaire to fill in.
- put right
Targeted refactoring, backend or frontend
Not a rewrite of the system: one bounded area that today slows down every change, put right without stopping the rest.
- build
Feature development
A feature your team has no time or no skill for right now, taken from analysis all the way to production.
- decide
PoC in four weeks
When the question is not how much it costs to build, but whether it works at all. A prototype is there to answer, not to impress.
- AI in your company
Enterprise RAG, assistants and onboarding
Our own framework: company documentation becomes a single library, served to three different audiences without duplicating it.
- getting found
A showcase site built to be found
For sole traders and small businesses with no presence online: the site built and published by us, optimised for search engines and for AI assistants.
method
How we work
The method is the only thing a client can check before signing. Ours comes down to seven rules, and they hold on every package.
Price agreed upfront, not tallied at the end
You know the cost before we start. If work outside the scope shows up we say so when it shows up, with a separate estimate: it does not turn up on an invoice at the end of the month.
Tests first, changes after
On code we did not write we start with characterisation tests: they pin down current behaviour, so a refactor that breaks something shows it the same day.
Small, reversible releases
No big-bang delivery after months of silence. Every step lands in an environment you can look at, and can be rolled back without an emergency meeting.
No rewrites out of habit
Rewriting from scratch is the most expensive and riskiest answer. We propose it only when we can show, with numbers, that it costs less than evolving what exists.
Every finding verified by hand
Automated tools flag a lot and are often wrong. What ends up in our reports has been looked at by a person: a padded report helps nobody decide.
Technical responsibility stays with us
We assemble the team around the project from our network of senior developers. Whatever its composition, that code is ours to answer for.
What we don't do
- We don't run penetration tests against live systemsOur audits read code, dependencies and configuration.
- We don't issue certifications or compliance stampsWe are not a certification body.
- We don't sell junior days by the headcountIf the work doesn't need seniority, another supplier suits you better.
- We don't take projects whose scope cannot be written downFirst we draw the boundary, then we quote.
expertise
Technical expertise
- Frontend
- Backend
- Database
- Cloud & infrastructure
- Testing & Quality Assurance
- AI integration
- Blockchain integration
Frequently asked questions
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.