Product Engineer

About Straddle, Inc.

Straddle is an open-banking payments platform for account-to-account money movement. We combine identity verification, fraud detection, and multi-rail payments, ACH, RTP, and soon FedNow, into a single API, so businesses can move money between bank accounts as easily as sending a text.

We're headquartered in Broomfield, Colorado, building infrastructure for how modern businesses get paid. Teams are lean, decisions are quick, and layers are minimal. If you care about quality and velocity in equal measure, you'll be in good company.

About the role

We have multiple openings on our Product Engineering team, which builds the customer-facing surfaces of our account-to-account payments platform. Each engineer owns an entire surface: onboarding, bank connectivity, the payment lifecycle, payouts, or the customer dashboard. Not a queue of tickets inside it. You own what gets built, why, whether it works, and what it costs the customer when it doesn't.

Most of the code is written by our agentic system, and you're accountable for it. You specify work precisely enough for an agent to execute, review the output harder than you'd review your own, build the guardrails that make it trustworthy, and know when to write it yourself. This is not a role for someone who wants to stop being an engineer. You have to tell good code from bad at speed, because you're the last check before production.

The scarce input is customer insight. If shipping is no longer bounded by how fast code gets written, it's bounded by knowing what to build. Our product is an API and the surfaces around it, so API design is product design here. Platform Engineering owns the infrastructure, so your time goes to product rather than plumbing.

Full-time in Broomfield, CO with hybrid and remote flexibility. Competitive base salary, benefits, and equity.

What you'll do

• Own a product surface end to end. The problem, the decision about what to build and what to refuse, the implementation, the outcome metric you defined before you started, and the operational health after launch. On-call for your surface included.
• Develop customer insight. Talk to customers and to the people who support them. Read the tickets, watch the analytics, integrate against your own surface and feel where it's awkward. Bring a defensible point of view to planning.
• Specify work for agents. Turn a product decision into intent, constraints, edge cases, and acceptance criteria. Ambiguity a teammate would resolve by asking, an agent resolves by guessing.
• Review adversarially. Hunt the plausible but wrong: missed edge cases, swallowed errors, queries that only work at current scale, security assumptions that don't hold. Reject work below the bar and say why.
• Build guardrails. Tests, evals, and CI checks that let generated code be trusted, so the second feature in your surface ships faster than the first.
• Design APIs as products. Naming, error semantics, pagination, webhook contracts, docs. Every breaking change is a cost paid by someone else.
• Ship interfaces people can use. Responsive TypeScript frontends, including the loading states, empty states, and error copy that agents deprioritize and users notice immediately.
• Model the domain. Data models and storage decisions behind your surface. Getting this wrong is expensive in a way agents can't rescue.
• Integrate partners. Open banking APIs (Plaid, Finicity, MX) and KYC providers. Handle webhooks reliably and design around partners that fail.
• Own security. Authentication, authorization, encryption, common vulnerabilities, PCI and SOC 2 controls. Assume generated code isn't secure until you've verified it.
• Raise the bar. Set standards, mentor other engineers on directing and reviewing agentic work, and push hard feedback into our platform tooling.

Qualifications

• 5+ years in .NET and TypeScript. This matters for judgment, not typing speed. You have to spot a subtle bug or an unsafe pattern in code you didn't write, quickly and reliably. Comfortable with CQRS, IoC, Clean Architecture, DDD, SOLID, and Entity Framework.
• Full-stack range. Data model through API to interface. You can't own a flow if you can only own part of it.
• Product judgment. A track record of shipping things customers used, and evidence you cared whether they did. You can describe a feature you argued against building, or a decision you reversed after seeing data.
• Precision in writing. Intent, constraints, and edge cases expressed unambiguously. It's the main interface through which your work gets done.
• Agentic fluency. Coding agents as a serious part of your workflow, with calibrated judgment about where they fail. If you've built evals, harnesses, or guardrails for agent output, say so.
• Comfort with ambiguity. Take a loose problem, ask the right questions, commit with incomplete information.
• Strong SQL and relational modeling. Schemas, queries, and performance work in MySQL, PostgreSQL, or similar.
• Distributed systems experience. External API integration, message queues, and asynchronous processing for background jobs and webhook handling.
• Security mindset and testing discipline. Secure coding practices, awareness of data privacy and compliance in fintech, and a sense of what makes a test suite protective rather than decorative.
• Communication. Explain a tradeoff to a non-engineer, talk to customers without a translator, give and take direct feedback.
• CS fundamentals from a degree or from work: data structures, algorithms, complexity.

Bonus:

• Fintech or payments: ledgers, reconciliation, ACH file processing, Nacha and PCI DSS
• Open banking APIs (Plaid, Stripe, PayPal): bank auth flows and token handling
• Developer experience work: SDKs, embeddable widgets, API docs, sandboxes
• Ownership on a small team: founder, first engineer, or sole owner of a surface
• Azure (App Service, Container Apps, Functions, Cosmos DB, Service Bus) or AWS and GCP equivalents
• Observability and product analytics: Application Insights, Datadog, PostHog
• Event sourcing or NoSQL
• Design sensibility: able to make reasonable calls without a designer