Prediction products.
Android people can trust.

The connection for me is that I've already built a product around predictions and live events at Verdict MMA. I worked across the Android experience and backend, including deposits, withdrawals, and the behavior around payment-provider callbacks. I like that these products put engineering decisions directly in front of the user: whether the information is current, whether an action is still pending, and whether the displayed balance can be trusted.

Polymarket adds a deeper real-time trading problem to that experience. The role combines native Android, payment flows, and live market data, which is a concrete fit with the work I've done and the areas I want to deepen. I'd bring experience owning the whole feature while learning the exchange-specific behavior from the team.

I bring startup product ownership and experience shipping inside a larger engineering organization. At Verdict MMA, I owned work across native Android, web, and backend in a prediction product. That included making deposit and withdrawal flows coherent across the app, our APIs, and an external provider.

At Lyft, I led the Android client for Driver AI from specification to public launch. That required shared API contracts, chat and voice behavior, driving-aware controls, and coordination around integration blockers. Earlier, I owned six Android apps at FantasyPros and worked on Kotlin modernization and release practices.

For this role, I would lead with the Verdict domain connection and then use Lyft to show how I carry a feature across team boundaries. I would be precise about what transfers and what I still need to learn about trading infrastructure.

At Verdict, I fixed an edge case where a declined full-balance withdrawal could fail to refund the player. The original withdrawal had correctly left the player's balance at zero, but the reversal reused a check that compared the refund amount with that already-debited balance.

I traced that assumption through the reversal path and removed the inappropriate withdrawal-style guard. I kept the transaction and ledger sanity checks. Then I added a regression test that replayed pending, in-progress, error, and declined callbacks and checked the debit, refund entries, and restored balance.

The corrected behavior was that the decline sequence could return the original balance. I do not claim a historical dollar amount recovered. The lesson was to test the complete business transition: a check that makes sense when taking money out can be wrong when putting that same money back.

I start with the state the user needs to understand and who has authority to change it. In a payment flow, for example, the UI can own a loading indicator, but it cannot infer settled money movement from a successful redirect. At Verdict, I explicitly handled pending, failure, back, and close states around the provider experience.

For a Kotlin and Compose implementation today, I would keep the feature's state and operations in a ViewModel and expose immutable state to the screen. The repository would own server data and reconciliation, while the UI would render state and send user actions. I would scope collection to the screen lifecycle and keep expensive parsing or transformation off the main thread.

The tradeoff is deciding how much structure the feature needs. I want state ownership and failure behavior to be clear, without building layers that have no responsibility of their own. I would explain those choices against a concrete screen rather than just naming an architecture pattern.

One example is an internal workflow I productionized at Lyft. It takes a request through research and planning into draft iOS and Android pull requests. The hard part was moving beyond a prototype into something engineers could operate and review.

I added queued workers, authenticated webhook ingress, a GitHub App, and human review gates. I worked through restart and cluster failures and aligned the integration with the infrastructure owner. The workflow was used during a sprint and packaged for broader use.

For me, AI is useful when it reduces the time to inspect or implement a well-scoped change, but the engineer still owns the behavior. I keep permissions bounded, review generated changes, and verify the actual result. I would not turn tool-repository activity into a claimed productivity percentage without measuring the work that people accepted.

A pressure example is a voice project where scope grew, backend gaps appeared, and I had overlapping on-call work. I absorbed those changes without making the effect on capacity visible early enough, and my estimate slipped.

I owned that with my manager and reset the plan. I started making capacity caveats explicit, raising scope changes sooner, and splitting later work into smaller reviewable units. My large-PR feedback reinforced that change in delivery structure.

What I learned is that intensity does not remove the need to communicate the tradeoff. I need to make the changed situation visible early enough for the team to adjust scope, sequencing, or ownership. The supported result is the replanning and changed behavior; I would give the actual delay and consequence from memory rather than invent a missed launch.

I would first learn the product and the team's boundaries around an action that matters to users, such as placing an order or moving money. I'd trace the screen, repository, transport, backend contract, observability, and release path so I understood where the authoritative state comes from and how failures reach the UI.

Then I'd take a bounded feature or reliability issue through production, working with the people who own its other dependencies. That would give me a practical view of the codebase and the review and release expectations.

From there, I would look for repeated friction in state handling, performance, or the build and suggest a change supported by what we observed. The goal would be a shipped contribution and a clearer view of the next problem, with the scope chosen together with the team.

At Verdict, I implemented Android deposit and withdrawal flows that crossed our app, backend APIs, and an external hosted payment provider. The challenge was making that asynchronous flow understandable inside a native app.

I added the presenter methods to request provider URLs, used amount-in-cents contracts, and hosted the provider experience in our WebView. I wired loading and error feedback and handled success, pending, failure, back, and close states. I also connected the callbacks to analytics and navigation back to the tournament lobby.

The important result was a coherent native flow across those boundaries, including a distinct pending state. A successful redirect was not the same as final settlement, and I kept those meanings separate. I learned to design mobile flows around authoritative state transitions rather than relying on the order or appearance of external UI events.

At Verdict, I fixed an edge case where a declined full-balance withdrawal could fail to refund the player. The original withdrawal had correctly left the player's balance at zero, but the reversal reused a check that compared the refund amount with that already-debited balance.

I traced that assumption through the reversal path and removed the inappropriate withdrawal-style guard. I kept the transaction and ledger sanity checks. Then I added a regression test that replayed pending, in-progress, error, and declined callbacks and checked the debit, refund entries, and restored balance.

The corrected behavior was that the decline sequence could return the original balance. I do not claim a historical dollar amount recovered. The lesson was to test the complete business transition: a check that makes sense when taking money out can be wrong when putting that same money back.

I would trace Driver AI from the specification to the launched Android experience. The first boundary was the shared message model: another team owned it, and we needed Android and iOS behavior to align. I wrote the Android spec and worked on additive chat and tile models with that owner.

The implementation covered chat, speech input, plan cards, and driving-aware input behavior. That meant the Android client was responsible for more than displaying a server response; it had to handle the interaction in the context in which a driver would use it.

I also aligned client, backend, and data engineering on what data we were gathering, and coordinated with support and the driver team about our changes. This brought the teams responsible for data and the people supporting the driver experience into the work.

The next difficult boundary was integration. Duplicated messages and backend ownership gaps became launch blockers, and I helped work through them across teams. That is where I carried responsibility beyond a locally complete client.

The supported result is the public launch and later reuse of the chat patterns. The tradeoff I would emphasize is designing around shared contracts and existing consumers while delivering a new experience. The lesson is that end-to-end ownership includes making the system work across the responsibilities you own directly and the ones you have to coordinate.

At Verdict, live fights concentrated scoring and notification work into short bursts. External push providers added latency outside our control, so accepting a request and completing all of its background work needed different paths.

I hardened the round-ballot queue's database lifecycle and moved push delivery into a Redis-backed Bull queue. I introduced a job wrapper that acquired a database connection, propagated processing errors, and released the connection in a finally block. I also used a limiter for notification work and later replaced sequential insertion with bulk enqueueing.

That gave us a more controlled processing path and explicit handling for failures and connections. I do not have a recovered throughput or latency benchmark to attach to it. The lesson was that introducing a queue is only the start: admission, processing, retry, and user-visible completion each need a deliberate contract.

At Verdict, I worked on tournament leaderboards where the product needed an ordered slice of entries during live events. I focused on matching the database access path to the actual lookup rather than adding an index without understanding the query.

I added a composite index on tournament ID, entry position, and user ID. In related tournament-list work, I also reverted pagination metadata changes. Those were separate decisions: the index supported the access pattern, while the revert protected the API contract that installed clients depended on.

The result I can demonstrate is the index and the explicit compatibility correction. I would need query plans and representative benchmarks to claim a particular speedup. The lesson was that a backend optimization has two acceptance criteria: the database must do less unnecessary work, and the client must continue interpreting the result correctly.

I would separate market metadata from the fast-changing quote state. A repository would combine the initial snapshot with updates, and the UI would render by stable market ID rather than row position. Search and subscriptions would follow the visible product needs instead of subscribing to every possible market.

On Android, I would use lifecycle-aware collection and avoid moving high-frequency parsing or sorting onto the main thread. For a watchlist, coalescing visual quote updates may be useful if the product accepts it. For an order book, I would first understand the feed's ordering and recovery contract before dropping or combining updates.

I would make connection and freshness state visible. The decision to permit an action against an old quote belongs in an explicit product and server contract; cached data is useful for viewing but is not proof that the displayed price is still executable.

I would treat reconnect as a reconciliation problem. First, identify which guarantees the actual transport supplies: sequence identifiers, event identities, snapshots, ordering, and replay. Then build recovery around those guarantees. I would not assume WebSockets or gRPC provide application-level replay by themselves.

When the connection drops, retain the last view with an explicit freshness state. On resume, obtain an authoritative snapshot and establish a consistent subscription boundary using the protocol's supported mechanism. If a sequence or version is available, use it to reject older updates and detect gaps. If it is not, define a resnapshot strategy rather than inventing one.

The subscription owner must also match its lifetime. A screen should not create duplicate collectors on every recomposition, and returning to the foreground should reconcile state before clearing the stale indicator.

A request timing out does not prove that the server rejected the order. I would model submitting and unknown outcome separately from confirmed rejection. The UI should prevent a casual repeated tap from creating a second operation, then reconcile with the server using the supported order or request identity.

I would distinguish an accepted order from a fill, and a fill from final settlement. Partial fills, cancellation, and rejection need their own product behavior. A pending row should explain what is known without presenting an optimistic balance as authoritative.

For retries, I would use the server's actual duplicate-prevention contract. If there is a durable operation identity, reconcile before retrying; if no such guarantee exists, that is a backend contract to resolve. I would also record enough non-sensitive correlation information to investigate an ambiguous result.

I would preserve the precision and unit specified by the backend contract and avoid floating-point money arithmetic. At Verdict, our integration used amounts in cents. That is useful experience, but I would not assume cents are the correct unit or precision for outcome tokens or this exchange.

Callbacks can repeat or arrive after the user has left the screen. The backend should enforce the intended ledger transition with the provider's identity and transaction semantics; the client should refresh or observe the authoritative result. A redirect, a push notification, and a balance update should not each independently credit the account.

For the mobile experience, I would make pending and failed states understandable, allow recovery after Activity recreation, and preserve enough operation context to resume. The refund example from Verdict is a useful reminder that debit and reversal operations have different invariants.

I would make the ViewModel own the feature's state and operations, with the repository owning network and persisted data. Compose would render an immutable state and send explicit actions. Work that must survive screen recreation should not depend on a composable's temporary coroutine scope.

Use structured concurrency so cancellation follows the intended owner, and preserve cancellation rather than swallowing it in generic error handling. Collect state with awareness of the screen lifecycle. Keep expensive decoding, database operations, and transformations off the main thread as appropriate to the libraries in use.

For a live market screen, separate the subscription lifetime from a particular recomposition. Profile the actual interaction before adding stability annotations or extra caches. The useful result is predictable state and responsive rendering on the devices users have.

I would first understand the current Gradle configuration and release pipeline before changing it. The useful questions are whether developers can reproduce a build, whether signing and credentials have clear ownership, and whether CI catches the failures that matter before a release reaches users.

For a risky payment or streaming change, I would review compatibility with the backend, run the project's existing checks, and exercise the relevant success and failure paths. A staged rollout with observability should let the team identify a regression and apply the agreed mitigation.

I would measure build work before claiming a speedup and compare the same task under defined cache conditions. AI-generated changes would pass through the same review and release requirements as any other change.

A pressure example is a voice project where scope grew, backend gaps appeared, and I had overlapping on-call work. I absorbed those changes without making the effect on capacity visible early enough, and my estimate slipped.

I owned that with my manager and reset the plan. I started making capacity caveats explicit, raising scope changes sooner, and splitting later work into smaller reviewable units. My large-PR feedback reinforced that change in delivery structure.

What I learned is that intensity does not remove the need to communicate the tradeoff. I need to make the changed situation visible early enough for the team to adjust scope, sequencing, or ownership. The supported result is the replanning and changed behavior; I would give the actual delay and consequence from memory rather than invent a missed launch.

An Android Auto release failed when drivers connected to a physical head unit. The initial mitigation was broad because we had not yet isolated the affected population.

As a responder, I reproduced the failure on real hardware, compared phones and OS versions, and shared logs. I isolated the regression to Android 16, which let the team restore the feature for unaffected cohorts while validating the specific fix. I also helped check the release candidate and a manifest-test issue in CI.

The source reports a targeted fix within roughly three days. My contribution was reproduction, isolation, and validation; I was not the incident commander. The lesson was to distinguish immediate recovery from permanent remediation and to use evidence from the actual device and release boundary to narrow the risk.