Custom software and platform development

Custom software is expensive to build and permanent to own. That combination means the first question is always whether it is necessary, and the honest answer is frequently no: a configured product plus some integration work covers most requirements at a fraction of the cost and none of the maintenance liability.

It becomes the right answer when the process genuinely is your competitive advantage, when per-seat licensing at your headcount exceeds build cost, or when the workflow is unusual enough that configuring a product means fighting it permanently. We will tell you which situation you are in before you commit budget.

Why this is worth doing properly

The build-versus-buy calculation has moved against building for anything generic. Products now cover CRM, support, project management and analytics well enough that recreating them is difficult to justify. What has not been commoditised is the specific operational workflow a business runs on, and that is where custom development still earns its cost.

The other change is that the real expense is not the initial build. It is the five years afterwards: dependency updates, security patches, browser changes, the person who understood it leaving. A quoted build price that ignores this is quoting for a third of the actual commitment, and we would rather set that expectation at the start.

Data model decisions made in the first fortnight determine what is cheap and expensive to change for the entire life of the system. It is the one part of a project where spending an extra week early reliably saves months later, and the part most likely to be rushed under delivery pressure.

Where this work usually goes wrong

Building what a product already does

Recreating a CRM or a helpdesk absorbs enormous effort for a result that will always trail the commercial alternative. Build the part that is genuinely yours and integrate the rest.

No migration path in the data model

Schemas designed for the launch requirement and never for change make every subsequent feature expensive. Migrations, versioning and the ability to evolve the model belong in the first design.

Skipping tests on the flows that matter

Full coverage is rarely worth it; zero coverage on payment, authentication and data export is negligent. Test what is expensive to get wrong.

Undocumented and unhandoverable

A system only one supplier understands is a commercial hostage. Documentation, standard technology and repository ownership should be delivery requirements, not favours.

Launching without operational tooling

No logging, no monitoring, no way to see what a user actually did. The first production incident is the wrong moment to discover you cannot observe the system.

What this covers

Custom business applications

Systems built around a specific operational process rather than configured around a generic one.

SaaS platform development

Multi-tenant products with subscription billing, tenant isolation and self-service onboarding.

Internal management systems

Tools for operations teams where the workflow is specific to how you actually work.

Client and employee portals

Authenticated areas with role-based access to documents, data and actions.

Booking systems

Availability, scheduling, payment and reminders, including multi-resource and multi-location cases.

Academy and learning platforms

Course delivery, progress tracking, assessment and certification.

E-commerce systems

Storefronts and order management where a standard platform cannot express the product or pricing model.

Inventory and order-management systems

Stock, purchasing, fulfilment and reconciliation across locations and channels.

Customer databases

Structured customer data with deduplication, history and a defined ownership model.

Custom dashboards

Operational views built for the decisions they support rather than for the data that happened to be available.

Admin panels

Internal administration with audit logging and permissions that reflect real responsibilities.

REST API development

Documented, versioned APIs with authentication, rate limiting and sensible error semantics.

FastAPI backend development

Python backends with typed request and response models and generated OpenAPI documentation.

Database architecture

Schema design, indexing, constraints and a migration strategy that anticipates change.

Authentication and user management

Sessions, roles, single sign-on and password handling done to current standards rather than invented.

Payment integrations

Stripe and regional gateways with tax, currency and strong customer authentication handled properly.

Third-party software integrations

Connections to the systems the business already runs, built to survive vendor API changes.

How the work runs

1. Challenge the requirement

   We start by trying to talk you out of it. If a configured product plus integration covers eighty per cent of the requirement, that is usually the better commercial decision and we will say so before quoting a build.

2. Model the domain

   Entities, relationships and lifecycle states agreed before any interface work. This is the decision with the longest consequences and it gets proportionate time.

3. Build the thin slice first

   One complete path through the system end to end, deployed, before breadth. It surfaces the integration and architecture problems while they are still cheap to fix.

4. Instrument from the first deploy

   Structured logging, error tracking and monitoring in place before real users arrive, not added after the first incident.

5. Test what is costly to break

   Automated coverage on authentication, payments, permissions and data export. Deliberately not everywhere.

6. Document and hand over

   Architecture notes, runbooks, repository and infrastructure access. You should be able to appoint another supplier without a rewrite.

What you receive

• Build-versus-buy assessment
• Domain model and database schema
• Working deployed application
• Documented, versioned REST API
• Authentication, roles and permissions
• Automated tests on critical flows
• CI/CD pipeline and environments
• Monitoring, logging and error tracking
• Architecture documentation and handover

You probably need this if

• Your operation runs on a spreadsheet nobody dares restructure.
• Per-seat licensing has become your largest software cost.
• You are fighting a product’s assumptions on every workflow.
• The process that makes you money is the one with no software behind it.
• An existing system works but nobody can safely change it.

What we build and work with

Deliberately conventional. Novel technology choices are a cost your successor pays, and we try not to impose them.

Python with FastAPI

Typed backends with generated OpenAPI documentation, which keeps the API contract honest as it changes.

PostgreSQL

The default data store. Proper constraints, real transactions and enough capability to postpone specialist databases indefinitely.

TypeScript front end

React or Svelte where an application genuinely needs interactivity, and server-rendered HTML where it does not.

Docker

Reproducible environments so local, staging and production are the same shape.

Alembic migrations

Versioned schema changes under review, because ad-hoc production schema edits are how data loss happens.

Stripe and regional gateways

Payments with tax, currency and European strong customer authentication handled at integration rather than patched later.

Playwright and pytest

Automated tests on the flows where failure is expensive, run in the deployment pipeline.

What changes once this is in place

A system shaped like your process

Software that matches how the business actually works, instead of a process bent to fit a product.

Predictable change cost

A data model designed for evolution, so the second year of features does not cost more than the first.

Observable in production

Logging, error tracking and monitoring from day one, so incidents are diagnosed rather than guessed at.

No supplier lock-in

Conventional technology, your repository, your infrastructure accounts, and documentation good enough to hand to someone else.

Honest advice about not building

Where a product plus integration is the better answer, you hear it before the budget is committed.

How this differs by market

The work is the same craft everywhere. What changes is the law, the language and the buying culture — and those change enough to matter.

European Union

Data protection by design and by default is a legal requirement under Article 25, not a principle — it affects schema design, retention and the ability to fulfil access and erasure requests. Payment flows must implement strong customer authentication under PSD2, and accessibility obligations under the European Accessibility Act reach many consumer-facing services from 2025.

Nordics

BankID in Sweden and Norway and MitID in Denmark are the expected authentication methods for consumer-facing systems, and their absence is conspicuous. Public-sector procurement frequently requires EU or national data residency, which is an infrastructure decision to make at the start.

United States and Canada

Sector rules govern: HIPAA for health data, PCI DSS for card handling, SOC 2 expectations for anything sold to enterprises. Canada adds provincial requirements, with Quebec’s Law 25 imposing assessment obligations on transfers outside the province.

United Arab Emirates

Arabic and right-to-left support is an architectural decision affecting layout, text handling and numerals, and retrofitting it is far more expensive than building for it. VAT at five per cent must be handled correctly in any billing flow, and financial services entities in DIFC and ADGM carry their own regulatory expectations.

Not legal advice. Regulatory summaries on this site describe how we scope and build, and are current to our latest review. Verify the operative text with qualified counsel in the relevant jurisdiction before relying on it.

How we know it worked

We measure delivery against the thin-slice milestones agreed at the start, and report slippage when it happens rather than at the end. A project that is late is discovered early or discovered expensively.

In production we track error rate, response time at the slow tail rather than the average, and uptime. These are reported from the monitoring system, not asserted.

Where we claim a system reduced operational effort, that comes from a baseline captured before launch. If no baseline was taken, we say the saving is unmeasured rather than estimating one.

Estimates are labelled as estimates. Any figure on this site that describes a range is a planning estimate with its assumptions stated, not a measured client outcome. We do not publish client results without the client's permission and a date.

Related services

Sectors where this is usually the lead engagement

These are the industries where this discipline is typically the first thing a client buys rather than something added later. The link goes to a page written for that sector specifically, with a paragraph on this service and on every other one.

• Manufacturing & Industrial — Excellent products, world-class production, and commercial systems that have not been touched in a decade. That gap is the opportunity.
• Construction & Engineering — The fastest-accelerating sector for AI adoption, running on drawings, variations and payment applications that arrive as PDFs.
• Wholesale & Distribution — Thin margins, enormous SKU counts and customer-specific pricing that lives in a system nobody wants to touch.
• Fintech & Payments — Startup growth expectations inside a supervised institution, where onboarding conversion and financial crime obligations pull in opposite directions.
• Agriculture & Agritech — A sector where subsidy compliance, buyer requirements and new supply chain regulation all demand data that farms have never systematically collected.

It appears on all thirty sector pages, because every one of them carries a paragraph on all twenty-two services. This list names only the sectors where it tends to lead.

Where we deliver this

This service is delivered across the European Union, the Nordic countries, North America and the United Arab Emirates. The craft does not change; the law, the language and the buying culture do. Consent regimes, invoicing mandates and payment conventions differ enough between markets that a campaign or a system built for one frequently cannot be used unchanged in another.

Each country page sets out what actually differs there and what it means for scope — all 32 countries and 10 cities are listed here. A few of the markets we work in most:

• Germany
• Netherlands
• France
• Sweden
• United States
• United Arab Emirates