Web applications
Web applications built around how your business actually works, not around a template. Interfaces your staff can use on their first day.
- Custom business portals
- React and Next.js
- Responsive by default
- API integrations
Services
Technology work, and the honest advice around it
Six things we do well. If what you need isn't here, we'll tell you — and usually point you at someone who does it properly.
Business ICT consulting
Aligning technology with what the business is trying to do. We start with your operations and work back to the systems, not the other way round.
- Digital transformation
- IT strategy
- Process review
- Technology assessment
Web hosting
Managed hosting with real uptime, real backups and someone who answers when something breaks. Scaled to what you need rather than what we'd like to sell.
- Managed hosting
- Monitored uptime
- Automated backups
- TLS and hardening
ERP advisory
Choosing and implementing an ERP is expensive to get wrong. We help you work out what you actually need before anyone signs a licence.
- Needs assessment
- Vendor selection
- Implementation support
- Staff training
Desktop applications
Desktop software for the work that doesn't belong in a browser — point of sale, production floors, anywhere the connection can't be relied on.
- Cross-platform builds
- Offline-tolerant
- Local database integration
- Hardware support
Cloud computing
Moving to the cloud without moving your problems with you. Infrastructure that scales with the business and costs what it should.
- Migration planning
- Infrastructure as code
- Cost control
- Disaster recovery
Who you're selling to
B2B, B2C, C2B, C2C — and why it changes the build
These get used as though everyone knows them. They're not marketing labels, they're engineering constraints: who's on each side of the transaction decides what the software has to do. Pick the one that sounds like you.
Business to business
One business sells to another business. The buyer is an organisation, not a person, and organisations buy differently.
Your companyAnother company
What it forces the software to do
- Accounts that represent a company, with several staff under one
- Roles and permissions — who may order, who may approve, who may only look
- Credit terms and invoices, not card-on-delivery
- Price lists that differ per customer
- Integration with their accounting or ERP, because the data has to land somewhere
- An audit trail, since someone will eventually ask who approved what
What that looks like here
A distributor portal where supermarket chains place wholesale orders against agreed credit terms, each branch ordering under the group's account, with the finance office approving anything above a set figure.
Where these usually go wrong
The sales cycle is long and the software is judged by the buyer's accountant, not the person using it. Budget for the integration work early — it is almost always bigger than the screens.
How we work
The same three steps, whatever the project
- 01
We start with your operations
Before anything is designed, we sit with the people doing the work. What the software should do becomes obvious once you've watched a day of the job it's replacing.
- 02
We agree what it will cost to be wrong
Every project has assumptions. We name them up front, say which ones we'd bet on, and structure the work so the expensive ones get tested first.
- 03
We build it so someone else could maintain it
Documented, tested, and free of clever tricks only their author understands. You should never be trapped with us because nobody else can read the code.
Not sure which of these you need?
That's a normal place to start. Describe the problem and we'll tell you what it would actually take to fix — including when the answer is 'nothing we sell'.