We build small systems around real business problems.

An SDK is a different problem from an app. The public surface has to be small enough to explain in a README and stable enough that a host app moving to a new version does not have to rewrite its call sites. Everything behind that surface — initialization, threading, what happens with no network, what happens when a callback arrives after the screen it belonged to is gone — is ours to get right, because the integrating team cannot see into it and should not have to.

Platform coverage is not one job either. Native Android and native iOS are one problem, with two languages, two build systems and two sets of lifecycle rules. React Native, Flutter and Unity sit on top of that as a wrapper layer, and the wrapper is where most breakage happens, because it has to forward every call and every callback the host SDK expects — including the ones that only fire in situations nobody demos.

What the integrator receives is a built artifact, not our source: an APK or AAB on Android, a framework on iOS, a package for the wrapper platform. The artifact is therefore the only thing worth verifying against, and that habit is the second lesson further down this page.

Google Ad Manager, AdMob, IMA for video and GMA for mobile display get discussed as one thing called "ads". They are not interchangeable. Each has its own initialization order, its own request shape and its own failure modes, and treating them as a single swappable component is the ordinary reason an integration is wrong in a way nobody catches.

The characteristic failure in this area is silence. A request that goes out missing a parameter does not throw, does not log an error and does not show a broken screen. It fills. A user sees an ad, the session looks healthy, and the placement earns less than it should have. Nothing in the app is in a state you would call a bug.

So verification is not a code review. It is making real ad requests from the real build and inspecting what went out and what came back, per platform and per format. There is no unit test for "did the ad server receive the parameter we think we sent", and writing one that passes proves only that the code we read does what we read it to do.

Identity and signal enrichment has one constraint that is easy to say and easy to get wrong: the adapter has to be registered and ready before the ads SDK initializes, and its readiness has to be awaited rather than assumed. If initialization races ahead of it, the first ad request of the session goes out unenriched. Nothing errors. That request is simply worth less, once per session, on every device.

The second rule is coverage. Enrichment has to happen at every ad-request site in the app — each banner, each interstitial, each rewarded placement, each video slot. Miss one site and that one placement degrades quietly, and it stays invisible in logs unless somebody goes looking for it specifically, which nobody does unless they already suspect it.

Both of those are why this kind of engagement ends with a pass over the installed build watching live requests, and with a written list of every call site we found, rather than with a green test suite.

The AI work we can point at publicly is inside Djob, and its shape is the shape we reuse. Jobs and candidates are split into structured statement parts, and each part is embedded with OpenAI's text-embedding-3-small, rather than pushing a whole CV through as one blob of text — a blob averages away the specific thing you wanted to match on. Cosine similarity then produces a ranking.

A ranking is not a decision, and that is the part most AI features get wrong. In Djob the similarity score is gated by pass/fail business rules, and when a candidate who reads as close to a role is excluded, the system says which hard requirement excluded them. The model drafts; the rules decide, and the rules are readable by the person who owns the outcome. We would build a summariser, a categoriser or a suggestion feature the same way.

Cost and latency belong in the design from the start. Djob reads its rankings from precomputed snapshot tables in PostgreSQL rebuilt daily, not from pairs scored when a page opens, because a recruiter who waits for a shortlist goes back to their spreadsheet and does not come back.

Every project on this page needed the same unglamorous half: scheduled work, a data model that can be queried the way the product actually reads it, an admin screen a non-technical person can operate, and some way to see afterwards what happened. Mincha Time runs on Firebase Cloud Functions with Firestore and Cloud Messaging. Djob runs on PostgreSQL with a daily rebuild. The Domino site has admin screens for products, deals, categories, pizza sizes, beverages, sauces, delivery zones, site settings and orders, because a menu only a developer can change is a menu that goes stale.

Workflow automation is usually one shape: something runs on a schedule, decides whether there is anything to do, and does it. Mincha Time is that at its cheapest — a function every minute, a Firestore lookup for the current time bucket, and almost no cost on the runs where the answer is no. Most automation people ask for is a variation on that, and the interesting decisions are about idempotency and what happens on the run after a failed one, not about the trigger.