Scope agreed phase by phase. The code is yours, and the repository goes into your company’s name.
Here is the method, phase by phase, with what you receive at each one. The person who runs the diagnostic is the person who writes the code. You do not talk to a salesperson and then get handed to somebody else. The process below is the same for a single-shop system and for an ERP across three branches. What changes is the size of the scope.
Every phase ends with a deliverable that exists as a document or as a running system. If a phase is over and you are not holding anything, it is not over.
Deliverable: a written summary of your operation and the problem, in your inbox.
A conversation. You show how the operation runs today: the spreadsheet, the improvised app, the notebook, the WhatsApp group. We ask where data gets retyped, where the team loses time and what breaks when someone is off. At the end we say whether it can be solved, and if the job is not for us, we say that too. Who takes part: you and whoever runs the process every day. That person usually knows the problem better than the owner does.
Deliverable: the Blueprint document, with scope item by item, what is excluded, the technical design and the figure for what is written there.
This is the document that defines what you are buying. The Blueprint lists every screen and every rule that is included, and also what is excluded, the part almost nobody writes down and that later turns into an argument. It carries the technical design (database, integrations, what has to keep working without internet), the architecture decisions with the reason for each, and the figure for exactly what is written there, with the rule for revising it when the scope changes. Nothing is built before you approve that document. If the Blueprint shows the project does not pay for itself, you walk away with a useful document and no half-built system. Who takes part: we write it, you read it and sign it off.
Deliverable: at the end of every cycle, a working version in a test environment, with your own login.
No disappearing for months and returning with a finished system. Each cycle delivers a slice that works end to end and closes with a live demo: we open the screen, you use it, your team points out what is wrong while changing it is still cheap. During the cycle you can see the task list, what is done, what is in progress and what moved to the next one. Who takes part: you and the person on your team who will use the system the most.
Deliverable: a test report and the security checklist applied, item by item.
Before anything goes live, the paths that stop the operation are tested automatically: sign-in, orders, price calculation, payment, cashing up. Those tests run again on every version, so a fix at one end does not silently break the other. The security work follows a written checklist we apply to every project: access control revalidated on each request, login attempts limited per e-mail and per IP address, personal data encrypted at rest, and a mandatory secret in production. Who takes part: we run it, you receive the report.
Deliverable: the system in production, training with the people who will operate it, and a short manual for daily use.
A system the team cannot use is back in a spreadsheet within a fortnight. So go-live includes training with the people who operate it, in their language, plus a short manual, the length a team will actually read. We stay close through the first round of real use, which is when the questions no meeting predicts finally show up. Who takes part: the whole team that will use the system.
Deliverable: a direct line to the people who built it and a version log, what changed, when and why.
After go-live the system carries on living: the law changes, a supplier changes an API, the operation grows. You talk directly to the people who built it, on WhatsApp or by e-mail. Every fix and every new feature goes into a logged release, so six months later you can look back and know exactly what changed. One of the point-of-sale systems we maintain has had 15 releases published. That is what it looks like when the client actually keeps using the system.
H&I is a small team, and that is precisely why the method is strict.
A big team hides mistakes behind meetings. A small team has nowhere to hide them, and what protects the work is method: nothing lands without review, nothing goes live without tests, and every technical decision is written down in your company’s repository.
Every piece of code goes through a dedicated review before it becomes part of the system: correctness, security, and whether something that already exists does the job. That review runs through separate roles, architecture, QA, security, and one role whose only job is to try to break what has just been written.
Not everything needs an automated test. What stops the operation does: sign-in, pricing, orders, payment, cashing up. Those paths are driven by a browser robot on every release. That is what stops a tweak to stock control from taking down the till with nobody noticing until Saturday night.
Development, staging and production are separate databases, with production isolated from the rest. You test in staging, with fake data, and approve. Only then does the release go to production. Nobody edits the environment where your customers live.
Every architecture decision becomes a short file: what the problem was, what the options were, what was chosen, why, and on what date. Six months later, when somebody asks why stock is calculated that way, the answer is written in your company’s repository.
Every project goes through the same written security checklist before it ships, and anything left out is recorded with the reason. What is implemented, by name and in detail, is on the technology page.
We use AI to speed up what is repetitive, always inside the rules above: review, tests and a logged decision. If the answer to "why is it like this?" is "the AI did it", the work is not finished. The full limit is written out on the technology page.
The code is yours for good: no usage licence, no rental, no expiry date.
Plenty of people find out too late that they paid for a system and received only the right to use it, and that changing supplier means starting from scratch. That is not how this works, and it is in the contract, not only on this page.
The source code sits in a repository transferred to your company’s account at go-live, or earlier if you ask. Not a zip file sent by e-mail: the entire history, commit by commit, with the decision records alongside it.
Domain, database, integration keys and payment gateway are created in your company’s name, on your card, with you as the owner; we come in as collaborators and you can remove that access at any moment. The server is the only piece that may be ours, when you would rather not manage a machine, and in that case the contract states whose it is and what happens on exit.
Along with the repository comes the documentation for whoever takes over: how to run the project from zero, which environment variables exist, how the database is migrated, how a release is published, the security checklist and the decision records. The test is simple: if we vanish tomorrow, someone else brings everything up by following the document. If that is not true, the documentation is not finished.
Next.js, TypeScript, PostgreSQL, Docker. No framework of our own invention, no platform only we know how to run, no compulsory monthly fee to keep using what you have already paid for. Any competent developer can carry on from where we stopped.
If the project is interrupted, for any reason and from either side, you keep everything built up to the last invoice paid: in the repository, either working or documented exactly as it stands. There is no delivery that only becomes yours at the end.
What belongs to your business never becomes a template for the next client: pricing rules, spreadsheets, data, internal process. We sign an NDA without argument. What we reuse between projects is our own infrastructure tooling and the security checklist, never your business rules.
The libraries used carry permissive licences and are listed in the repository, with the version pinned. There is no component of ours with an expiring licence, and no piece that demands a future payment for the system to keep running.
If one day you want a different supplier, we hand the project over to whoever comes next and answer their questions during the transition. No holding data hostage, no withheld passwords, no going quiet on the phone. A supplier who needs to trap you is a supplier who knows it would not be chosen again.
It will change. That is the right question to ask before signing.
No software project ends exactly as it was drawn. Anyone who promises otherwise is selling. The difference between a calm project and a nightmare is what was agreed for the moment things change. The general rule here is one line: nothing slips in quietly and turns up on the invoice.
Did it come out different from what the Blueprint says? It goes into the cycle and costs nothing extra. Our misunderstanding is our cost.
Anything delivered that does not work as agreed, we fix, with no argument about who pays.
A feature turns up that was not in the Blueprint? We tell you what it costs and what it pushes back in the delivery queue. You answer yes or no in writing, an e-mail is enough. Only then do we start.
Some changes are not "one more field on the screen": they change the design of the system. When that happens we stop, revise the Blueprint and decide together. A difficult conversation now costs less than the wrong delivery later.
If it becomes clear along the way that some part is not worth what it costs, we say so and propose dropping it. Scope that comes out brings the figure down. We have no interest in selling you a screen your team will never open.
Three that come up in almost every first conversation.
The honest number only exists after the Blueprint, because before that any date is a guess. What we can tell you now is the shape of it: we work in short cycles and, at the end of each one, there is a working slice your team uses in a test environment. You are not left for months with nothing to see, and the first useful delivery does not wait for the whole project to finish.
All the better. In the diagnostic we look at what already exists and tell you what can be kept, what can be integrated and what has to be rebuilt, replacing everything at once is rarely the cheapest option, and we say so when that is the case. One caveat: taking over code written by somebody else goes through a paid audit first. Without reading what is there, any date we gave you would be a guess.
It is the most common risk and the one that sinks most projects, more than any technical decision. That is why the people who run the process take part from the diagnostic onwards, see every demo while changing their minds is still cheap, and are trained at go-live in everyday language. A system the team did not help design is back in a spreadsheet within a fortnight, and at that point the problem was not the software.
A 30-minute diagnostic, free and with no obligation: you leave with a written summary of your problem, and it is yours even if we never work together. Bring what your operation runs on today: the spreadsheet, the improvised app, the paperwork, the WhatsApp group.
Coverage
All of Brazil, remotely. Based in São Sebastião: on the northern coast and in the Paraíba Valley, in person when it makes a difference. International projects out of London.
