stalance/services
Fewer slides. More diffs.
We work on the parts of a product that are hard to see and expensive to get wrong: the data model, the pipelines, the integrations and the hosting. Every service below is something we run in production for ourselves, so the proof column is not a case study we borrowed. It is our own pager.
- first step
- A written read-out of your system before any quote
- stack
- Proven open-source, chosen per problem, never per trend
- after launch
- Agreed in the written scope
- on request
- Technical review: a written second opinion on your code or architecture
Web platforms
Multi-site and multi-tenant applications: one codebase serving many brands, domains, languages and databases. Tenancy model, per-site config instead of per-site forks, theming, localisation, admin areas that do not leak across tenants.
proof: one codebase, 20+ storefronts, 8 countries, a database per storefront
E-commerce engineering
Catalogues that stay clean at scale: variants, attributes, search, filters, category trees and technical SEO. Product identity and de-duplication, faceted search, price history, structured data, marketplace and merchant-feed integrations.
proof: 4,000,000+ product listings, price history on every variant
Data pipelines
Ingestion, transformation and classification of messy third-party data, with checks that fail loudly. Feed ingestion and streaming, polite web data collection, AI-assisted classification behind explainable rules, quarantine for ambiguous rows.
proof: 50+ merchant programmes, 4,000,000+ product listings, every day
Cloud and operations
Deploys, queues, monitoring and the unglamorous work that keeps a site fast and up. Zero-downtime web deploys, queues, monitoring, private admin access over a mesh VPN, firewalls at provision time.
proof: we run production for our own 20+ storefronts
What happens after you write
No discovery workshop. No sales engineer. You talk to the person who will do the work.
- You send one paragraph.What the system does, where it hurts, what “fixed” looks like.
- A call with an engineer.We ask about the data, the traffic and the last three incidents.
- A written read-out and scope.Risks ranked, what we would do first, and what we would not touch.
- We start with the riskiest part.If the hard part is going to fail, better it fails in week one.
Not sure which one you need?
Describe the symptom. Picking the service is our job.