What Running a Family Business Taught Me About Software Engineering

I have two desks. At one, I architect a 30+ microservice platform — Spring Boot, Cassandra, vector search, the kind of work I spent a decade doing on defense programs at Lockheed Martin. At the other, I am a 20% shareholder in a family portfolio of hotels and gas stations in South Florida, where the urgent questions are a broken ice machine, a review that stings because it's half-true, and whether the night audit reconciles. People assume the first desk subsidizes the second — that the engineer slums it in the family business. It has mostly worked the other way. The family business has been teaching the engineer for as long as I can remember, and these are the lessons that stuck.

Software is abstract; the customer's trust is not

My education in this started before my career did. My father was a mechanical engineer who owned a factory in Nairobi — I grew up understanding that a business is a physical, daily, human thing. Then, just out of high school in Florida, I started my own company in the dot-com years. We built websites, then taught office software, then ran a medical transcription service with an office in India. It did not make us rich. It made me wise in a way no course did: software is abstract, and abstract things are hard to sell. A customer can see and feel bricks and mortar and price them intuitively; an if statement is invisible. Nobody buys code — they buy the confidence that something they care about will be handled. Twenty-four years later, that's still how I evaluate every feature I build: not “is this technically good?” but “does this make someone's actual day trustably better?”

Owner-hours are the truest unit of cost

Engineering organizations measure story points, sprints, velocity. A family business has one metric that dominates everything: the owner's hours, because they are the only truly non-renewable input. When I automated our back-office and front-desk operations — statements filing themselves overnight, accounting prep, maintenance reminders that fire on schedule — the return wasn't measured in efficiency percentages. It was measured in whether my family members got their evenings back. That reframing follows me to the platform work: every system I build now gets asked whose hours it returns, and whether those hours matter to that person. A surprising amount of enterprise software fails this question quietly.

The front desk is the ultimate code review

On defense programs, feedback on my software arrived through structured channels — test reports, review boards, briefings. At an 88-room hotel, feedback arrives at the front desk at 11 p.m., unstructured and unfiltered, from a guest whose room key doesn't work. When I built QR-code landing pages so guests could get help without picking up the phone, I watched in real time which questions people actually had — not the ones I'd designed for. No requirements document has ever taught me as much as standing behind a front desk watching someone use something I built while they are tired and annoyed. Software is in service of humans; the family business makes that sentence impossible to forget, because the humans are standing right there.

Build for your successor, not your résumé

In a family business, every system you build will one day be run by someone who loves the business but did not build the system — a sibling, a cousin, a next generation. That constraint is clarifying: plain-language naming, boring technology, alerts that go to a shared mailbox, nothing that requires the builder to be reachable. I now apply the same test to platform architecture, and it's why my open-source work favors generated, conventional code over clever abstractions. The question is never “is this impressive?” It is: does this keep working when the person who built it is on a plane? Family businesses have asked that question for generations. Software teams are still learning to.

Judgment is the moat

I automate aggressively — but the family business taught me precisely where automation must stop. Machines fetch, file, remind, prepare. They do not decide what a distressed guest deserves, whether a vendor relationship is worth a price increase, or when a rule should bend. In a small business those judgment calls are the business; everything else is overhead to be automated away so the judgment gets more attention. I think about this constantly now that I build AI systems for a living: the goal was never to automate the innkeeper. It was to automate everything that stands between the innkeeper and the guest.

What I'd tell other engineers

Run something small and real, even briefly — a family operation, a side business, a stand at a market. Not for the income. For the calibration. You will learn what a dollar of revenue costs, what customers actually notice, and how it feels when your own money meets your own code. I went from Nairobi factory floors to a failed startup to defense programs to hotels, and every desk taught the others. The engineer builds better systems because the innkeeper knows what mornings are like. I wouldn't give up either desk.