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 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, 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.