Custom software platforms

We build operational platforms: the system a business runs on rather than a site that describes it. In practice that usually means Laravel or Next.js on AWS or Google Cloud, in the il-central-1 region for Israeli clients, with the pieces that usually get discovered late designed on purpose at the start.

• The schema

  The decision that gets harder every week you postpone it.

• Queues

  Not an optimisation. The line between slowed down and taken down.

• The API

  Designed once, before the first consumer exists.

The database is the decision that lasts

Schema design is the one thing that gets harder to change every week you postpone it. We spend real time on it early: what the actual entities are, where the money lives, what has to be auditable, and what has to survive being wrong. A platform that models a customer, an order and a payment correctly can absorb five years of feature changes. One that does not will need a migration project roughly every eighteen months, and each one will be sold to you as a new feature.

We use relational storage by default and are specific about where we leave it. Money, inventory and anything a regulator might ask about belongs in a transactional database with constraints that make invalid states impossible rather than merely unlikely.

Queues are not an optimisation

Anything that talks to a system you do not control belongs behind a queue from day one: payment providers, shipping APIs, messaging gateways, the customer’s own ERP. Not because it is faster, but because it is the difference between a supplier’s outage slowing you down and a supplier’s outage taking you down.

The work is in the failure handling rather than the queue. What retries, how many times, with what backoff, what is safe to run twice, and what has to be manually resolved by a human who needs to understand what happened six hours later. Idempotency is a design property, not something you add during an incident.

APIs get designed once

Every platform we build ends up with something else talking to it, usually sooner than anyone predicted: a mobile app, a partner, a reporting tool, an AI feature. We design the API surface as a product from the start, with versioning and authentication decided before the first consumer exists, because retrofitting them means breaking whoever is already connected.

We price and design for the running cost, not only the build. A platform that costs a fortune to operate is a platform you will be asked to replace, and the decisions that drive that bill are architectural: how much you keep in memory, how chatty the system is with itself, whether you sized for your peak hour or your average one, and how much of your traffic never needed to reach the application at all.

We would rather ship something modest that costs very little to run and can grow than something impressive that starts with a bill nobody budgeted for. Caching, CDN and query design do more for both speed and cost than adding capacity, and they keep doing it as you grow.

Engagements normally start with a short paid discovery. We look at what you have, what it costs, what breaks, and what you are actually trying to achieve. The output is an architecture, a phased plan and an estimate, written so that you could hand it to another firm if you wanted to. That happens occasionally and we would rather it happened than have someone locked in by a document only we can read.

Then we build in phases that each end in something usable. The first release is deliberately narrow: one real workflow, running in production, with real users. A platform that reaches production in eight weeks and grows is worth more than one that arrives complete in a year, because the second one is complete according to assumptions nobody has tested.

We stay on afterwards. The team that designed the schema is the team that gets the alert at two in the morning, which turns out to be a remarkably effective constraint on design decisions.

We pick per project rather than per habit. Laravel and PHP where the work is operational and long lived, Next.js and React where the interface is the hard part, on AWS or Google Cloud. What we will not do is choose something because it is new.

What every one of those choices has in common is a large hiring pool and a long support horizon, so a developer who joins in year three can read code written in year one. We optimise for the decade rather than the demo, and if that points away from what we last used, it points away.

We run our own products on the same stack, including irua.app and wagate.app, which means the operational decisions we recommend are ones we are living with ourselves.

Platforms rarely stand alone. Most of ours also involve system integration with software the client already runs, and increasingly AI features built on top of the data the platform collects. If the platform is a storefront, see e-commerce engineering.

Tell us what you are building