---
title: "Software development on demand"
description: "Bespoke TypeScript services and integrations, delivered in your repository and documented for handover."
language: "en"
canonical: "https://zapolu.com/services/custom-development/"
---

# Software development on demand

Not everything fits inside a platform. When the work is a custom
service, an integration layer, an internal tool, or a marketplace
backend, we build it from first principles in TypeScript: scoped in
writing, delivered in your repository, and documented well enough that
the next team can take it over without us.

## What we build

- **Custom integrations** between e-commerce and ERP / PIM / WMS
  systems, when the off-the-shelf connector covers 80% of the flow and
  the missing 20% is the part your business depends on
- **Internal tooling** that doesn't belong inside your shop admin:
  pricing engines, returns handling, warehouse dashboards, customer
  service consoles
- **Marketplaces, multi-tenant SaaS backends, and domain-specific
  services** where the domain logic is the product
- **Migrations off bespoke legacy systems** where the requirements
  are partly documented and partly held as institutional knowledge,
  and the first deliverable is writing down what the old system
  actually does

A few builds of this shape from past years, anonymized: an automatic
repricing engine for a 123,000-product catalog, driven by predicted
days-to-sell-out from ERP data, with rule bands, an audit trail, and
safeguards for cases where the automated price and a human decision
conflict; a
14-hour sales-history recalculation parallelized down to 2.5 hours,
processing recently sold products first so the most recent figures
are available first; and a customer migration between platforms with no
password-reset email, verifying against the legacy hash on first
login and transparently re-hashing to the new format, plaintext never
stored.

## How we build

Every backend we ship follows the same structure:

- **Structured modules** with explicit dependency declarations
- **Dependency injection** that can be overridden for testing or for
  environment-specific behavior
- **Lifecycle hooks**, so subsystems boot and shut down in the right order
- **Boot-time contract validation.** The app refuses to start if its
  wiring is incomplete. Misconfiguration surfaces in seconds at boot
  rather than as a null-pointer exception three weeks into production.

We insist on this structure because it keeps assumptions visible, and
because we want software that is still understandable a year after
launch.

## What delivery looks like

- The work happens in **your repository, in your organization**; you
  own the code from the first paid invoice
- Tests and contract checks run in CI from the first week, not as a
  hardening phase at the end
- Every deploy keeps a rollback path, and the system ships with logs,
  metrics, and alerts wired in. The
  [DevOps & infrastructure](/services/devops/) page describes how we
  operate what we build
- Handover documentation is a deliverable in its own right: runbooks,
  an architecture note, and a decision log

Where the hard part is deciding what to build rather than building it,
that's [system design & architecture](/services/system-design/), and we
do the two together or separately. Fixed-scope builds typically run
4–16 weeks, invoiced weekly; long-lived systems usually continue on a
monthly retainer.