Real-time systems
Cross-venue arbitrage detection and execution
Two prediction markets list contracts on the same event, the
same crypto price at the same settlement time, and price them
independently. This system watched both continuously and acted
when they disagreed by more than the cost of trading.
- Role
- Sole engineer
- Status
- Ran live with real capital
- Scope
- Four assets, two venues, rolling settlement windows
- Surface
- Discovery, execution, measurement, dashboard
Problem
The two venues don't agree on what a market is. One
organises contracts as series with tickers and floor strikes on
fixed windows; the other lists them as standalone markets with
their own identifiers and close times. Before two prices can be
compared at all, you have to establish that the contracts
genuinely settle on the same event: same asset, same strike,
same instant. And because the windows roll continuously, with a
new one opening as the last closes, that pairing has to be
rediscovered constantly rather than configured once.
The harder problem is that the edge is small and perishable. By
the time a price gap is large enough to notice, it usually means
one venue is stale rather than that anything is genuinely
mispriced. Telling those two cases apart is the actual work;
everything else is plumbing.
Approach
Built in layers. A discovery layer queries both venues
independently and matches their markets into pairs by asset and
settlement time. Fetchers poll both order books alongside spot
prices from several exchanges. A signal layer computes the edge,
with a Black–Scholes model supplying an independent reference
price, not to trade on, but to sanity-check what the books were
claiming.
Everything ran through a paper-trading stage that simulated fills
before any capital was committed. Live execution came later and
stayed deliberately narrow: signed orders, per-market cooldowns
so a repeated signal can't stack duplicates on one contract, a
kill switch with a daily loss limit, and balance polling so the
system works from what the account actually holds rather than
what it believes it holds.
Outcome
The measurement layer turned out to matter more than the trading
layer. Several plausible-looking strategies were tested and did
not survive contact with real data: an entry timed to the final
seconds of a window, and a pricing relationship between paired
contracts that proved to be an artifact rather than a signal.
Each hypothesis got its own tracker that recorded live data and
scored itself against real settlements, and critically none of
them were allowed to influence the live signal while they ran,
because measuring a thing shouldn't change it. That separation is what
made it possible to be wrong quickly and know it. One approach
did hold up under that testing: the cross-venue divergence the
system was built around. Reaching it meant discarding most of
what I started with, which is the part I'd point at.
Build vs. buy evaluation
Grant discovery for a college-access nonprofit
A nonprofit serving under-resourced students needed a dependable
way to find the education grants it qualified for. The work
started as a custom platform and ended with a recommendation not
to build one.
- Role
- Technical evaluation and solution design
- Engagement
- Evaluation and recommendation
- Status
- Recommendation delivered
- Sector
- Education nonprofit
Problem
Grant search at the organization was manual, so opportunities
were found late or missed outright. The original brief was a
custom platform: a Next.js and Supabase web app pulling open
education grants nationwide from a paid grants data feed,
filtering automatically to the state and private funders the
organization was eligible for, hiding anything whose deadline had
passed, and emailing the team whenever a new match opened.
Fully branded, logins for the whole team, owned end to end.
Approach
Before building the application, I traced where its data would
actually come from. The feed the custom app would have depended
on is the same data already sold directly by Candid, the sector's
main grants database, packaged with search, saved searches, RFP
recommendations, and email alerts as standard features. The
proposed product substantially already existed as a subscription,
and building it would largely have meant re-skinning that, plus
taking on a permanent maintenance obligation.
I priced both paths. The subscription, layered with Candid's free
RFP notifications and a strong chance of qualifying for free
Premium access through the Seal of Transparency program, came to
roughly $1,700 in the first year. Building custom was $10,000 or
more before any ongoing upkeep.
Outcome
I recommended the organization not build. It gets the two things
it actually needed, seeing relevant grants and being notified
when new ones open, for about a sixth of the cost, with nothing
to host, monitor, or keep running, and no dependency on one
developer staying available.
The useful judgment here was scoping the data layer before the
application layer. Had the build gone first, the same
subscription would have surfaced as a dependency partway through,
after the budget was already committed.
Full-stack web
Sybil storefront, checkout, and order operations
A live e-commerce site handling real card payments, built and
operated end to end: storefront, checkout, order database, and
the internal tool used to fulfil orders.
- Role
- Sole engineer
- Status
- Live, taking orders
- Surface
- Storefront, checkout, admin
Problem
Selling physical product needed more than a catalogue page: real
payment handling, an order record that survives the browser
session, shipping across roughly thirty countries, and a way to
mark orders shipped and hand customers a tracking number without
touching the database by hand.
Approach
The storefront is static and dependency-free, with the dynamic
work behind serverless functions. Checkout creates a Stripe
session; a signature-verified webhook is what actually writes the
order, so a customer closing the tab mid-redirect can't produce a
paid order with no record. Orders normalise into a relational
schema across customers, addresses, orders, line items, and an
event log. Fulfilment runs through a token-protected admin view
with status updates, tracking codes, and CSV export.
Outcome
A security review of the checkout path found the server was
trusting prices sent by the browser, meaning a modified request
could buy an $80 item for a dollar. Pricing now resolves
server-side from the product ID, with the client's figures used
only for display, covered by tests for tampered prices, unknown
products, and invalid quantities. The same pass cut the deployed
payload from roughly 600 MB to under 13 MB, largely by
removing full-resolution originals that were being served to
phones.