Delivered for a mobile tipping product we built and later sold, through Platform to Platform and Data to Data.
The challenge. Tipping apps hand the user a selection and stop there. The user still has to decide how much to stake, open another app, find the market, and get on before the price moves — which is where most of the value of a good tip is lost.
Context
BetrBets was a mobile racing tipping product we designed and built for the Australian market, and later sold to a wagering group. It generated tips from models, sized the stake for the individual user, and placed the bet on Betfair Exchange on the user’s behalf.
We were listed in Betfair’s public vendor directory, which is what made the automated execution path available.
The problem
A tip is not a decision. A tipping app that returns “runner 4 in race 6” has answered the easy half of the question and left the user with the rest of it: how much to put on, whether this tip is more or less confident than yesterday’s, and how to get the bet placed before the price moves.
That last part is where the value goes. The user reads the tip, switches to a wagering app, finds the meeting, finds the race, finds the runner, and takes whatever price is available by the time they get there. On an exchange, where prices move on the other side of the book, the delay between deciding and executing is measurable in the price achieved.
The stake-sizing gap is worse. Two users with the same tip and different bankrolls should not bet the same amount, and neither should the same user bet the same amount on a high-confidence and a marginal selection. Most tipping products treat stake as the user’s problem, which means it defaults to a habit.
Why it is hard
Confidence has to be a number the stake can be computed from. A tip is only useful for sizing if the model emits calibrated confidence rather than a ranking. Turning “this is our top pick” into a stake requires knowing how strong a top pick it is, and the answer has to be comparable across races and days.
Models disagree, and sometimes a human is right. A production tipping system needs machine models, expert input, and a way for the two to overrule each other without either becoming untraceable. That means model versioning and recorded overrides, not a config change.
Automated execution against a real exchange is unforgiving. Prices are live, liquidity is finite, and the bet either got on at an acceptable price or it did not. There is no retry semantics that make an expired market work. The integration also runs under the exchange’s vendor rules and the user’s explicit authorisation, both of which have to be enforced in the code path rather than assumed.
Risk appetite is a user setting with real consequences. An “aggressive” profile that produces stakes the user did not expect is a trust failure and a responsible-gambling problem at the same time. The mapping from profile to stake has to be legible to the user before they authorise anything.
What we built
A tipping engine with versioned models and recorded overrides. Multiple data sources and modelling techniques feeding tip generation, with real-time probability overrides, factor adjustments, and model versioning. Users could select machine-generated tips, expert-curated tips, or a hybrid of the two, and every tip carried the version of the model that produced it.
Risk profiling that drives stake size. The user picks conservative, moderate or aggressive and sets a budget. Stake size for each tip is then derived from that budget and the tip’s confidence score rather than being a flat amount, so a marginal selection is a smaller bet by construction.
Exchange execution. With the user’s authorisation, the app fetched live prices and placed the selected bets on Betfair Exchange at the time of wagering, rather than reporting a price the user then had to chase. Authorisation is per-user and revocable; nothing is placed without it.
A mobile-first client on one codebase. React Native for iOS and Android, with TypeScript, Ant Design Mobile and GraphQL, covering secure login, wallet views and live racing dashboards.
Serverless back end. AWS Lambda behind API Gateway with DynamoDB for state, Node.js for services, Python for model execution and Java for API services. The load profile is spiky and race-bound, which is the case serverless is actually good for: nothing runs between meetings.
Results
Tip to placed bet became one action. The user authorises once and the bet is executed at live prices, which removes the delay that was costing them price.
Stake size responded to bankroll and confidence rather than defaulting to habit.
Model and human input coexisted with an audit trail. Every tip is attributable to a model version or a named override.
The product was acquired by a wagering group and absorbed into their ecosystem. The approach carried across.
We have no user numbers, bet volumes, retention figures or returns cleared for publication, and none appear here.
What we would do differently
We would build the responsible-gambling controls before the risk profiles rather than alongside them. Deposit and loss limits, cooling-off, and a hard ceiling on what an “aggressive” profile can stake in a day are not features that sit next to automated execution — they are preconditions for it. Building them second meant retrofitting constraints into a stake-sizing path that had already been designed without them.
We would also decouple the model runner from the app release cycle earlier. Model execution and the mobile client shipped on the same cadence for longer than they should have, which meant a model improvement waited on an app store review.
Where this transfers
The pattern is a model producing a calibrated recommendation, a user-declared risk profile turning that recommendation into a sized action, and automated execution against a live venue with an audit trail behind every decision. That is the same architecture as model-driven investment tools with automated order placement, and as any product where the recommendation is worthless unless it can be acted on immediately.