How we work
OFO Development builds software and then keeps it running. That second half shapes everything else — what we agree to, how we build it, and what we are willing to say about it afterwards.
How a project starts
With a conversation about your problem rather than a presentation about us. The first thing worth establishing is whether the thing being asked for is the thing that would actually help, because those are not always the same and it is cheaper to find out before anyone writes code.
If it turns out the work is smaller than expected, we say so. If it turns out the real problem is somewhere else entirely — a process, a vendor, a decision nobody has made — we would rather point at that than quietly build around it.
How work proceeds
Visibly. You get the repository, not a monthly summary of it. Deploys are frequent and boring rather than rare and dramatic, because the alternative concentrates risk into exactly the moments when everyone is already tired.
We write things down: why a decision was made, what was rejected, what would have to change for it to be revisited. Most of the cost of inheriting a codebase is not reading the code, it is reconstructing the reasoning that produced it.
What we do not take on
Work we cannot support afterwards. Projects where scope, deadline and budget are all fixed before anyone has looked at the problem — something has to be able to move, and pretending otherwise just decides in advance that it will be quality.
And anything that would require us to claim more than we can evidence. That applies to what we build for you and to what we say about ourselves.