Key takeaways
- Delivery risk should sit with the people doing the delivery
- A signed specification keeps acceptance objective
- It only works with discipline on both sides
The usual arrangement
In a typical software contract, you pay an advance, then pay monthly as time passes, and hope the result matches what you had in mind. If it does not, the money is already gone, and the conversation turns to change requests and who said what in which meeting.
Our arrangement
Under O2E, our output oriented model, work is arranged in fixed capacity blocks. Each block includes senior review, QA and project management at no extra cost. You review the output and pay after you accept it. There is no advance.
What keeps it fair
Everything rests on one document: a signed technical specification. It comes out of a simple chain: business discovery, then business requirements, then the specification. The specification decides acceptance. "Done" means the same thing to both sides, so acceptance does not depend on anyone's mood that week.
Why we do it
- It forces us to understand the work properly before we start. Vague scope is our risk, so we do not accept it.
- It holds us to a clear quality standard, because we are paid only for work that passes your review.
- It makes it easier for a new client to try us. You are not betting an advance on a team you have never worked with.
What it asks of you
Clear requirements, reviews done on time, and changes agreed in writing. If a review sits for three weeks, everyone loses momentum. When both sides keep to this, the model runs smoothly, and it leaves a clean paper trail from the first call to the final invoice.
Have a question about this guide? Write to us or ask Colony, our AI guide.