Seven years of code after twenty years of sales

I wrote my first line of code after two decades of closing deals.

Before that, twenty years in finance. I sold third-party capital market products and looked after portfolios for high net worth clients, much of it in the secondary market, and finished as Senior Vice President and Country Head for Sales and Marketing. Then, about seven years ago, I started writing software, for one stubborn reason: I kept watching smart developers build the wrong thing.

People assume the career change was a reset. It wasn't. It was a translation. Almost everything I learned selling to demanding buyers turned out to have a twin in code. A few things I had to unlearn completely.

Why a sales head started writing code

Picture the meeting. A product team demos a feature they spent a quarter on. It's polished. It works. And the client in the room is quietly doing the maths on why it doesn't solve the problem they actually pay for.

I sat in that chair, on the client's side, more times than I can count. Every time, the gap was the same: the people building had never heard the buyer say the thing out loud. Nobody had translated "here's what keeps me up at night" into "here's what the software must do."

So I learned to do the translating myself, all the way down to the database. Not because sales was the wrong job. Because the most valuable seat turned out to be the one between the buyer and the code.

What twenty years of selling taught me about software

An error message is an objection

In sales, an objection isn't rejection. It's the first honest thing the buyer has said all meeting. You don't argue with it; you ask what's underneath it.

A stack trace is exactly that. It's the program telling you, precisely and without politeness, where your assumptions broke. Developers who treat errors as insults fight them. Developers who treat them as objections read them slowly and fix the real cause. I still read error messages like objections, and it has saved me more evenings than any tool.

Discovery beats demos

The best salespeople talk least in the first meeting. They ask what happens today, who signs off, what failed last time, what "done" looks like. Then they propose.

Software works the same way. A requirement written after a real discovery conversation is worth ten written from a feature list. That's why every build I take on starts with the person who pays, not just the person who clicks, which is the whole argument of building for the buyer, not just the user.

Money has to reconcile

Capital markets have one unforgiving rule: the numbers must agree, to the last unit, at the end of every day. Close enough is a phone call from compliance.

That instinct came straight into my code. Money as integers, never floats. Ledgers that prove themselves instead of balances we hope are right. Tests on the paths that move money before tests on anything pretty. You can see it in the billing work in a racket sports platform, where every statement has to settle to the cent.

Sophisticated buyers read the fine print

My old clients read every clause. So do good type systems. TypeScript is, in a way, fine print for your codebase: it refuses to let a vague promise pass as a contract. That's a big part of why every project I take on is TypeScript end to end.

What I had to unlearn

Not everything translated. Some habits that made me good at selling made me worse at building, at first.

The hardest one was the first. In a client meeting, "let me come back to you" can feel weak. In engineering, it's the most senior sentence there is.

Seven years in: what actually compounds

Frameworks don't compound. I've watched the fashionable choice change several times in seven years, and it will change again. What compounds is the boring stuff:

• Asking better questions before writing anything. Still the most valuable hour of any project.
• One language across the stack. Fewer contexts to switch, fewer places for bugs to hide. More in why I reach for Hono over Express.
• Owning the whole path. Design, interface, API, database and deployment in one head means fewer handoffs where meaning gets lost.
• Honest numbers. On this site that even means analytics that respect consent, because a dashboard full of flattering guesses is just a nicer-looking objection you haven't heard yet.

And one habit from sales that I never dropped: being genuinely fine with a "no." If I'm not the right builder for a project, I'd rather say so in the first call than discover it in the third month.

What this means if you're hiring a builder

You don't need someone who knows every framework. You need someone who can sit with your buyer, hear the real problem, and turn it into software that survives contact with real users and real money.

That's the seat I've spent twenty-seven years working toward, first from one side of the table and now from the other. Paul Graham's advice to do things that don't scale lands differently when you've spent decades doing exactly that, one client conversation at a time.

Turn your previous career into one useful build

If you are making a similar transition, choose a workflow you already understand. A quotation tracker, a stock discrepancy report or a follow-up list is a better first problem than “build the next everything.” Familiarity gives you something more useful than confidence: a way to notice when the software is wrong.

Try a small learning cycle. First, describe the real task and the annoying exception. Next, build the simplest version with sample data. Then ask someone to use it without coaching. Write down where they hesitate, what fails and which assumption you got wrong.

The deliverable is not a polished startup. It is a working slice and a short explanation of a tradeoff: why you chose this data structure, what happens when saving fails, or how you prevent an accidental duplicate. Those explanations become better portfolio material than another certificate screenshot.

Use the MDN curriculum to fill gaps systematically. Bring your domain knowledge to the exercises, and keep your financial commitments proportionate to the experiment. My path is one person's experience, not a timetable everyone should copy. Building for the buyer is where the old career and the new one meet most clearly.

Frequently asked questions

Is it too late to learn to code after a long career?

I started about seven years ago, after twenty years in finance, and I build full production products today. Age matters far less than what you bring with you. Domain knowledge, patience with demanding people and a habit of finishing things are rare in software, and they shorten the learning curve more than any course.

Does a sales background actually help a software engineer?

Yes, mostly in the parts nobody puts in a job description: discovery, saying "I don't know yet", handling feedback without ego, and understanding why someone will or won't pay. Those skills decide whether the right thing gets built at all.

What did you find hardest when switching to engineering?

Slowing down. Sales rewards momentum, while engineering punishes skipped details later. Learning to treat "let me reproduce it first" as strength rather than hesitation took the longest.

What kind of projects do you take on now?

Full-stack web and mobile products for founders, usually one or two at a time, in TypeScript with Next.js, Expo, Hono and PostgreSQL. The common thread is software that has to sell, not just ship. You can see the tools on the stack page, explore the portfolio, or read about Kyloth, my own product in development, which has not launched yet.

The translation never stops

Twenty years taught me why people buy. Seven years taught me how to build what they'll buy. The job, every single day, is translating between the two, and the day I stop doing that is the day I start building the wrong thing again. If you've got a product that needs to sell as well as it works, tell me what you're building.