One backend, many products

We are a small studio with a portfolio that looks bigger than our team: a live exchange-rate app, a document-redaction tool, a World Cup tracker, and more. We can carry that range because we do not rebuild the same thing over and over. We build tools once and reuse them.

Reusable packages, not copy-paste

The core of our engineering is a set of shared packages — our design system, data-fetching layer, internationalization catalogs, schemas, and business rules — with one package name per concept. A component lives in the shared UI library, never in an individual app. An app or marketing site holds only its own product-specific code plus a small configuration file; it never restyles anything itself.

The rule we hold to is DRY across products: any logic that does not genuinely depend on the platform has exactly one home and is never copied. We only maintain a second implementation where the platform truly differs — how a screen renders, how the shell works, how storage behaves. Everything else is written once.

One shared backend

On the server side, we run a single shared backend, and each product is an app inside it. Quantis, our Venezuela exchange-rate viewer, talks to a backend that aggregates rate sources. Our World Cup 2026 tracker consumes a single bundle endpoint from that same backend, which polls the upstream football data provider and keeps the API key server-side where it belongs. The frontend holds no secrets and makes only same-origin requests.

Sharing one backend is also a discipline. It is a scarce resource, so we cache, dedup, and derive before we fetch. A product that hammers the server is a product that makes every other product slower, so “be a good tenant” is built into how we query.

The same experience on web and mobile

Because the hard parts — schemas, rules, catalogs, tokens — are shared, the same product can appear on the web and on a phone without drifting into two different apps. Quantis runs as a React Native app on Android and as a web app, backed by the same rate data. The goal is zero-friction consistency: you should recognize a Vzla.io product instantly, wherever you open it, because underneath it really is the same product.

Why it matters to you

This is not just internal tidiness. Reuse is why a two-person change can land across several products at once, why a fix in one place fixes it everywhere, and why we can start a new product by slotting it into machinery that already exists instead of starting from a blank page. Fewer moving parts means fewer bugs, faster fixes, and more time spent on the thing that is actually new.