I started my business in my forties, alongside my job and the responsibilities that come with having a family. I wanted to find out whether I could build something of my own.
I had twenty years of software experience behind me. I’d worked across different industries and led teams. I knew how to build things.
What I didn’t have was a single client, or much experience finding one for myself.
My first project would take twice as long as I’d estimated, involve a change of freight carrier, and expose a mistake in my own process that could have undone weeks of my client’s work.
At the end, the client thanked me and “the team.”
I’m still thinking about that.
A friend made the introduction
A friend who does SEO and social media mentioned my name to a retailer she worked with. They needed help with their online store, particularly shipping. She knew I could build things and connected us.
That was how it started.
I’d spent plenty of time thinking about how to present my business. My first opportunity came through someone who understood what I could do and knew a person who needed it.
There’s a practical lesson there if you’re trying to get started: make it easy for people to explain your work to someone else.
“I build software” can mean almost anything. “I help businesses get their online stores working, including the awkward integrations” gives someone a situation in which to remember you.
Your first client might come through a different route. Mine came through a conversation I wasn’t even in.
The job looked straightforward
The client wanted a store where customers could order their products online.
The complication was delivery. Some products could travel as parcels. Others needed to move on pallets by freight. A customer might put both types in the same order.
They wanted customers to choose their products, see an actual delivery price, and complete the purchase.
That meant building an online store and connecting the shipping services so checkout could handle the products the business actually sold.
I estimated eight weeks.
It took sixteen.
Much of that extra time involved the original freight carrier’s delays and, eventually, moving to another carrier. The client understood those problems were outside my control. They weren’t upset with me over them.
The parts I hadn’t allowed enough room for
About four weeks in, I had to change where I was doing the work.
I hadn’t been able to get the required carrier-rate setup working in the development environment I was using. We moved the work onto the client’s actual store, which brought a different level of care to every change.
The lesson for me was to validate that critical shipping path earlier. It was central to the whole project. I should have established that it worked in the intended environment before building so much around it.
Then I needed access credentials from the freight carrier.
I emailed their specialist and waited. Twelve days went by without a reply.
Meanwhile, the original delivery date kept getting closer. I kept the client informed about what we were waiting for and how it affected the project. They understood that I couldn’t move that part of the work forward without the carrier’s response.
I couldn’t make that person respond. I could keep my client informed about what was missing, what it affected, and what I was doing about it.
That distinction became important throughout the project. Some dependencies were outside my control. Keeping the client informed was still my responsibility.
I spent days looking for a mistake in my code
When the credentials arrived, the shipping quotes took eighteen to twenty-five seconds to come back.
That was too slow for the checkout flow. The freight options weren’t appearing when they needed to.
I assumed I’d done something wrong. I spent days checking my integration.
Then I examined the timing information in the carrier’s responses. It indicated that the quote calculation itself was finishing in under half a second, while the response was taking much longer to reach us.
That gave me something concrete to investigate and document. I put together the request timings and the information returned by their system, then sent it to them.
It gave the carrier specific evidence to investigate and helped explain why the integration was stalling.
For anyone doing client work, this is a skill worth developing: learn to measure a problem and explain what the evidence actually shows.
You don’t need to make someone look bad. You need enough clarity to decide what happens next.
Then the client changed carriers
The client eventually ended the relationship with that freight carrier over its customer service. Their frustration was with the carrier, and we moved forward with a replacement.
I understood the decision. It also meant the integration I’d spent so much time working on needed to change.
I had about two weeks to rebuild it around a different carrier.
The replacement returned quotes in two to five seconds. We got it working and shipped.
It would be easy to tell that part as a story about pulling off a difficult deadline. What I took from it was how much a supplier’s service can affect a project.
I’d estimated the work I expected to do. I hadn’t allowed enough room for the waiting, investigation, and changes surrounding it.
The mistake that was mine
During all of this, my code repository had fallen about two months behind parts of the live store.
The client had been making changes too: phone numbers, shipping policies, page content. Normal things an owner should be able to update.
My local version no longer reflected all of that work.
If I’d deployed it without checking, I could have overwritten the client’s changes and put a placeholder phone number back on the store.
I caught it before deploying. Nothing was wiped.
It still bothers me.
The carrier problems were frustrating, but this was a gap in my own process. I needed to reconcile what had changed on the store before pushing my version over it.
Experience doesn’t excuse that. It’s a reason to take it seriously and change how I handle the next project.
Finishing meant handing it over properly
The store eventually went live.
It could quote parcel and freight delivery at checkout, including mixed orders. Customers could see a delivery price and place their order.
I also handed over a written handbook so the staff could run the store without depending on me for every routine task.
That mattered to me. The client needed something they could operate after the build was done.
The invoice was paid in full.
The client sent a message praising the store’s appearance, speed, and functionality, and saying how satisfied they were with the result.
What stayed with me was their reference to “the team.”
There is no team of employees. It’s me, working from a basement office.
I took those words as a sign that the experience had felt supported. The client had someone handling the problems, explaining the decisions, and seeing the work through.
That meant a lot after sixteen weeks of wondering how my first project was going to turn out.
What I’m taking into the next one
I want to check the riskiest dependency earlier. In this project, that was getting a real shipping quote all the way through checkout.
I want my estimates to account for work involving other companies, including what happens when access is delayed or a service doesn’t behave as expected.
I want a clear process for handling changes the client makes while I’m still building.
And I want to keep communicating while a problem is unresolved. An update can explain what’s happening even when it can’t yet announce a fix.
Twenty years in software didn’t prevent the setbacks. What it gave me was practice dealing with them: investigating, documenting, explaining what was happening, and choosing a next step when the original plan stopped working.
That’s part of what we bring when we start something in our forties. We already have experience we can use, even while learning how to run a business.
I’m one completed client project in. I still have plenty to figure out.
But now, when someone asks what my business does, I have a finished store, a client’s feedback, and a very specific story to tell.
I’m glad I took the chance.
What happened on your first client project that you hadn’t thought to put in the estimate? Reply and tell me.