Snippets

I'm so chuffed to tick off a first for me in hiring - hiring through an external referral!

A few weeks ago we brainstormed what else we can try to hire a very hard to fill role. In the end we had a toss up between a billboard, or an external referral push.

I'm not trying to build suspense here, so don't wait for it. The billboard isn't coming 🙈

But the external referral worked so well, we're running it back. This time for our support engineering and sales roles in SF.

I've mentioned these jobs before, but if you need a refresh, links to job ads in the comments!

If you know someone who'd do well at Plain, and you'd like some extra pocket money for your summer holiday, tag them in.

Or, DM me if you don't want their current employer freaking out 😅

🕵️‍♂️ Ever watched a murder mystery where every clue feels exciting but incomplete until that one perfect detail ties it all together?

When designing software, I call these details Magic Moments. They're the storytelling beats that make your product experience click. Turning something useful into something people genuinely love using.

Here's how we identify and create these moments at Plain.

Coming from a Go background, I'm used to being deliberate about error handling.

Every function that might fail returns an error. You check it, log it, and return early if needed. It’s repetitive, but it’s explicit, and the pattern is pretty much guaranteed to be the same regardless of the codebase that you’re working in.

Now I’m working in a TypeScript codebase, and we’ve adopted a library called `true-myth` to bring some of those same principles over. It gives us a `Result` type that makes success and failure explicit, without hidden exceptions or try/catches scattered everywhere.

True Myth helps us avoid surprises. Because you have to unwrap that result, you’re forced to think about both failure and error paths, similarly to how you’d handle them in Go.
That said, the tradeoffs are familiar:
* You end up writing a lot of repetitive checks
* The boilerplate can add up
* It’s honestly just extremely verbose

If you’re used to Go-style error handling and working in TypeScript, true-myth is a nice middle ground. I can’t tell if I love it yet, but curious to hear any opposing thoughts on this approach

At Plain, we’ve been generating AI-powered answers to customer questions in more parts of the product, such as in our Help Center (support.site).

“Only use information from the provided documentation” or similar is a common line found in RAG (Retrieval Augmented Generation) prompts. But it comes with challenges.

When a customer asks a question and the documentation doesn’t contain an answer, we want a way to indicate that no answer was found and handle this situation differently, rather than confidently making something up.

We initially tried a two-step approach:

1️⃣ Generate an answer using RAG.
2️⃣ Run a second LLM-as-a-judge call to validate whether the answer is grounded in the provided input.

This worked well, but as we’re using the same model and inputs, this often failed.

So we tried a different approach: tool calling that explicitly allows for a null value when an answer is not found.

Instead of always generating a response, we ask the LLM to return either a valid answer or null when no grounded response can be found. This works well for a few reasons:

💡 It encourages the model to make an early decision: “Do I have what I need?”
🧠 It significantly reduces irrelevant or hallucinated answers.
😶‍🌫️ It helps filter out the obscure, edge-case queries that customers sometimes come up with (trying to expose the prompt, irrelevant or inappropriate questions, etc).

I'm curious if others have tried similar techniques or different ones to keep RAG answers tightly scoped to the documentation?

’ve been recruiting for a long time 👵, but recently joined Plain to help scale the team. I thought hiring our first Support Engineer in SF would be easy peasy (we’re literally building a support product!). Spoiler alert: it’s not.

A few things I’ve learned:
- This is a proper founding role. We’re looking for someone who’s technically sharp, genuinely excited about what we’re building, and happy flying solo for a bit while we grow the team.
- Our physical presence in SF is basically “hi, we exist” - and response rates have been a bit of an ego bruiser.
- We know great candidates move fast but with the time difference, Lucas and I have had to shift our working hours just to keep up.
- Some roles are just different and this role sits right at the heart of the product, talking to customers daily and working directly with Matt, Simon, and Youmna to build how support works at Plain from the ground up.

If you’ve got tips on hiring your first support engineer, please share!

And if you know someone great, we’re offering → $$$$10,001 referral bonus

A friend took this photo of me during my first month in the UK. I was watching the sun set over the Thames, clearly excited to be living in one of the most diverse and dynamic cities in the world. I couldn’t have imagined what the next four years would bring. During my time in the UK, I:

- Traveled to 17 countries
- Earned my MBA from the University of Oxford and built a community of friends I’ll carry with me for life.
- Explored VC through the Oxford Seed Fund and Lakestar and developed a thesis on what I believe makes a great startup.
- Used said thesis to discover Plain and join as the first non-engineer hire.
- Helped grow Plain into a product used by hundreds of customers, setting the stage for a U.S. expansion.

Now, I’m heading back home to help scale Plain from San Francisco.

To everyone I met in the UK, thank you. It’s hard to articulate how much I’ve grown during my time here, both personally and professionally. To those in SF (or anywhere across the U.S.), hello! I'd love to catch up in person soon 😊.