What I learned building a website for a helicopter parts company
The rebuild was fifteen pages, a CMS, and a two-week deadline. The actual project was one form.
Canadian Air Parts sells helicopter and aircraft components to operators across North America, Europe, and the Middle East. Third-generation business, deep OEM relationships, serious inventory. Until this spring, its website had a stranded Covid-19 page, a row of broken partner logos, and fifteen menu items.
That’s not unusual. It’s close to the default for good small businesses: the company outgrows its website and nobody notices, because the people who know the business best never look at their own site. Customers do.
Dave, the owner, brought me in to rebuild it. On paper the job was design: new identity, new pages, something that finally matched the calibre of the operation. And I did that. But the thing I actually learned on this project had nothing to do with how it looks.
The old site had a request-for-quote function. Buried. A prospect with a part number in hand and real purchasing intent had to go hunting for the way to ask, and it’s a safe bet some of them gave up and rang a competitor instead. Meanwhile the navigation offered fifteen other places to go, none of which made anyone money.
The website was never the product. The path to a quote was.
Once I saw the project that way, most of my decisions were removals. Fifteen menu items became a handful. The Covid page went. Every page that survived earned its place by doing one of two jobs: convincing a prospect this company is what it actually is, or moving them toward the RFQ. One clear route from landing page to quote request, routed to the sales team, confirmation handled. That flow is the whole build. Everything else is set dressing around it.
BEFORE AFTER
home ─┬─ page home
├─ page │
├─ page ▼
├─ covid-19 page request a quote
├─ page │
├─ page ▼
├─ … fifteen in all sales team
└─ rfq (buried) │
▼
confirmationThe second thing I learned is about handover. My rule going in was that the site couldn’t depend on me. CAP’s team publishes their own knowledge-base articles and consignment stock updates through a CMS, with structured fields and a publish button. No developer in the loop, including the one who built it. If a small business needs to call someone to change their own website, something got built wrong.
And a third, more personal one. CAP was my first external client. I’ve built plenty of software inside businesses I help run, where if I want to change something I just change it. Building for someone else’s business meant asking instead of deciding, and it turns out the asking is where the value is. Most of my useful decisions came out of questions about how a part actually gets quoted and sold, not from anything technical. The code was the easy half.
The transferable lesson, if you run a business with a website you’re vaguely embarrassed by: your site is a workflow wearing a homepage. Find the one thing a visitor with money does on it. Make that thing unmissable. Then let almost everything else go.
Brief to production domain took two weeks. The full write-up, with before-and-after screenshots, is on the work page.
Working on something like this? hey@samjennings.dev