Backend Engineering · 3 min read
SW · Custom Software
Custom software for business rules that off-the-shelf tools can't handle.
We design and build platforms, backends and integrations for companies whose edge lives in their own business rules. Architecture built to scale, to be maintained by another team, and to keep working when a dependency fails.
Fig. 02 · Failure propagation: synchronous vs. event-driven
Dependencies
- Billing
- Inventory
- Orders accepted
- 0
- Orders lost
- 0
Log
- Take a dependency offline and place an order.
Problems we solve
Systems rarely fail for lack of features. They fail through coupling, inconsistent data and missing visibility.
ProblemApproach
A small change touches several modules and nobody feels safe deploying.
Explicit domain boundaries, contracts between modules and automated tests that make deploys routine.
When an external system goes down, the whole operation stops with it.
Asynchronous communication where it fits, retrying queues and controlled degradation.
Data drifts between ERP, CRM and the platform, and reconciliation is manual.
Idempotent integrations, a transactional outbox and a defined source of truth per entity.
The system got slow as volume grew.
Measure before optimizing: query profiles, indexes, caching and, only when needed, separate services.
What we build
Custom software development for complex requirements, from backend to operations.
SaaS platforms
Multi-tenancy, billing, permissions and observability from the first release.
Backend systems
Services with careful domain modeling, correct transactions and measured performance.
Enterprise integrations
ERPs, CRMs, payment gateways and legacy systems connected safely.
REST and gRPC APIs
Versioned, documented APIs with idempotency, pagination and rate limits.
Real-time systems
WebSockets, streaming and event processing with ordering guarantees where needed.
Distributed architectures
Independent services when scale or team structure justifies them, and not before.
Process automation
Internal workflows automated with traceability and replay.
Database design
PostgreSQL schemas designed for consistency, real queries and zero-downtime evolution.
Cloud-native services
Containers, infrastructure as code, automated deploys and horizontal scaling.
Technical capabilities
Practices that keep a system reliable and maintainable for years.
Domain-driven design
Models that mirror the business and boundaries that contain the impact of change.
Consistency and transactions
Explicit choices between strong and eventual consistency, per use case.
Reliable messaging
Outbox, idempotency, dead-letter queues and replay.
Observability
Structured logs, metrics and distributed tracing from day one.
Zero-downtime migrations
Schema evolution in backward-compatible steps.
Layered testing
Unit, contract, integration and load tests, each in its place.
Example applications
Typical scenarios. These are scope examples, not delivered projects.
- B2B
Vertical SaaS platform
A multi-tenant product with industry-specific rules, billing and granular permissions.
- Logistics
Order orchestration
Integration across e-commerce, ERP and carriers with end-to-end tracking.
- Financial services
Financial product backend
Accounts, transactions and reconciliation with an audit trail.
- Operations
Legacy modernization
Gradual replacement of a monolith, module by module, without stopping operations.
Reference architecture
An integration hub with a verified inbox, sagas and a transactional outbox.
Components
- E-commerce
- Order source via webhook.
- Payments
- Payment confirmations via webhook.
- Verified inbox
- Verifies HMAC signatures and drops duplicates by event ID.
- Order saga
- A state machine with a compensation for every step.
- Outbox
- Messages written in the same transaction as state.
- ERP
- Receives orders and invoices with an idempotency key.
- CRM
- Updates the customer timeline.
- Dead letters
- Permanent failures with full context and a replay button.
Reliability and maintainability
A system's real cost shows up after launch. We design for that period.
- Defined SLOs
- Availability and latency targets agreed with the business and measured in production.
- Fearless deploys
- CI/CD, feature flags and fast rollback keep changes small and frequent.
- Secure by default
- Strong authentication, per-resource authorization, managed secrets and reviewed dependencies.
- Living documentation
- ADRs, up-to-date diagrams and runbooks for known incidents.
- No vendor lock-in
- Code, infrastructure and knowledge transferable to your team.
How we implement
- 01
Domain mapping
Entities, rules, integrations and the business's real volumes.
- 02
Architecture and ADRs
System structure and decisions recorded with the alternatives considered.
- 03
Vertical slice
One complete flow running in production early, end to end.
- 04
Continuous increments
Short, demonstrable deliveries with reviewed and tested code.
- 05
Operations and handover
Monitoring, support and a structured handover to your team.
Custom software questions
Microservices or a monolith?
It depends on team size and domain. We often start with a well-structured modular monolith and extract services when there is a concrete reason, such as independent scaling or separate teams.
Do you take over existing systems?
Yes. We start with a technical assessment of code, infrastructure and risks, and propose incremental evolution instead of a full rewrite.
Which languages do you use?
TypeScript, Go, Rust and Python are the main ones. The choice depends on the problem, the ecosystem and your team's ability to maintain the system.
Who hosts and runs the system?
It runs in your cloud account, under your control. We can operate it during a support period or hand operations over to your team.
How do you estimate timelines?
After discovery we estimate per increment with explicit uncertainty ranges. We'd rather give an honest estimate with a margin than an optimistic number.
Related insights
- Software Architecture · 3 min read
- Software Architecture · 3 min read
Has your current system hit its limit?
Tell us what it does today, where it gets stuck and what it must do tomorrow. We start with a technical assessment.