The client is inside the process, not outside it.
Every task we undertake passes through you three times: when we decide what to do, when we agree what it will cost, and when it is ready for you to see. In between, there is nothing you need to do — but nothing arrives as a surprise.
What follows is the method we apply to every project.
The unit of work
Before writing code,
we write down what it must do.
Every task has a brief, and that brief covers six things: what is being built, the business context it belongs to, the conditions it must meet to be considered complete, what is out of scope, which technical aspects matter, and what the person testing it needs to know.
The part that is usually missing elsewhere is the second one. A developer who knows why something is needed makes different technical decisions from one who only knows what was requested — and makes better ones.
Decisions
AI fills the gaps. The process makes them visible.
With AI, writing down first what the software must do matters even more. If you ask it to do A, and doing A means deciding X, Y and Z, AI makes those decisions on its own. Usually in a plausible way, which is exactly why you do not notice: you may only realise once you are already in production.
For a decision to stay in a person's hands, it first has to be seen. That is what the process is for: the brief for every task, a technical design validated by a second engineer, the tests. That way choices surface while changing them still costs little, and we make them together with you.
The workflow
Eight steps. You own three of them.
01
Us
We describe the task
02
You
You approve the content
03
Us
We design the technical solution
04
Us
A second engineer validates the design
05
You
You approve timing and cost
06
Us
We build it
07
Us
A second engineer reviews and tests the code
08
You
You test it where you can see it running
The rhythm
Two weeks at a time.
Work is organised into two-week cycles, filled up to the team's available capacity. You can see which tasks belong to each cycle and work out when something will be ready from there — not at the end of the month and not only when you ask: it is the same view we use.
Every task has an estimated time and a time spent. The difference between the two shows what remains and whether it still fits in the cycle.
When something is not completed in a cycle, it moves to the next one carrying only the remaining effort. It is not counted again from scratch.
- Estimated
- Spent
- Remainder carried into the next cycle
- Free capacity
Who checks
Nobody releases their own code.
What we sell is people's time, and people are different: the method is there so that the quality of the work does not depend on who happens to be doing it. That is why every change passes through a second engineer before it goes anywhere. This is not a formality: the reviewer reads the code, tests it in a separate environment, and sends the work back if anything is wrong.
With AI, code arrives fast and in large quantities. Nobody can review thousands of lines at once with real attention. So we work in small steps: each one has its own review and is short enough to actually be read. Responsibility for what goes into production is something we share with you.
Before the review even starts, every change goes through the CI/CD pipeline: automated tests that check the software still does what it should, test coverage checks, security checks on the code. If a check fails, the change stops there. With AI it is now much easier to cover the whole codebase with tests. But someone has to ask for it: AI does not do it on its own initiative, just as a developer left alone would not. In our process it is a planned step.
01
Local
where development happens
02
Dev
internal testing
03
Staging
where you test
04
Production
your users
Every transition is automated — no commands typed by hand
There are four environments — where development happens, where we test internally, where you test, and production. Each has an automated deployment pipeline: nobody types commands into a server to push a release live.
Releases have a fixed day and time, with one person coordinating them. We do not release on Friday evening simply because something happens to be ready.
How we communicate
Every two weeks, with the people working on your product.
There is a fixed alignment with you every two weeks and an internal one every week. Decisions do not stay in the call: they are written into the task they belong to, so six months later you can still find out why something was done that way.
If something does not work, there is a structured way to report it: what you did, what you expected, what happened, where, and when. It sounds like bureaucracy, but it is the opposite — the difference between solving a problem in an hour and spending three days going back and forth just to understand it.
- What you did
- I exported the March orders to CSV.
- What you expected
- A file with every order of the month.
- What happened
- The file only has the orders up to the 15th.
- Where
- Back office · Orders
- When
- 3 Apr, 10:42
- User
- Mario Rossi · administrator
- Environment
- prodstgdev
Knowledge should not live in one person's head.
One of the most common risks in external engagements is dependence on a key person. When that person leaves, the context leaves with them.
At Astrorei, work is documented and distributed across the team: code, architectural decisions, access, and project materials. The accumulated know-how remains a stable asset for the client, not an operational risk.
The collaboration continues because it creates value, not because context is stuck somewhere.