Selling Made Me a Better Builder
Writing code was the smallest part of making software matter. Shipping it, selling it, and sitting inside the industry it serves were harder, and each one changed what I built.
This picks up where The Start Date Everyone Gets Wrong ends: after the family conversations, after the interest had proved itself, when the actual work began.
Shipping: the part tutorials skip
Structured fundamentals came from Scrimba's full-stack course. Then I built a to-do app, part hand-coded, part AI-assisted, and deployed it live on AWS. I did this before I sat my first university lecture.
A to-do app is the most common beginner project there is. The app isn't the point. The deployment is.
Getting from "runs on my laptop" to "anyone can open it" meant dealing with hosting, environment configuration (getting the settings right on the server so the thing actually runs there), and the gap between a demo and a deployed product. Tutorials end where those problems begin.
The second lesson was about AI. There is a difference between asking it to write code for you and using it to think through a problem while you keep ownership of the decisions. The first makes you a typist for a model. The second makes you an engineer with a fast collaborator. Only the second one builds on itself.
The app is small. It's mine, and it's live.
The shift to being both a developer and a sales rep
After the app, I expected to go deeper into development. Samuel pushed me toward sales instead, specifically a sales role at Producer Framework, an agency management platform for financial services teams in Singapore.
I resisted. I was a developer. Why would I sell?
His argument, paraphrased: nothing moves without a sale. You can build the best product on earth, and if nobody buys it, it doesn't matter. Sales isn't the opposite of technical skill. It's what makes technical skill matter to anyone outside your own head.
The argument holds beyond my case. Engineers who treat sales as someone else's job build for an imagined customer. Engineers who have sat across the table from a real customer build for the problem the customer actually has.
What agency directors told me
As a sales rep, I sat in real meetings with directors and executives running insurance and financial advisory agencies in Singapore. Not case studies. Not hypotheticals. People running teams, telling me bluntly what wasn't working.
Three problems kept recurring:
- Activity tracking that fades within weeks. Agents log diligently at first, then stop once nobody acts on what they entered.
- A recruiting pitch built on promises instead of proof. Agencies couldn't show candidates evidence, so they sold hope.
- A feast-and-famine revenue cycle. Income swung hard enough to wear people down.
None of these are tooling gaps. They are structural problems in how agencies run day to day. A generic CRM, the standard software for storing contacts and tracking sales, bolted onto workflows it wasn't designed for doesn't fix structure. That's the gap Producer Framework targets: an operating system for the agency, not another contact database.
You cannot build good software for an industry you don't understand from the inside. Every hour in those meetings taught me more about what "the client actually needs" means than any spec document could.