Skip to content
UNFLECT

Software company · Web · Systems · Integrations

We buildsoftware thatsolves real business problems.

UNFLECT works with businesses whose problems fall between the platforms that already exist. We understand the operation first, then build the software that fixes it.

Our process

Discover → Define → Build → Deploy → Evolve

  1. 01Problem

    A real business problem that off-the-shelf software does not solve.

  2. 02Solution

    Defined against how the business actually works, not how a template assumes it does.

  3. 03Software

    Built, deployed, documented and handed over — yours to own.

  4. 04Outcome

    The operation measurably changes. That is the point.

The problem

Most business problems fall between the platforms that already exist.

Off-the-shelf software is genuinely good at the problems it was built to solve. Where your business is different, the gap has to be closed deliberately.

How we work

Sound familiar?

  • The software was bought for a different business and never quite fitted.
  • Work that matters is done in spreadsheets, and nobody fully trusts them.
  • The same information is entered in three places, so the copies disagree.
  • Customers have to phone because the product cannot handle what they need.
  • The internal tool only makes sense to the two people who built it.
  • Growth means more manual work, which means more errors, which means rework.
  • Reporting is assembled by hand, so decisions use last week's picture.
  • Every vendor says it will integrate, and none of them finished.

What we do about it

  1. 01

    Understood first

    We map how the business actually works, including the workarounds nobody wrote down. No solution is proposed until the problem is understood.

  2. 02

    Defined precisely

    Requirements, scope, boundaries, milestones and acceptance criteria are written down. Scope becomes a promise rather than an impression.

  3. 03

    Built to be owned

    Delivered as production software with source, documentation and credentials handed over. Maintainable by your team, not dependent on ours.

Sometimes the honest answer is that a process should change rather than more software should be bought. We will say so.

What we build

One offering, three connected disciplines.

Web, systems and integrations are usually sold as separate things by separate companies. They are not separate problems. A business is one system, and these are the three ways it fails.

  • 01

    Web

    Software experiences delivered through the web.

    Covers

    • Business websites built to a clear commercial purpose
    • E-commerce platforms with the checkout and catalogue behaviour your customers expect
    • Customer portals with authenticated, self-service access
    • Web applications for operational and team workflows

    Explore Web

  • 02

    Systems

    Software that helps businesses operate.

    Covers

    • Internal business tools for recurring operational work
    • Dashboards that report from real data, not manual entry
    • Admin platforms for managing users, content and configuration
    • Management systems for workflows, approvals, stock, scheduling or case handling

    Explore Systems

  • 03

    Integrations

    Connecting the systems your business already depends on.

    Covers

    • APIs and webhooks between your systems and ours
    • Payment system integration — checkout, subscriptions, reconciliation
    • CRM integration so sales and operations work from the same record
    • Third-party service connectivity for the tools you already pay for

    Explore Integrations

Most projects draw on more than one of these. A customer portal is web software; the order data behind it is a system; the payment provider is an integration. We scope the combination, not the department.

Selected work

We understand the problem before writing the software.

Our case study structure is published below so you can see exactly how we document a project. Published work will appear here.

See our work

Placeholder content. The structure below shows how we document a project. These are not client engagements, and no results are claimed. Selected real work will be published here with client-approved detail.

  • 02Status: Illustrative example

    Operations · PLACEHOLDER

    Placeholder — Consolidating operations across scattered systems

    Structure for a case study about replacing spreadsheet-driven operations with a single internal system.

    Service
    Systems
    Problem
    Operational work is spread across spreadsheets, inboxes and legacy tools. The same information is entered more than once, nobody trusts the numbers, and reporting is a manual exercise every month.

    Read the breakdown

  • 01Status: Illustrative example

    Commerce · PLACEHOLDER

    Placeholder — Replacing a limited commerce platform with a purpose-built storefront

    Structure for a case study about rebuilding e-commerce around a product range the existing platform could not support.

    Service
    Web
    Problem
    The current storefront cannot represent how products are actually priced, bundled or sold. Customers cannot complete their order without contacting the team, and staff absorb the gap manually.

    Read the breakdown

  • 03Status: Illustrative example

    Cross-platform · PLACEHOLDER

    Placeholder — Removing manual data entry between systems

    Structure for a case study about connecting existing software so information stops being rekeyed by hand.

    Service
    Integrations
    Problem
    Customer, order and payment data lives in separate systems that do not communicate. The same records are copied between them by hand, so they drift apart and reconciliation becomes an argument.

    Read the breakdown

How we work

A structured path from problem to running software.

Five stages, every project. The sequence does not change; what happens inside each stage is defined with you.

Full process
  1. 01DiscoverWe understand the business, the actual problem and the constraints before anything is built.
  2. 02DefineWe turn the problem into requirements, scope, architecture, milestones and acceptance criteria.
  3. 03BuildDesign, development, integration, testing and client review, in visible increments.
  4. 04DeployProduction release, configuration, testing, documentation and a proper handover.
  5. 05EvolveMaintenance, improvement and new development once the software is live and in use.
Visible progress
You see working software during the build, not only at the end.
Scope is a promise
What is agreed is what gets built. Anything else is a change request.
Defined done
Each part of the project has agreed acceptance criteria.
You own it
Code, accounts, infrastructure and documentation belong to the client.

Security

Controls follow the risk, not a template.

Security is decided during definition, when the cheapest decisions are still available. Every project is assessed and placed at one of three levels.

  • Level 1

    Standard

    Normal business applications and lower-risk projects.

    Sound defaults applied consistently. Appropriate where the software handles ordinary business data and the consequence of compromise is bounded.

    Practices

    • Least-privilege access, including for our own team
    • Managed authentication with multi-factor support where accounts are exposed
    • Encrypted data in transit and at rest
    • Secure development practices throughout the build
    • Dependency and patch management
    • Functional and integration testing before release
    • Input validation and output encoding
    • Backups and a documented restore position
    • Logging proportionate to the system

  • Level 2

    Enhanced

    Projects requiring stronger security controls and additional practices.

    Adds review, segregation and evidence on top of Standard. Appropriate where the system holds more sensitive data, supports more users, or is business-critical.

    Practices

    • Everything in Level 1, with each control evidenced and reviewed
    • Formal threat consideration as part of the Define stage
    • Stricter access control, review and periodic re-validation
    • Additional automated and manual security testing before release
    • Segregation of environments: development, staging and production
    • Detailed audit logging of sensitive actions
    • Documented incident response and communication process
    • Hardened infrastructure configuration and secrets management
    • Recovery objectives agreed and tested, not just configured
    • Security documented for the handover rather than assumed

  • Level 3

    High security

    Sensitive, high-risk or regulated projects requiring significantly stronger controls and potentially specialist involvement.

    Substantially more demanding. Where data, regulation or consequence justify it, the work involves specialist security input and a longer, more formal process.

    Practices

    • Everything in Levels 1 and 2, at a higher level of assurance
    • Independent specialist security review, including penetration testing where proportionate
    • Formal security requirements derived from a dedicated assessment
    • Approved-by-design architecture with threat modelling per significant component
    • Strict segregation of duties and privileged access controls
    • Enhanced encryption, key management and rotation
    • Continuous vulnerability management of dependencies and infrastructure
    • Formal change control, code review and release authorisation
    • Documented, tested and rehearsed incident response
    • Contractual security responsibilities and handover obligations

Principles we apply throughout

These hold at every level. The level determines how much rigour sits behind them and how much evidence you receive.

Least privilege
Access is granted to the minimum needed for the task, reviewed, and removed when it is no longer needed — including our own.
Controlled access
Authentication and authorisation are designed deliberately, not inherited from a framework default.
Secure development
Security is considered during design and build, not added at the end as a phase.
Appropriate testing
Testing depth follows the risk level, rather than a fixed checklist applied identically to everything.
Responsible data handling
Only the data needed is collected and kept. Client infrastructure and critical third-party accounts remain client-owned where practical.
Security by risk
Controls are chosen per project risk. Higher-risk work gets more; routine work is not over-engineered.

No software can be described as completely secure. We design and test to reduce risk to the level the project warrants, and we do not claim guarantees we cannot evidence. Security is part of the process, not a promise of immunity.

Engagement

Structured projects, predictable terms.

Projects are scoped, phased and paid against agreed milestones. You always know what the next payment is for.

  • 01

    Small projects

    50% upfront · 50% before go-live

    Single-phase delivery. The balance falls due before go-live or handover.

  • 02

    Medium projects

    30–40% upfront · milestone payments

    Paid in defined milestones as agreed work is delivered and accepted.

  • 03

    Large projects

    Paid discovery phase · project-phase payments

    A paid Discovery and Define phase first, so scope is set before build commitments are made.

  • 04

    Recurring work

    Monthly, in advance

    For ongoing maintenance and continuous development.

Exact terms, including IP, liability and warranties, are set out in the commercial documents for each project — not here.

How we use AI

AI assists;
people answer.

We use AI where it genuinely makes the work better or faster. It is a capability inside the engineering, not the positioning of the company. Everything that ships is reviewed, tested and owned by a person.

AI assists

  • Exploring approaches and options during discovery
  • First-pass code, refactoring and boilerplate
  • Drafting documentation and test coverage
  • Repetitive data transformation and migration work

People answer

  • Reviewing every line before it is accepted
  • Testing the behaviour that matters to the business
  • Security decisions and the risk assessment
  • Architecture and the engineering trade-offs
  • Final implementation and standing behind it

Where AI-assisted output would carry more risk than it saves, we do not use it. Automation is a tool choice, not a default.

Why UNFLECT

Software should be built for the problem, not for the portfolio.

We are a software company, not a development agency. That distinction decides what we build, what we refuse, and what we tell clients when the answer is no.

About UNFLECT
  • 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

    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.

  • 04

    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.

Start a project

Tell us what is going wrong in your business.

The first conversation is about the problem, not the technology. If software is not the right answer, we will say so — and if it is, we will tell you what solving it properly involves.

Start a projectSee our work