01Principle
Solve the problem first
The technology is a consequence of the problem, not the starting point. If software is not the right answer, we will say so — including when the right answer is to change a process instead.
About
UNFLECT exists to solve business problems through thoughtfully built software — not to ship software for its own sake.
Most software problems are not technology problems. A process has grown past the tools that support it. Two systems hold the same information and neither knows about the other. A platform was bought for a different business and now everybody works around it. Someone has been doing the manual part by hand for so long that it has become invisible.
Off-the-shelf software is genuinely good at the problems it was designed to solve. Where a business is different — in how it sells, how it operates, how it is regulated, or simply in the detail that matters to it — the gap has to be closed deliberately. That is the work UNFLECT does.
We are not interested in shipping the most software. We are interested in the software solving the actual problem, being maintainable after we leave, and being honest about what it does and does not do.
The point
We are interested in useful software that keeps working after we leave.
How we operate
Eight commitments, not eight adjectives.
02Principle
Scope is a promise
What is agreed is what gets built. New requirements are handled transparently as change requests, with the effect on cost and timeline made clear before the work starts.
03Principle
Clarity beats cleverness
Software should be understandable by the people who depend on it. We favour clear, maintainable systems over impressive ones that only the builder can follow.
04Principle
Security starts before code
Risk is assessed during definition, when the cheapest decisions are still available. Controls follow the risk level of the project, not a fixed list applied to everything.
05Principle
AI assists; people answer
We use AI as a development capability where it genuinely helps. A person remains accountable for reviewing output, testing it, securing it and standing behind what ships.
06Principle
We don't make impossible guarantees
No software is unbreakable, no result is certain, and no deadline survives a change in requirements. We are direct about that rather than reassuring and vague.
07Principle
Ship, then support honestly
Delivery is not the end. We hand over properly, then maintain and improve what we built — keeping maintenance and new development clearly separated.
08Principle
Evolve deliberately
Change is treated as a decision with a cost, not an accident. We improve systems on purpose, at a pace the business can absorb.
On AI
AI assists. People answer.
We use AI as an engineering capability where it genuinely improves the work. It is not the positioning of the company, and it is not a substitute for judgement. Someone reviews every line, tests what matters, makes the security decisions and stands behind what ships.
Engagement
Commercially clear. Technically clear.
Small projects
50% upfront · 50% before go-live
Single-phase delivery. The balance falls due before go-live or handover.
Medium projects
30–40% upfront · milestone payments
Paid in defined milestones as agreed work is delivered and accepted.
Large projects
Paid discovery phase · project-phase payments
A paid Discovery and Define phase first, so scope is set before build commitments are made.
Recurring work
Monthly, in advance
For ongoing maintenance and continuous development.
Handover
You should be able to own what we build.
Production application
The live application running in your own environment.
Source repository
Version-controlled source, owned by the client.
Access and credentials
Documented access to the systems needed to operate it.
Setup documentation
How to run, deploy and configure the application.
Architecture information
How the system is structured and why.
Runbook
Operational procedures for routine and incident work.
Dependency information
Third-party services, versions and what they are used for.
Changelog
What changed, when, and why.
Technical documentation
Relevant documentation for future development and handover.