Services
Two groups of work sit on this page: business systems for small businesses and founders, and mobile SDK, ad monetization and AI integration work for product and engineering teams. Both start with mapping what actually happens and end with a working system. We keep the scope narrow enough to launch quickly and useful enough to change the business.
The first group is for a business where something is manual, or does not exist yet, and the build starts by mapping the process. The second is engineering work inside a product that already ships and already has users — a mobile SDK other teams embed, an ad monetization stack, an AI feature — where the process exists and one layer of it is failing.
They sit on one page because the failure mode is the same in both: the visible part looks fine while the part that decides the outcome was never checked. In a booking flow that is the cancellation path nobody tried. In an ad integration it is the release build that quietly stopped sending a parameter. What changes between the groups is who we talk to and where the risk hides — not how the work is run.
Business systems
Booking, intake, first versions and internal tools for small businesses and early-stage founders. These builds start from how the work runs today — who calls whom, what gets retyped, what falls through — and end with something your team uses instead of the manual routine.
Replace phone calls, missed WhatsApp messages, and manual confirmations with a booking flow that confirms, reminds, and updates people automatically.
Best for
Restaurants, clinics, beauty studios, consultants, and service businesses that lose time around scheduling.
Typical deliverables
Turn scattered forms, calls, emails, and chats into one clear intake process that gathers the right details before work starts.
Best for
Small teams that need better qualification, cleaner handoff, and fewer back-and-forth messages.
Typical deliverables
Build the smallest useful version of a product idea so founders can test the real workflow with real users before overbuilding.
Best for
Founders and operators who need a working product, not months of planning documents.
Typical deliverables
Move repeated work out of spreadsheets and chats into simple tools that help teams track, update, and act on the same source of truth.
Best for
Teams that have a process that works in theory but breaks when volume rises or people get busy.
Typical deliverables
SDK, ad-tech and AI
For product and engineering teams: native Android and iOS, SDKs that host apps embed through React Native, Flutter or Unity wrappers, Google Ad Manager, AdMob, IMA for video and GMA for mobile display, releases through the App Store and Google Play, and AI features added to a codebase that was written before we arrived. The team here usually has engineers already — the gap is someone who has shipped this specific integration before and knows how it is verified.
Build and maintain libraries other developers embed: native Android and iOS targets, the React Native, Flutter and Unity wrappers around them, and release builds verified from the packaged artifact.
Best for
Product and engineering teams who distribute functionality to other companies' apps, and anyone whose SDK works in debug and breaks in a customer's release build.
Typical deliverables
Integrate Google Ad Manager, AdMob, IMA and GMA as the separate systems they are: correct initialization order, identity and signal enrichment at every request site, and verification against real ad requests.
Best for
Apps and publishers whose ad stack is technically live but under-delivering, and teams adding video, identity or signal enrichment to an integration that already exists.
Typical deliverables
Add an AI feature to a product that already has users: embeddings and ranking where they help, plain business rules where they must decide, and cost and latency handled as design constraints.
Best for
Teams with a live product and a real matching, ranking, drafting or classification problem, who need the result to be explainable to the people using it.
Typical deliverables
The four business systems on this page are not packages to pick from a menu — they are the four shapes that work usually takes. If the jam is customers trying to reach you and staff answering the phone mid-service, that is booking automation. If it is unqualified enquiries arriving through five channels and the first call starting from zero, that is client intake. If nothing exists yet and you need evidence before spending more, that is an MVP build. If the process works but only when one specific person is present, that is an internal operations tool.
Every business-systems page linked above has a section on what version one deliberately leaves out, because that is where these projects are won or lost. A booking flow does not need deposits, waitlists and loyalty points to be worth launching. An intake system does not need scoring before anyone has seen the raw enquiries. Cutting version two before estimating version one is the single habit that keeps a build launchable.
The screens are rarely the expensive part. The expensive part is the payment provider, the point-of-sale system, the calendar, the messaging channel — each one a real dependency on software we do not control. When we quote, integrations are named individually rather than folded into a feature list, because that is where scope quietly grows.
For the engineering group the first useful question is where the boundary sits. If other teams have to embed your code — native Android, native iOS, and a React Native, Flutter or Unity wrapper on top — that is SDK work, and the wrapper is usually where the time goes, because it has to forward calls and callbacks in the exact shape the host SDK expects. If the app already shows ads and the problem is what the ad request contains, when it fires, or which of Google Ad Manager, AdMob, IMA and GMA is involved, that is ad monetization and ad server integration. If the product itself works and the feature you want is a ranking, a match or a summary the current code cannot produce, that is the AI work.
Two facts decide how this work is run. Release builds on Android go through R8 and ProGuard, which can strip or rename a class an ad SDK resolves reflectively at runtime — so the debug build passes, the release build fails, and nothing in the source tells you which one you are looking at. And there is no unit test for whether the ad server received the parameter you think you sent. So verification means building the APK, AAB or framework and inspecting what is actually inside it, then making real ad requests and reading them. A unit test cannot catch a class that compiled cleanly and then got dropped from the shipped bundle.
Identity and signal enrichment has to be registered and ready before the ads SDK initializes, and that readiness has to be awaited rather than assumed. If it is not, the first ad request of the session goes out unenriched, nothing throws, no log line looks wrong, and the session simply earns less. The same applies per call site: enrichment has to happen at every ad request in the app, and a missed one is invisible unless you go looking for it. That is why listing every ad-request site in the app is part of the estimate rather than something discovered halfway through.
Each of the business systems above has shipped at least once. These are the live builds behind them, with the technical decisions that shaped each one.
The SDK and ad monetization work is not represented above for a simple reason: it is contract engineering inside another company's product, so there is no site of ours to link to. The client is IntentIQ, an ad-tech company we work with on mobile SDK development — native Android and iOS plus the React Native, Flutter and Unity wrappers — and on identity and secure-signals integration across Google Ad Manager, AdMob, IMA and GMA. Their implementation details stay theirs. What this work produces that we can publish is the engineering practice around it: the ordering constraints, the keep rules, and the habit of verifying against the packaged artifact rather than the source tree.
Reservation and booking automation
An ordering flow with delivery-zone rules that decide checkout eligibility, Cardcom card payments, and a handoff into the Aviv POS. Built in about two months and in daily use for more than five years.
Read the build notes →Reservation reminders at scale
Per-user reminders sent at each user's own minute, using Firestore time-bucket documents checked once a minute instead of a task queue. Six languages, and users grouped by rounded location so the source API is called once per location per day.
Read the build notes →Client intake systems
Structured intake feeding a matching layer: statements stored as separate parts rather than one text blob, embeddings for similarity, and plain pass/fail business rules deciding what actually qualifies. About six months of scope.
Read the build notes →Features that do not change the workflow or help a user make a decision.
Large dashboards before the team knows which numbers matter.
Generic tools that duplicate what an existing platform already does well.
Ad integrations signed off from a source review or a debug build instead of the packaged artifact.
SDK support that stops at native Android and iOS when the host apps ship React Native, Flutter or Unity.
AI features that depend on data the product is not collecting yet.