B—01
Custom applications
Software built around an existing workflow rather than a workflow rebuilt around software.
The problem
Your business should not have to work around its software.
Software stops fitting gradually. Nobody decides to run the business on exports and email — it accumulates, one reasonable workaround at a time, until the workarounds are the process.
None of these mean anything is being run badly. They are what happens when a company grows faster than the tools it started with. They are also all fixable, and usually for less than people expect.
How we work
Build. Secure. Improve.
Three disciplines, in that order, and then round again. Most agencies sell the first one. The other two are where software either keeps earning its cost or quietly stops.
Discipline 01
Build the systems your business actually needs.
Most business software is bought, then worked around. We start from how the work is done now — the real sequence, the exceptions, the bits held together by one person who knows — and build the system that fits it.
Discipline 02
Protect the applications, data and access that matter.
Security is decided by hundreds of small choices made while building: what a route checks, where a secret lives, what a support user can see. Doing it at the end means finding out which of those choices were wrong.
Discipline 03
Keep your technology useful long after launch.
The version of your business that exists in twelve months is not the one we build for today. Software that nobody is maintaining does not stay still; it slowly stops matching the company using it.
Capability
What we build, and what we look after.
One team across the whole life of a system — the application itself, the security around it, and the development that continues once it is live.
B—02
Internal tools
Replace the spreadsheets and manual steps currently holding a process together.
B—03
Customer portals
Give people a place to see what they currently have to email you about.
B—04
Integrations
Connect the systems you already pay for so data stops being carried by hand.
B—05
Dashboards
One view of the numbers, built from source instead of assembled every month.
B—06
APIs and backends
The reliable layer underneath — data, rules, and what other systems call.
B—07
Workflow automation
Automate the repetitive steps, in the places where it genuinely earns its place.
B—08
Data migration
Getting years of history out of the spreadsheets and into the system.
S—01
Security
Authentication, permissions, dependencies and monitoring, built in rather than added.
S—05
Audit trails
A record of who changed what, and when — the thing a spreadsheet cannot give you.
I—02
Ongoing development
A monthly rhythm of fixes, features and updates instead of a rebuild every few years.
I—04
Infrastructure and hosting
Running the environment underneath it, in accounts you own and can remove us from.
What this looks like
Concretely, what could we build for you?
The same underlying capability shows up differently in every sector. These are the shapes of system we most often end up building — described as scopes, so you can judge whether yours is one of them.
NOTEThese are illustrative project scopes, not delivered client work. Where we have delivered something we can name, it will appear on the work page with the client’s permission and nowhere before that.
Recruitment
Candidate operations platform
Candidates, roles, submissions and stages in one place, replacing a CRM used sideways plus three spreadsheets.
Client portal
Clients see shortlists, feedback and progress without a consultant assembling an email.
Placement and margin reporting
Fees, margins and consultant performance calculated from source rather than reconciled monthly.
Property
Property and tenancy management
Units, tenancies, documents and key dates, with the renewals nobody wants to miss surfaced ahead of time.
Tenant portal
Maintenance requests, documents and payment history — the three things that generate most inbound calls.
Maintenance workflow
A request from report to contractor to sign-off, with a record of what happened and when.
Professional services
Client portal
Documents, requests, approvals and status, replacing an email thread nobody can find.
Engagement and project tracking
Work, time, stage and profitability per client, visible while the job is running rather than after it.
Document workflow
Generation, review, signature and filing as one path instead of four tools.
Operations and logistics
Operations dashboard
What is happening now, what is late, and what needs a decision today.
Order and job workflow
From enquiry through scheduling to completion, with the exceptions built in rather than handled by phone.
System integrations
The accounts package, the ordering system and the customer-facing side sharing one set of facts.
Not on this list? The sector matters much less than the shape of the problem. If your business runs on records, stages, documents and people who need different views of the same thing, it is the same kind of build.
Process
How a project actually runs.
Six stages. The first two are where most of the value is decided, and they happen before anyone writes code.
Understand
The business, the current systems, the workflows and where they hurt.
Design
Decide what the right solution is before development starts.
Build
Develop the application, with working software to look at throughout.
Secure
Review access, authentication, data, dependencies and the real risks.
Launch
Test, migrate, deploy and watch it carefully.
Improve
Keep developing it as the business changes.
Security
Security is not a final checklist.
It is decided by hundreds of small choices made while building — what a route checks, where a secret lives, what a support user can see. A review at the end can only tell you which of those went wrong.
Practised, not promised
- Authentication. Sessions handled properly, passwords stored using a current algorithm, multi-factor available where the data justifies it, and a real password-reset flow rather than an email with a link that never expires.
- Authorisation and permissions. Every route checks what the user is allowed to do, not only every screen. Hiding a button is a user-interface decision; it is not access control.
- Data separation. Where a system serves multiple customers or offices, the boundary between them is enforced in the queries rather than assumed from the interface.
- Secrets and configuration. Keys and credentials live in the deployment environment, never in the codebase, and production credentials are not the same as the ones used to develop.
- Dependency management. The libraries underneath the application are tracked, updated on a schedule, and checked against published vulnerability data — not left where they were on launch day.
- Environment separation. Development, staging and production are genuinely separate, so a test does not touch live data and a mistake in one does not reach the others.
What we will not tell you
That your software will be unbreakable. Nobody can say that honestly, and a supplier who does is telling you how they will handle the day something goes wrong.
- We hold no security certifications. When we do, they will be named here with their scope and expiry.
- We are not a penetration-testing firm. For a formal test we will tell you to commission one independently.
- We do not claim uptime figures for systems we have not run yet.
What we can tell you is exactly what we do, on every project, and let you judge whether that is the standard you want applied to your data.
After launch
Launch isn't the end.
Most businesses do not need software delivered and then abandoned. They need a system that keeps up with them — and someone who is responsible for it when it does not.
- 01
Build
The system gets designed and written.
- 02
Launch
It goes live, with the people who use it ready for it.
- 03
Secure
Access, data and dependencies reviewed against real use.
- 04
Improve
Bugs, friction and the things nobody predicted.
- 05
Expand
The next part of the business it should cover.
And round again — for as long as it is useful
An outsourced technology team, not a finished invoice.
After launch most clients move onto a monthly arrangement. It buys a known amount of engineering time each month, covering maintenance, security updates, monitoring and a steady stream of improvements — and it means the person changing your system already knows it.
It is deliberately not an open-ended retainer with nothing to show for it. Every month has work in it that you agreed to and can see.
What a month typically includes
- Maintenance. Bugs, small changes, and questions answered by someone who knows the system.
- Security upkeep. Dependency updates, patches and periodic review of access.
- Monitoring. Errors and downtime noticed by us rather than reported by your customers.
- Development. An agreed amount of new work each month — features, integrations, reports.
- A conversation. A regular call about what changed, what is next, and what is not worth doing.
Before you get in touch
You don't need to know exactly what to build.
Almost nobody does at the start. Working out what the right thing to build is — and what it is not worth building — is the first part of the job, not a prerequisite for starting a conversation.
Enough to start a conversation
- What your business does, roughly.
- The part of it that is not working well at the moment.
- What software you currently use, if you know.
- Whether this is an idea, a plan, or something urgent.
No technical vocabulary required. If it turns out software is not the right answer, we would rather tell you that in the first conversation than in the third invoice.
Two things called ShipSure
Built with the same philosophy behind our own product.
The connection worth knowing about is the standard, not the product. We built a tool whose entire purpose is refusing to accept “it’s done” without evidence. That is the same bar we hold our client work to.