Skip to content

Services

Four kinds of work.

Most engagements start in the first of these and pull in the others. If a project is the wrong shape, I would sooner say so than take it and find out later.

Backend systems and APIs

Java, Spring Boot, PostgreSQL.

The server, the schema and the API that everything else depends on. Thirteen years of it, mostly as the only developer on the system. The data model, the endpoints and the deployment all get decided by the person who then has to live with them.

  • Domain and database modelling built to outlast the first three feature requests
  • REST APIs consumed by web and mobile clients
  • Reversible migrations, and a schema that stays readable as it grows
  • Authentication, roles, and audit trails

Systems integration

Making software talk to software it was never designed to meet.

Connecting the systems a business already runs: CRM, ERP, identity, payments, email automation. The point is that data moves between them without anyone re-keying it. Usually the least glamorous part of a project, and the part most likely to sink it.

  • ERP and CRM integration (ERPNext, Zoho)
  • National identity and authentication providers (BankID / GrandID)
  • Marketing and transactional email automation (Klaviyo)
  • Legacy systems that only speak their own protocol

Workflow and line-of-business platforms

The system an operation would stop without.

Approval chains, case management, scheduling, document tracking. Processes that live in email threads and spreadsheets today, turned into something with a state machine behind it and a record of who did what.

  • Business process and approval workflows (jBPM)
  • Case and document management with full history
  • Role-based access for office, floor and field
  • Reporting the people doing the work will actually open

Architecture review and AI-code audit

You shipped it with AI tools. Now you need to know what it will cost you.

An independent read of a codebase built fast, often by a founder using AI coding tools, before it scales past the point where problems are cheap. What is sound, what is fragile, what will fail under load or audit, and what to fix in what order.

  • API design, data model and architecture review
  • Third-party integration and data-security risk
  • Findings ranked by what breaks first, not by severity theatre
  • Written for a non-technical founder to act on

Mobile and web applications

Android, iOS and the web.

Flutter apps built to survive the conditions the work happens in: offline where there is no signal, localised properly where English is a second language. Plus web front-ends and Shopify builds, configured and handed over so your own team can run them.

  • Flutter apps for Android and iOS from one codebase
  • Offline-first with conflict-safe sync
  • Store submission, signing and release
  • Shopify build, theme and payment configuration

Not sure which of these you need?

That is a normal place to start. Describe the problem, not the solution, and I will tell you what it would actually take.