Netic
Software engineer · August 2026–present
My current chapter: software engineer at Netic in New York City, since August 2026. I bring a foundation in payments and infrastructure to the work of building reliable systems as a company grows.
Software engineer at Netic NYC
Jake Laney
I took a payments platform from zero to production across dozens of countries.
Building systems people depend on, and keeping them on course.
- Rippling
- Staff engineer.
Founding payments engineer. - AWS
- Global EC2 deployment infrastructure.
Plate I A course held between its bounds
- Fix intent before departing.
- Enforce invariants where drift meets the bound.
- Design for recovery, and rejoin the course.
Background
New products. Real stakes. Systems that hold up.
Rippling
Staff engineer · Insurance, payroll & payments
As the founding engineer for a new payments platform, I took it from zero to production across dozens of countries.
I built new products across insurance and payroll during Rippling’s growth from Series B to G. Shipping reliable software quickly led to a fast promotion to staff engineer, while growth kept testing early design decisions.
The systems I owned stayed stable, with measurable results and honest communication about their state. In payments, that meant making every payment auditable, recoverable, and reconcilable.
AWS
Deployment infrastructure
I built deployment infrastructure for large fleets of EC2 instances: cellular architecture and operational tooling that ran globally.
That early work established my approach to rigor and risk assessment. An outage could halt thousands of site deployments; observability, recovery, and safe changes were engineering requirements.
Approach
“Invert, always invert”
Move fast without breaking things.
At AWS, an outage would halt thousands of site deployments. In payroll, a failure could mean a missed payment or an unexpected value in a paycheck. A startup has to move fast; those stakes demand discipline.
Instead of starting with the happy path, I imagine the worst failure that could happen. Once it is clear, a few simple guardrails let the system move forward safely.
I applied this directly to payments. Every payment had to be auditable, recoverable, and reconcilable, and four guardrails kept it that way:
- Intent
- A fixed record of intent defined what should happen before any money moved.
- Invariants
- Runtime invariants enforced constraints such as money out never exceeding money in.
- Observability
- Observability kept every payment’s state legible.
- Escalation
- Cases outside what the code explicitly permitted escalated for human review.
Engineering notebook Sketch 01
When a payment loses its way.
An illustrative payment model. Choose a failure and follow the checks and the recovery.
Fixed intent A Sender → recipient · amount fixed
- IIntent
- IICheck
- IIISend
- IVMatch
- VDecide
Read all three walkthroughs
Clear path
Result: one confirmed transfer, matched to the original intent. No further send.
- Record the intent.
Record the sender, recipient, and amount under intent A before money moves.
- Check the boundary.
The request matches A. Runtime checks pass, including money out not exceeding money in.
- Send once.
The provider completes the transfer and returns an acknowledgement tied to A.
- Match the outcome.
Match the provider reference, sender, recipient, and amount to A. The audit record agrees.
- Close the record.
The payment is complete, with its intent and confirmed outcome available for audit.
Provider completed, acknowledgement lost
Result: hold while delivery is unknown; reconcile the existing completion. One transfer, no second send.
- Record the intent.
Record the sender, recipient, and amount under intent A. A timeout must not change this intent.
- Check the boundary.
The request matches A and the runtime checks pass. The system permits the first send.
- Acknowledgement lost.
The provider completed the transfer; its acknowledgement was lost. To the caller, delivery is unknown.
- Find the existing transfer.
Match the provider’s record to A: completion confirmed. If still unknown, hold and escalate.
- Recover, then close.
Record the confirmed outcome and the lost acknowledgement in the audit trail. The original intent remains unchanged.
Conflicting retry / intent mismatch
Result: block the mismatched retry and escalate for human review. Zero transfers.
- Keep the original intent.
Intent A is already recorded. An incoming retry uses A’s reference but asks for a different amount.
- Reject the mismatch.
The runtime check detects that the retry differs from A. Reusing a reference does not authorize a changed payment.
- Do not send.
The conflicting request stops before the provider. No money moves, and no replacement intent is silently created.
- Make the conflict legible.
Record the original intent, the attempted change, and the blocked decision together in the audit trail.
- Escalate the exception.
The code cannot authorize a changed payment. Keep it blocked for human review.
The transfer count describes the hypothetical provider outcome, even when the caller cannot yet know it.
A continuing interest
Agent infrastructure
The same questions show up in production AI agents: how to bound what they can do, enforce invariants, design escalation paths, recover from failures, and keep a useful audit trail.
I think of agent infrastructure as distributed systems work more than research work. Models will be wrong sometimes. The platform around them still has to enforce the properties that matter.
Contact
Compare notes.
Building payments, infrastructure, or the systems around agents?
I’d like to hear how you’re keeping them on course.