About
UNFLECT exists to solve business problems through thoughtfully built software.
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.
In one line
We are not interested in shipping the most software. We are interested in the software solving the actual problem.
- Offering
- Web · Systems · Integrations
- Process
- Discover → Define → Build → Deploy → Evolve
- Philosophy
- Solve the problem first
- AI
- AI assists; people answer
Principles
Eight commitments we actually operate by.
Not values on a wall. Each of these changes what we do, what we refuse, and what we tell a client when the honest answer is inconvenient.
- 01
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.
- 02
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.
- 03
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.
- 04
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.
- 05
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.
- 06
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.
- 07
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.
- 08
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.
- We use AI for
- Exploring approaches, first-pass code, refactoring, documentation, test coverage and repetitive data work — where it genuinely helps.
- People remain accountable for
- Reviewing every line, testing behaviour that matters, security decisions, architecture and final implementation.
- We will not
- Present AI output as verified, automate a decision a person should own, or use it where the risk exceeds the saving.
- Why it matters to you
- The same person who reviewed the code is the person who answers when something needs explaining six months later.
Delivery and handover
What you own when the project ends.
Software that belongs to somebody else is a dependency, not an asset. Handover is a defined stage with a defined output list.
Handover pack
Delivered at go-live or at the agreed handover point, documented so your team can operate the system without us.
- 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.
Critical accounts stay yours.
Where a critical system is identified early, it stays in client ownership wherever practical. A business should not be unable to reach its own customers, its own payments or its own data because a supplier relationship ended.
We will flag this during discovery if we see it, and it is written into the handover.
- Payment accounts
- Merchant accounts and payment credentials are opened and owned by the client.
- Business accounts
- Domain registration, hosting and business tooling remain client accounts.
- Customer-facing accounts
- Accounts in front of your customers — marketplaces, social, support and communication tools — stay under your control.
- Critical third-party services
- Where a third-party service is critical, it is identified early and kept in client ownership where practical.
Working together
If that sounds like how you want to work, start the conversation.
No pitch deck. Tell us the problem and we will tell you what we would do about it, what it would take, and whether we are the right people for it.