We said "PandaDoc" more than we said "Scout Talent". So we built our own.

For four years, Scout Talent sent every sales proposal through PandaDoc. It worked. Documents went out, signatures came back, nobody thought about it too hard. That's usually the sign a piece of software has quietly become invisible, for better or worse.

CEO Andrea Davey put her finger on the moment it stopped being invisible. "We said 'PandaDoc' more often than we said 'Scout Talent'. Internally, in meetings, and on calls with clients. 'I'll send you the PandaDoc.' Four years of that. We had trained our own people, and our clients, to name someone else's product at the exact point in the relationship where we should have been reinforcing ours." The emails a prospect received at the moment they were closest to buying carried a different brand entirely. Once she saw it, she couldn't unsee it.

That's a small, honest thing to admit publicly, and it's the reason this is worth writing about. The problem wasn't really PandaDoc. It was four years of small frictions everyone had learned to live with: copying details out of Salesforce, formatting breaking when a pricing table changed, version confusion when a deal went through three iterations. None of it was a crisis. That's exactly why it survived so long.

Why building it made sense

The brief that started this wasn't "build us a proposal tool." It was "our proposals don't represent our brand well." The team looked at alternative providers first. Sheila, who ended up building the replacement, explains what changed her mind: "We almost signed up to Qwlr, but then we reviewed the functionality and how it works. Overall we liked the web page proposal but it still did not solve our overall workflow, so I asked if we could vibe code for a week and see how complicated it would be."

A week in, the core feature was working. Two weeks in, the end-to-end workflow was done. Sheila built it on Supabase and Vercel, simple, boring infrastructure choices that meant more time on the actual problem and less on plumbing.

Andrea's read on why the decision flipped: "Two years ago this would have been a massive project requiring a business case and a significant time investment. Once you see that a proper build is two weeks of focused effort, the question stops being 'can we afford to build this' and becomes 'why would we continue to pay a subscription for something that isn't as good'."

Replacing the tool wasn't the point

The easy version of this project would have replicated PandaDoc's workflow in a new interface. Sheila was clear that this was the trap to avoid: "Most teams make mistakes by replicating the same workflow to the new system. The purpose of moving to a new system is improving workflows, replicating the same would not change the experience."

So the new tool, Scout Proposals, doesn't just send documents. It tells a story: the recommended solution, why it helps, how it compares, a client success story, and only then the pricing, in that order, because that's the order a person actually needs to be talked into a decision. Signing is available the whole way through the page rather than buried at the end.

Sacha Price, who uses it daily as a Sales Account Executive, describes the difference in plain terms: "The look and feel of the proposals is significantly more professional than those in PandaDoc. It aligns far better with our brand and the value we're providing the prospect. It also does a far better job of 'selling the solution', which is so important when internal discussions are being had that we're not part of."

The rollout mattered as much as the build

A two-week build is a nice story, but it means nothing if the sales team quietly goes back to old habits. What actually made this stick was unglamorous: a beta period with two SAEs, a demo at a morning sales meeting, then two to three weeks of the whole team using it in beta before it became official, with a Slack channel running the whole time for feedback and fixes.

Sacha's account of adoption is refreshingly ordinary: "Not much resistance. The natural questions that stem from familiarity surfaced, but we had a global Slack channel set up by Sheila to help capture feedback and adjustments needed as we used the proposals more. The overall sentiment was excitement." No lengthy training programme, no change management framework. Just visibility into what was changing, a place to ask questions, and a builder close enough to the work to respond to them fast.

That closeness is the part we'd point to if anyone asked what made this different from a typical vendor rollout. Sheila wasn't handing the sales team a finished product from a distance. She was in the same building, hearing the same objections, fixing the same edge cases (prepaid campaigns, overseas clients without GST, franchise pricing) as they came up, in days rather than through a support ticket queue.

What we'd tell anyone thinking about the same move

Andrea's advice to another software business: "If your last build-versus-buy assessment is more than eighteen months old, it's wrong. Two weeks of focused effort now delivers what used to be a proper project, and that moves a whole category of tools from 'not worth building' onto the other side of the line."

Sheila's version is more practical: understand the actual pain point and process before you touch the architecture, build reporting in early because it shapes everything downstream, and know that a workflow as complex as a franchise business's pricing model won't always fold into two weeks quite so neatly.

And Sacha's, from the seat of someone who has to use whatever gets built: get the client experience and the workflow right before anything else, and give people a real forum to flag what wasn't thought of the first time. Nothing ships finished. It just ships close enough to start learning.