How a project runs
Five stages, with a fixed price agreed before each phase begins.
What this means in practice
We absorb our own estimating errors. A fixed price holds even when a phase takes longer than we expected.
Declined changes cost nothing. The phase continues as scoped and the request can be picked up later or dropped entirely.
Short phases limit exposure. If a project stops after phase two, you have working software rather than a partial build.
We recommend buying where it makes sense. If an existing product covers most of what you need, building is usually the wrong answer and we will say so.
Frequently asked
What happens if we want a change mid-phase?
We price it in writing and send it. Nothing is built until you approve it. If you decline, the phase continues exactly as scoped.
What if a phase takes you longer than expected?
The fixed price stands. Absorbing our own estimating errors is our side of the arrangement.
Why short phases?
Because a two month phase carries far less risk than an eight month one, and each ends with software you can actually use.
Who owns the code?
You do, in your own repository from the first week, with hosting and licences in your name.
Do you support systems you did not build?
Yes, at the same rates, on thirty day rolling terms.
What technology do you use?
Mainstream tools your team can hire for locally. An unusual framework is a liability for a client in this region.
Do you work in Spanish?
Yes. Most of our team works in both languages, and bilingual interfaces are built in rather than added later.
Would you tell us not to build something?
Yes, where an existing product would cover most of the requirement. It happens regularly and it saves clients a great deal.