Working remotely, before anybody called it that.
I started taking my own clients in 2015. That is roughly five years before the world discovered remote work, and at the time it was not a lifestyle or a movement. It was a thing you had to explain, usually more than once, to people who assumed you were between jobs.
What I actually did was run a small business. The work was digital marketing, and it was genuinely varied: SEO and analytics, managing content across a client's CMS, paid campaigns on Google and Facebook, email programs, funnels, the writing, the social accounts. Clients ranged from people starting something in a spare room to established businesses with real budgets.
The part nobody talks about is everything around the work. Contracts. Scoping something before you know how long it takes. Rates, and holding them. Invoices that go out on time and come back late. Deciding whether to chase a client who owes you or let it go and keep the relationship. Saying no to work you can technically do but should not take. Being the entire company, including the part of the company that has to have the awkward conversation.
Read a client wrong and you find out inside a month, because they stop paying you.
Having no boss did not mean answering to nobody. It meant answering to six or eight people at once, any of whom could leave at the end of the month. That turns out to be a harder manager than an actual manager.
It also meant nobody was going to send me on a course. If the way people expected a page to behave changed, or a platform half a client's business sat on moved the rules, or a tool everybody used got replaced by a better one, I had to know before they did. Staying current on design, on tools, on where things were actually heading, was not professional development. It was how the invoices kept going out. Ten years of that is why picking up something new does not feel like a risk to me.
For years I worked from time zones that did not line up with my clients, which forced me to write things down properly. If somebody could not ask me a question until their morning, the document had to answer it without me in the room.
Inside other people's companies.
Not all of it was freelance. For two years I was a senior project manager at a web and marketing firm, running ten to fifteen client projects at a time and coordinating designers, writers and a development team spread across time zones. Marketing sites rather than complex software, and the useful part was not the projects. It was learning to stand between somebody who wanted something and the people who had to build it, and to be careful with what I promised on their behalf.
Then several years with software companies. At Salesbox I onboarded B2B customers onto a done for you sales service, and worked alongside the teams building each client's outreach. At OpenBOM I ran the marketing for a SaaS product and ended up on the phone with people who were mid trial, asking what they were trying to do and where they got stuck. Nobody hired me for that part. The scope just kept widening until it was mine.
Those years are the reason I care about the difference between what somebody asks for and what they actually need. I heard the gap between those two things several hundred times before I ever built anything.
Now I build it myself.
I am not an engineer. I use AI to build working software, which means I can put a real product in front of a real person instead of stopping at a wireframe and hoping somebody else picks it up.
There are three of them so far. A restaurant operations platform with paying customers, which exists because I worked in New York restaurants long before any of this and knew exactly what the job looks like at seven on a Friday. A habit tracker in Spanish, which exists because of the ten years and the language. And a learning product, which exists because I got tired of not understanding what engineers were telling me.
The through line is not obvious from a resume. Everything I have done has been some version of the same job: figuring out what people actually need, and then being responsible for whether it works.