We look at the process
We sit with the people doing the work, not only with whoever describes it. What actually happens almost always differs from the written procedure.
For Companies
Software shaped around your actual process
Custom applications, integrations between the systems you already use, and automation that takes repetitive work out of people's days. Built so anyone can take them over, not so you depend on us.
The situation
The systems exist. The problem is they do not talk.
The pattern in a company that has grown is almost always the same. There is an invoicing system, a sales platform, a spreadsheet maintained by one person, a stock application bought seven years ago, and a shared folder holding whatever did not fit in the others.
Each of them works. What does not work is the space between them, and that space is covered by people copying data from one place to another. It is invisible work in any report, but it consumes hours every day, produces errors you discover months later, and creates a dangerous dependence on the person who knows how it is done.
Usually you do not need to replace anything. You need the existing systems to communicate and the repetitive steps to disappear.
What we cover
Four types of work
Custom software
Applications built around your process, when nothing on the market covers it. We start with the question of whether it is worth building at all, because sometimes the honest answer is no.
See the detailIntegrations and APIs
We connect the systems that today communicate by manual export. Plus your own interfaces for cases where partners need access to data, with proper authentication, rate limiting and versioning.
See the detailAutomation
The steps people perform daily because nobody has got round to automating them. We start by measuring what each one actually costs, then automate in that order.
See the detailSoftware maintenance
For applications already in production, ours or inherited from somebody else. Dependency updates, security fixes, monitoring and a person who answers when something breaks.
See the detail
How we work
Frequent deliveries, not a year of silence
The biggest risk in a software project is not technical. It is building something for months that does not match reality, and that is only discovered by putting the work in people's hands early.
We decide whether to build
We compare against what exists on the market, licences and hidden costs included. If an existing solution is better, we say so, even if it means a smaller project for us.
Architecture and estimate
What gets built, on what, how it connects to the rest, what risks exist. You get a document another supplier could read and evaluate.
First usable version
The main case, working, in people's hands. From there every addition is decided on real feedback rather than assumptions.
Short delivery intervals
Something verifiable every two weeks. You see progress continuously and can change direction without losing months of work.
Handover with training
Technical documentation, user documentation, sessions with your team and a period in which we stay close.
Standards
What we deliver besides code
The difference between a project that lasts and one that becomes somebody else's problem in two years lies almost entirely in the items below.
| Deliverable | What it contains | Why it matters |
|---|---|---|
| Architecture documentation | Components, data flows, technical decisions and the reason for each | In two years, the question "why was it done this way" has to have a written answer, not one that left with a former employee |
| Access control | Roles, permissions, two step authentication for privileged accounts | The first requirement of any audit, and the cheapest thing to do at the start |
| Audit logs | Who, what, when, on the data that matters | Without them you cannot answer a complaint, nor an auditor |
| Personal data handling | Minimisation, defined retention, export and deletion on request | GDPR designed in from the start costs a fraction of GDPR added later |
| Backup and recovery | Automatic copies, tested by actual restoration, with measured recovery time | An untested backup is an assumption. You need to know the duration before the incident, not during it |
| Monitoring and alerts | Availability, errors, performance, with defined thresholds | You find out from the system, not from an unhappy customer |
| Automated testing | Coverage on critical flows, run on every change | It makes changing the code a year from now possible without fear of breaking something else |
| Reproducible infrastructure | Environment described in code, identical between staging and production | It eliminates the class of problems that only appear in production |
About certifications
We are not a certification body and we will never tell you your system is ISO certified. What we do is deliver with the evidence an auditor asks for anyway: change records, access control, logs, verified backups and a documented recovery procedure. If your organisation goes through such a process, the software will not be the part that holds you up.
Honesty
When we tell you not to build
A custom software project costs a lot and, more importantly, creates a permanent obligation: once built, somebody has to maintain it indefinitely. That is why the first question we ask is not how to build it, but whether it should be built.
If your process looks like everyone else's in the industry, an existing platform properly configured costs you less and is safer. If the requirement comes from a single person and nobody else feels it, it is probably not a systems problem. If the process changes every quarter, anything we build will be out of date before launch, and then the process is stabilised first.
We say this before the contract, not after. A project that should not have been built does not become a success however well you execute it.
Frequently asked questions
Why custom software rather than an off the shelf solution?
Most of the time we actually recommend the off the shelf solution, and if that is the conclusion we tell you before signing anything. Building makes sense when your process is itself the competitive advantage, when per user licence costs have overtaken the cost of development, or when no product on the market covers a requirement the business depends on. Otherwise an existing platform, properly configured, is cheaper and safer.
What happens if we replace you with somebody else?
You leave with everything: code, documentation, infrastructure, keys. The code is written so it can be taken over, not so it keeps you tied. A supplier whose continuity rests on nobody else understanding the code is not a partner, it is a risk.
How do you handle security and compliance?
We are not a certification body and we will not claim to certify you. What we do is deliver with the evidence an auditor asks for: role based access control, audit logs, change records, backups verified by restoring them, a documented recovery procedure, and personal data handled to GDPR by construction rather than bolted on at the end.
How long does a project take?
The first working version, the one that solves the main case, is normally delivered in two to four months. We prefer to put something usable in people's hands early and build on top, rather than disappear for a year and deliver something that no longer matches reality.
Do you work with our internal team?
Yes, and it is in fact the ideal situation. We can take on a component, extend the team, or build something from scratch and hand it over with training. What we ask for in every case is one person on your side who can decide, otherwise the project stalls waiting for an approval.
Describe the problem, not the solution
Tell us what is not working in your process. What gets built, and whether it gets built, we decide together once we understand.