Internal sales quoting system
Built an end-to-end quote-to-pay flow at Properti without adding new tools. Stripe and HubSpot were already there. The job was making them work.
What we were working with
Properti’s sales team was quoting customers manually. Spreadsheet, email, follow-up, follow-up again, eventually a payment link, eventually a signed agreement, eventually a customer onboarded. Every step a handoff. Every handoff a place where deals stalled.
The instinct in this situation is to buy a tool. Salesforce CPQ, PandaDoc, DocuSign, GetAccept, take your pick. The market is full of products that promise to solve the quote-to-cash problem.
We didn’t buy anything. Stripe and HubSpot had been core to Properti for five years. Both were already wired into billing, deal pipeline, customer records, and finance reporting. The right move wasn’t adding a third vendor to the stack. It was making the two already there do the work properly.
Why not just buy CPQ
A few reasons, in order of importance.
The integration cost of new tools is invisible until you pay it. Adding a new SaaS to a five-year-old operation means migrating customer data, retraining the sales team, rebuilding finance reports, and building two new integration layers (CPQ to HubSpot, CPQ to Stripe). The vendor sales pitch never includes this. The implementation always does.
The data already lived in HubSpot. Every customer, every deal, every stage was already there. Pulling that data into a CPQ tool to generate a quote, then pushing the result back to HubSpot, is a synchronisation problem nobody actually wants.
Stripe was already the payment system of record. Customers were already paying through it. Subscriptions were already managed there. The CFO already trusted its reporting.
Five years of institutional knowledge gets respected, not bypassed. People at Properti knew how HubSpot worked. They knew how Stripe worked. New tools mean new training, new errors, new "how do I do that again" moments.
What I built
The system spans three layers, all wired together with a quoting interface I designed and built myself.
The quote builder. A custom interface where sales could configure a Properti package, apply discounts, set terms, and produce a customer-facing quote in under five minutes. Pulled product, pricing, and customer data directly from HubSpot. Pushed the resulting quote back to HubSpot as a deal artefact.
Document generation. PDFKit on the backend, generating branded PDF quotes that matched Properti’s design language. The quote PDF was attached to the HubSpot deal record automatically and emailed to the customer with a tracked link.
Payment and acceptance. Stripe Checkout linked from the quote PDF. Customer clicked, accepted the terms, paid. On payment, HubSpot deal moved to Won, customer record updated, onboarding triggered. No human involvement past the initial quote send.
End to end: salesperson opens HubSpot, clicks Quote, configures, sends. Customer receives, reviews, accepts, pays. HubSpot updates, finance sees the revenue, customer onboarding starts. Manual steps removed: at least four.
The pattern worth naming
The pattern I want a hiring manager to notice in this is not the Stripe and HubSpot integration. The Stripe and HubSpot integration is competent product work. Anyone good can do it.
The pattern is the diagnostic before the design. The default move when someone says "our quoting is broken" is to scope a tool. The harder move is to look at what’s already in the building and ask whether it’s being used to its potential. Most internal tooling problems at established companies are not tooling shortage problems. They are tooling under-utilisation problems.
Identifying which is which is judgement work, not procurement work. You don’t get there by reading G2 reviews. You get there by understanding what’s already in the stack, why it’s there, and what it could do if someone actually invested time in making it.
That’s the bit that generalises beyond this one project.
What I’d want someone to take away
Most internal tooling decisions are framed as "build vs buy." The more useful framing is "build, buy, or use better what you already have." That third option gets ignored because it isn’t sexy and nobody sells it to you. It is, in my experience, the right answer more often than the other two.
That, and: respect the five years of institutional knowledge sitting in your existing stack before you decide to throw it out.