Tell us the problem, not the solution

It depends on what we are doing, and the difference is not an administrative detail: it is where the incentives come from.

• To build: by project, with a defined scope

  When there is something concrete to deliver, charging for time puts the incentives backwards. We agree the scope and we agree the price.

• For products in continuous change: agile as a service

  Some products never finish because the business keeps changing. There we work in cycles, with priorities reviewed with you.

• To support: by service or in blocks of hours

  Support and evolution have no deliverable to close. What gets agreed there is availability and response level.

What we do not do is charge by the hour for something with a definable deliverable. That is what makes it in nobody’s interest for the project to end.

A product that works, matching the scope we signed, stable on both the user and the server side, with security checks done and documented, and ready to grow without being rebuilt.

Finished is not looking finished. It is working in your reality, not in ours.

A project runs long for three different reasons, and they are not paid for the same way. What almost nobody does is say which of the three it was; we say it.

• We estimated or understood it wrong: we pay

  No argument. That is what the discovery stage is for: the better the diagnosis, the less room this case has.

• You changed what you needed: you pay

  But decided before we build it, never discovered in the invoice. Every change is estimated and approved first.

• Something nobody could have known appeared: we share it

  A legacy system worse than its documentation, a third-party API that changed. Risks of this kind get named at the start, not at the end.

There is also an agreed contingency band that absorbs small things without paperwork. Anything beyond it goes through the change process, in the open.

The first conversation is not charged: half an hour to see whether there is a fit and to give you a first read of the problem. The diagnosis is, because it is work with a deliverable — the map of the problem and the proposed solution.

And if the project goes ahead with us, what you paid for the diagnosis is deducted from the total. You risk nothing, and we do not work for free.

The code we write for you is yours, and it transfers on final payment. What we bring already built — our own components and libraries from earlier projects — is licensed to you to use without limit, but remains ours. Third-party dependencies keep their own licences.

Yes, and without friction. At the close of every project we hand over complete documentation and run the knowledge transfer to whoever you choose.

It is included. It is not an exit service billed separately when you want to leave.

Changes are expected: if halfway through you understand something new about your business, we want to hear it. What we do not do is absorb it silently — and let the project slip without explanation — or invoice it without you having decided.

A change halfway through is not a problem. It appearing on the invoice without you deciding it is.

The Alubyte team. The people who sell to you are the people who build, and alongside them work the specialists of each discipline your project calls for — all trained with us, working to our method, with the Triple E as the standard on every project.

You know from the start who does what. And they are all Alubyte: they were trained with us, they did not come out of an urgent search.