Product Engineer

About Purelend

Purelend is an early-stage company operating at the frontier of FinTech and AI. Our small, tight-knit founding team is reimagining banking technology, starting with mortgage loans. We're fully automating the manual checks and underwriting which historically have meant hours or days of frustrating manual work. Our customers and their clients get what they want faster: a funded mortgage.

Our platform is already used by mortgage brokers and lenders across Canada, including some of the country's most important lenders. The product surface has grown bigger than any one founder can hold, and the next phase of the company depends on having someone whose full-time job is making sure we build the right things in the right order.

Our AI Stance

We're all in on AI, and not just in the product. Engineering, infrastructure, design, customer support, sales: every function here uses the best AI tooling we can find to maximize quality and throughput on a small team. We're looking for someone who wants to help us push that bet further, not someone who's skeptical of it.

The Role, and the Thesis Behind It

Our thesis: AI is collapsing the cost of writing code. What's still hard, and getting harder fast, is figuring out the right thing to build, scoping it sharply, and breaking it down so a small team can ship it without losing the plot. The binding constraint on a serious software company isn't typing speed anymore. It's clear thinking upstream of the IDE.

We're hiring a senior Product Engineer to sit on that boundary. You're an engineer at the bone. You think in systems, you write production code, and you have the technical credibility to argue architecture with the engineering team and not get steamrolled. But your center of mass is shifted toward product. You spend more of your time talking to customers, defining what's worth building, scoping it tightly, and breaking it down into shippable chunks than a pure engineer would. You still ship code where it's the highest-leverage thing you can do.

What You'll Actually Do

Sit With Customers

You'll be in front of brokers, underwriters, and lender executives every week. Not surveys. Calls, screen shares, ride-alongs, sometimes office visits. You'll watch how real users work real files, and you'll learn to tell the difference between “they say they want X” and “what would actually change their behavior is Y.”

Define and Scope

You write the briefs. One or two pages that get to the point: who it's for, what changes for them when this exists, the smallest version that's worth building, what's explicitly out of scope, what we'll know after we ship it. You're better at scoping than at typing, and you treat that as your edge.

Break Down the Work

You take a fuzzy problem like “our income verification doesn't work well enough for self-employed borrowers” and turn it into a sequence of shippable chunks an engineer can pick up tomorrow. You know where the seams are, what to ship in week one to learn the most, and what to push until you have the evidence to do it right.

Think in Systems

You see software and the customer workflow it sits inside as one system. You understand state, side effects, latency, error modes, and how a change in one component ripples into the others. Most engineers can do this for code. You do it for the whole customer workflow, which is exactly why your scoping is sharper than someone who only sees half of it.

Write Code Where It Matters

You ship production code regularly, not as a side hobby but as part of the role. Sometimes that's a prototype to learn something faster than a meeting would. Sometimes it's the actual feature because you're the person who understands it best. Sometimes it's the connective tissue between two systems no one else has the patience for. You're a credible engineer who's chosen to weight your time toward upstream work.

Own Outcomes

You define what success looks like before we build. You watch the metrics after we ship. You kill what isn't working and double down on what is. You don't need an analyst to tell you whether a feature is being used.

What You Bring

• 5–10 years building production software. You've shipped features that real users depend on and you've owned a product surface end-to-end, not just one feature inside someone else's roadmap. Ideally one cycle at an early-stage company and one at a scale-up so you've seen both modes.
• A real engineering background that you're still using. TypeScript, Python, Go, or whatever the right tool is. You haven't been “out of the IDE” for years. You can read a codebase, follow a PR review, and ship a clean PR when one needs to happen. You still enjoy it.
• Systems thinking. You can map a customer workflow on a whiteboard and identify the five places it breaks. You see how a change to one component ripples into the others. This is your through-line between engineering and product. It's the same skill applied to different surfaces.
• Project decomposition. Taking a fuzzy problem and turning it into a sequence of shippable chunks is your strongest move. You don't wait for a spec. You write one. You know what to cut first when scope is too big.
• Sharp customer instincts. You can sit on a call with a senior underwriter or a head of broker operations and ask the three questions that tell you what to build next. You'd rather watch one broker use the product for an hour than read ten survey responses.
• Strong writing. Briefs, decisions, postmortems, customer summaries. These are how the rest of the team makes decisions. They need to be sharp, short, and honest about tradeoffs.
• Comfort with data. SQL is a plus. PostHog or Amplitude-style product analytics is table stakes. You can answer “is this feature actually being used” without asking anyone.
• AI fluency, in product and in practice. A lot of what we ship leans on LLMs. You have a real point of view on where models are genuinely useful, where they're a liability, and how to evaluate whether something is good enough to ship. Just as importantly, you use the best AI tooling available in your own work: research synthesis, prototype generation, customer call summaries, internal automation. You see AI as how a small team punches above its weight.
• Mortgage industry experience is a bonus, not required. Curiosity about the workflow is. You'll spend your first month deep in broker and underwriter calls, and you'll need to enjoy that.

What We're Not Looking For

• Engineers who want to live in the IDE and ship tickets someone else wrote. The whole role is the part you'd be skipping.
• Pure PMs without engineering chops. The team needs a technical partner, not a translator.
• Engineers who've drifted away from the IDE for so long they couldn't ship a real feature today. You need both halves of this.
• Anyone who believes scoping is the easy part of software and the hard part is typing. We disagree, and the role is built around that disagreement.

Why This Role Is Interesting

Most companies treat product scoping as a process problem: more PRDs, more rituals, more sign-offs. We think it's an engineering problem, and one that's getting more important every quarter as the cost of implementation keeps falling. The teams that win the next decade will be the ones whose best engineering thinking lives upstream of the IDE, not just inside it. You'll be the first hire we make on that bet, and what you build, features and process, will shape how this company ships for years.

Compensation

Our total compensation, a blend of cash and equity, is market competitive.

Details

• Location: Calgary, AB — in-office
• Reports to: Seb Hiscock (CTO)