Someone who understood search: how Google actually reads a page, why structured data matters, what makes one URL worth more than another. And someone who could open our codebase and change it.

I never found them.

I'm trained as an engineer. My degrees are in industrial engineering and computer science, with minors in business, entrepreneurship and statistics. I could read every one of these problems and tell you exactly what was wrong. That's precisely what made it maddening. The constraint was never whether I understood the work. It was time. Doing it properly takes real hours, and those hours belong to running the company.

The specialists understood search but couldn't ship. The engineers could ship but had no reason to care about a meta description. The agencies would happily audit our site and hand me a PDF of recommendations that someone on my team would then have to implement, which put me back where I started.

The rare people who genuinely did both were priced like a small department. For a company at our stage, paying that to fix something that should have been right from the beginning was hard to justify.

So the work sat there. Year after year.

What sitting there actually cost

It's easy to treat SEO as something you get to eventually. The cost is invisible until you look directly at it.

When I finally did, here's what I found on our own site.

Our structured data told Google our platform had a price of zero, across seven different pages. Nobody wrote that on purpose. It came from a copied block of code that spread quietly from page to page. For years, the machine-readable version of our business said something none of us would ever say out loud.

This is technical debt. Not the kind engineers argue about in planning meetings, but the kind that quietly misrepresents your business to every search engine that visits.

A page that should have been one URL was another, with no way for anyone to find the right one. Long sections of our most substantial content sat inside interface elements that search engines couldn't read at all. And we had five years of blog posts on a separate subdomain that generated essentially nothing of commercial value.

None of these are exotic problems. Every one of them was fixable in a day by someone who knew what they were looking at.

That's the part that bothered me. Not that the problems were hard, but that they were easy and still didn't get solved, because the work fell into the gap between two job descriptions.

Taking it back, with an AI coding assistant

At some point the frustration stopped being productive, and I decided to do it myself.

Not by sitting down and writing it line by line, which would have taken weeks I didn't have. By directing the work: decide what needed to be true, have an AI agent write the change, review it against what I know, and hand it to my team as a finished pull request instead of a wish list.

In a matter of weeks, the backlog I'd carried for five years was gone.

Structured data describing me and the company correctly, so a search engine understands who runs this business. The price-zero problem removed everywhere it had spread. The wrong URL retired properly. The unreadable content made readable. A content system that lets us publish guides without engineering time. And a writing section with its own publishing pipeline, which is how you're reading this essay.

Every one of those went to my engineering team the same way any other change does: as a pull request, reviewed, merged, and shipped on the normal release. Nobody's roadmap moved.

The rules came first

This isn't vibe coding. A live commercial site with customers on it is not a place to find out what the AI feels like building.

It only worked because I set the constraints before I set the AI loose.

Plan before code. Every task started with investigation and a written plan. Nothing changed until I read it and said yes. That single rule caught more problems than any review of the finished work would have.

Nothing changes without my approval. Not one file, not one line, not as a helpful extra.

Pull requests only, never a deploy. The AI could propose. My team decides what ships. That boundary never moved.

Only fix what we agreed to fix. No tidying, no "while I was in there."

The AI wrote the code. Every decision about what should exist was still mine.

Reviewing is the job

The most useful thing I can tell another founder is that generating the work is the easy part. Judging it is the job.

More than once, the plan that came back was wrong. A proposal to fix something that turned out to be commented-out code that never ran. A finding that reversed itself under closer inspection. A build check that would have worked perfectly on my machine and silently done nothing in production.

Each of those was caught because someone read the plan and asked what would actually happen. That is where the engineering training earns its keep. You have to be able to follow what the code will really do, understand the business well enough to know which answers are unacceptable, and be stubborn enough to say no to a confident-sounding recommendation.

That skill isn't new. It's the same thing you do with any proposal from any team. What's new is how many proposals you can evaluate in a week.

What this doesn't replace

I want to be precise here, because this is where these stories usually get oversold.

I didn't replace my engineering team. They build the product, which is a vastly harder problem than a marketing site. Their review still gates everything. They deploy, and I don't.

I also didn't stop being the CEO. My engineering training is why I could review this work honestly, but reading pull requests is not what my week is for. The point was never to become the person doing the implementation. It was to stop that being the reason nothing happened.

And I'd still hire the person I spent five years looking for. The difference is that not finding them is no longer a reason for the work to sit undone.

What actually changed

For most of my career, the distance between knowing what a company needs and having it built was measured in hiring cycles, budgets, and someone else's priorities.

That distance is shrinking fast. A founder who can specify clearly, set hard constraints, and review honestly can now close problems that used to require a hire they couldn't find or afford.

The bottleneck was never the code. It was translation, coordination, and waiting.

Five years of waiting ended in a few weeks of directed work. What I regret is the five years, not the weeks.

Very few will say payments.

Then ask what they did this morning.

Chased an overdue balance. Refunded a registration. Checked whether a deposit came through. Tried to figure out which kid a payment belonged to.

A surprising amount of running a sports facility is making sure money gets where it is supposed to go.

The moment a facility takes a registration fee online, it takes on a set of responsibilities that look a lot like running a payments business. Collecting money is the beginning. Someone also has to manage what happens before it arrives, after it arrives, and when it doesn't.

Nobody opened a facility because they wanted to become good at reconciliation. But here we are.

What a facility actually sells

Think about what a facility actually sells.

A parent registers a child in February for a league that starts in April. They pay part now and the rest later. Before the season starts, they switch divisions. A sibling signs up with a discount. One session gets canceled. Part of the fee becomes a credit toward summer camp.

Every one of those changes has a financial consequence.

The registration, the roster, the payment plan, and the credit all describe different parts of the same relationship with that family. The operator has to keep them consistent.

A checkout is not a season

That is a different problem from taking a payment at a retail counter.

Facilities sell access to something that will happen later. Sometimes it happens repeatedly. Sometimes the person paying is buying for several people. Sometimes a team organizer pays a deposit and everyone else pays their share.

A successful checkout tells you that one transaction worked. It tells you almost nothing about whether the money for an entire season is taken care of.

Where the work piles up

A card fails on the second installment. Does the registration still show as fully paid? Does anyone get notified? Who follows up with the parent?

A player withdraws. Does removing them from the roster stop the remaining payments, or does someone have to remember to do that somewhere else?

A coach checks a player in. Can they see that there is an outstanding balance, or does that information live with the one person who knows how to pull the report?

These are ordinary situations. A facility should be able to handle them without an employee reconstructing the story across three systems.

The coordination tax, priced in dollars

In an earlier essay, I called this the coordination tax: the work people do to keep disconnected systems moving together.

With payments, that tax shows up directly in the economics of the business.

It is the balance nobody follows up on because nobody sees it. The refund that takes several emails to resolve. The staff time spent matching deposits to registrations. The owner staying late to understand why the amount in the bank doesn't match what they thought they collected.

Some of the cost is missing revenue. Some is the time required to collect revenue that was already earned. And some is the damage to a customer relationship when a family has to explain the same billing issue to a different person.

A payment processing rate won't tell you any of that.

What embedded finance actually means here

In fintech, the term for this is embedded finance: financial services delivered inside the software a business already runs on, rather than as a separate product it has to integrate.

Most industries have already been through this. Ride-hailing, food delivery, and online marketplaces all stopped treating payments as a bolt-on and built them into the core of how the business works. Sports and recreation are arriving late, and the versions on offer are usually a processor attached to the side of a registration system.

Embedded payments in a facility should mean something more specific. A payment carries the context of what it is paying for. An installment stays connected to the registration. A refund is traceable to the original purchase. Staff can understand an outstanding balance without becoming experts in the payment processor.

When I think about the cost of payments, I think about the full path from someone deciding to register to the facility knowing the money is accounted for. How many times does a person have to intervene along that path? How many exceptions depend on someone remembering what happened?

That is the work good software should absorb.

Money moves to where the activity is

At Natty Hatty, this is why we think payments belong inside the operating system of the facility.

Our tap-to-pay capability is already in production. It is a simple example of the direction we believe this should go.

A facility's activity happens across the building. Staff are checking people in, answering questions, helping families, and keeping programs moving. Being able to take a payment where that interaction happens removes a reason to send someone back to a desk.

It is a small change in the payment experience, but it reflects a larger design principle: the financial part of an interaction should fit naturally into the work already happening.

Over time, I expect more of payments to work this way. The system will know what is owed, what it belongs to, and what needs attention. Operators will spend less time moving information between the financial side of the business and the people running the programs.

What stays with the owner

They will still make the judgment calls. Whether to offer a family more time to pay. Whether a cancellation deserves a refund. When an exception is the right thing to do.

Those decisions are part of running a community business. Software should give the owner enough context to make them well, then carry the decision through.

"Every facility is becoming a fintech company" sounds like a prediction about where the industry is going.

For the owner chasing a failed payment between games, it describes work they already do.

They start because their town needs a place to play. Because their daughter's team needs better competition. Because they believe they can build something people will want to come back to.

Then they open their laptop.

Create the season. Add the divisions. Set the age groups. Enter the fees. Build the registration form. Attach the waiver. Set up payments. Figure out the schedule.

Somewhere in that process, the person who wanted to build a sports community becomes a software administrator.

We have accepted this for a long time. We shouldn't have.

A chat box is not the answer

In my last essay, I wrote that complexity is a failure of design. When an operator has to carry the context, remember the exceptions, and tell the system what to do at every step, the software is leaving too much work unfinished.

AI gives us an opportunity to finish more of that work.

But most of the industry is aiming too low. The easy move is to put a chat box next to the same old forms and call it AI. The operator still does the translating. They just type it into a different box.

That isn't the shift. The shift is software that takes on the work itself.

What has changed is that software can now understand intent expressed in plain language. And a platform that already holds the registrations, payments, schedules, and rules has the context to act on that intent, not just record it.

Every setting is a translation problem

For years, sports software has followed a familiar pattern. An operator needs something. We add a setting. Another operator has a slightly different need. We add another setting.

Each addition makes sense on its own.

Eventually, building a league means understanding how dozens of settings interact. The operator knows what they want to run. Now they have to learn how the software wants it described.

That translation is work.

A registration fee might affect payment options. An age group might affect eligibility. A venue limitation might change the entire schedule. The operator becomes the person connecting all of it.

More features can help. They can also give that person more things to connect.

Describe the league, review the result

The shift I care about is what happens when software can take on that translation.

An operator should be able to say:

"I'm running a six-week youth basketball league. Three age groups. Games on Saturdays. Registration is $150, and families need an option to split the payment."

That should be enough to get the work started.

The system should use the information it has, ask for what is missing, and produce something the operator can review.

There will still be decisions. There will still be exceptions. But the operator should spend their time on those decisions instead of entering the same information in five places.

Where we are today

That is the direction we are building toward at Natty Hatty.

We are building Arya into the checkout builder so a customer can describe the checkout they need in a conversation and have the system build it.

The scope matters here. A checkout is a specific piece of work. Creating and running an entire league is a much bigger ambition.

The checkout work is a step toward that ambition. It is not evidence that we have already arrived.

Trust is earned in the details

Even within a checkout, the standard has to be higher than generating something that looks right. Fees need to be correct. Payment terms need to match what the operator intended. Missing information needs to trigger a question, not a confident guess.

An agent earns trust by getting the details right and making its work easy to check.

That is how this expands: useful work, a clear review, and more responsibility as the system proves itself.

The longer-term goal is for customers to create and run leagues by talking with Arya. To describe what they want to accomplish, work through the decisions, and let the system handle more of the setup and follow-through.

What stays human

The human responsibility does not disappear.

Someone still has to decide whether a league is affordable for its community. Whether an exception is fair. Whether a parent needs a conversation. Whether a competitive division is actually serving the kids in it.

Those decisions require judgment and relationships. Automating the administration should give operators more room for both.

A prediction

By the end of 2028, describing a league and reviewing a system-built setup will be a normal expectation in sports software.

Operators will still make the important calls. But manually configuring every division, fee, form, and rule will increasingly feel like doing work the system should already know how to do.

The title of this essay is a prediction, too. Somewhere, an operator is building their last league by hand.

They probably don't know it yet.

The bigger the company, the more processes it has. The more powerful the software, the more settings it needs. The more advanced the operation, the more people it takes to run.

We've learned to accept this as the price of doing anything serious. I don't think we should. Complexity is more often evidence that we stopped designing the system before we finished.

The measure of a sophisticated system isn't how much it can make you do. It's how much it can do without you.

Complexity accumulates quietly

Most systems don't start complicated. They become complicated one reasonable decision at a time.

A customer has a problem, so we add a feature. A team needs an exception, so we add a rule. Something goes wrong, so we add an approval. Information isn't available, so we add a report. Two systems don't talk to each other, so we put a person between them.

Every individual decision makes sense. Eventually the system as a whole doesn't.

More buttons. More settings. More documentation. More training. More dashboards. More people whose actual job is moving information from one place to another.

The problem isn't that each addition was wrong. The problem is that nobody went back and questioned the system itself.

Sports organizations are where this is easiest to see

I spend my time inside sports operations, and they're a near-perfect case study in accumulated complexity.

Registration lives in one place. Payments in another. Scheduling somewhere else. Teams, documents, commerce, communication — each in its own system, each of them working exactly as designed.

And the organization still runs inefficiently.

Consider what happens when a family registers a child for a fall program. Someone confirms the payment cleared. Someone checks whether the waiver was signed. Someone assigns the athlete to a team. Someone updates the roster the coach is working from. Someone makes sure the facility schedule reflects the new headcount. Someone emails the parent what happens next. When the family later changes a phone number, most of those systems never find out.

Nothing here is difficult. Every step takes a few minutes. Multiply it across a season and an organization has quietly built a full-time job out of copying information between products that should have known about each other from the start.

The real complexity doesn't live inside any of those products. It lives in the space between them.

Inherited processes disguise themselves as requirements

When something becomes complicated, the instinct is to improve what already exists. Make the process faster. Improve the interface. Automate a few steps. Add another integration.

All of that assumes the existing process is fundamentally correct.

First-principles thinking starts somewhere else. Strip the problem down to what must actually be true. What are we trying to accomplish? What is genuinely required? Which constraints are real, and which exist only because of decisions someone made years ago? Which steps would we never create if we were designing this today?

That last question does most of the work, because inherited processes are very good at looking like requirements.

We need this approval. Why? Because finance needs this report. Why? Because they need information from another system. Why isn't that information already available?

Keep going and you usually find that the workflow isn't solving the original problem at all. It's solving problems created by the architecture around the problem.

That's the moment redesign becomes possible.

Some complexity is necessary. Real systems operate under real constraints. But "that's how we've always done it" isn't a constraint. It's history. And history shouldn't get to dictate architecture.

The best workflow is the one that doesn't exist

Imagine a process with twelve steps. You could spend months making every step faster: better interfaces, fewer clicks, automated notifications, AI assistance. Maybe you cut the time in half. That's genuinely valuable.

But there's a better question. Do all twelve steps need to exist?

If eight can be removed entirely, you haven't built a faster workflow. You've built a smaller problem.

This is the principle I keep returning to, and it's the one most often skipped: never optimize something before proving it deserves to exist. Once a process becomes fast, people stop asking why they're doing it.

The same trap sits inside automation. Automation doesn't automatically produce good systems — it can just as easily make a bad system run faster. If five approvals aren't necessary, automating five approvals doesn't fix anything. If employees spend their days moving information between two systems, an integration helps, but the deeper question is why those systems were ever disconnected. If customers need a tutorial to complete a basic action, the interface is wrong.

So before automating anything, I ask three questions in order:

Does this need to happen? If it does, does a person need to make it happen? And if a person does, what's the minimum effort we should require from them?

Only then is automation the right tool. Otherwise we're using technology to preserve complexity instead of removing it.

Every handoff is a coordination tax

Complexity doesn't only live in interfaces. It lives in dependencies.

A customer changes their information. One system knows. Another doesn't. An employee spots the discrepancy and updates the second system. Someone gets an email. A spreadsheet changes. Another department eventually hears about it.

Technically, everything worked. Architecturally, something is wrong.

Every manual handoff is another opportunity for delay, misunderstanding, and failure. I call this the coordination tax. It doesn't appear on any budget line, which is exactly why it goes unexamined for years. It shows up instead as headcount, as slow response times, as the vague sense that everything takes longer than it should.

The clearest sign of poor system design is when people exist primarily to connect processes. Download this file. Upload it there. Copy this number. Email that department. Check whether they replied. Update the spreadsheet. Change the status. Notify the customer.

None of these actions are difficult. That's precisely why they survive. But thousands of tiny actions compound into enormous operational friction, and nobody can point to the moment it became a problem.

Humans are extraordinary at judgment, creativity, relationships, and decisions where the answer isn't obvious. Humans are an extraordinarily expensive way to move structured information from one database to another.

Information should move because the system understands where it belongs, not because someone remembered to move it. People shouldn't compensate for architecture. Architecture should enable people.

Complexity belongs inside the system

Simplicity gets misunderstood. Simple doesn't mean basic. It doesn't mean stripping out powerful capability, and it doesn't mean software that only works for simple businesses.

Some of the best-designed systems in the world are extraordinarily complicated underneath. The difference is that the user never has to manage that complexity.

Think about turning on a light. Behind that switch sits power generation, transmission, distribution, transformers, decades of electrical engineering, and countless safeguards. You think about none of it. You flip a switch.

The complexity didn't disappear. The system absorbed it.

That distinction is fundamental to how I build: complexity belongs inside the system, not on the user. The sophistication should be underneath. The simplicity should be what people experience.

The same principle applies to edge cases. It's tempting to accommodate everything: an option for this, a setting for that, a toggle for the unusual scenario. Eventually most users are navigating complexity built for a small minority of situations. Edge cases matter, but they shouldn't define the experience. The normal path should be obvious, and the system should absorb as much of the exception as it safely can. If a user has to understand the entire architecture to accomplish one task, we've transferred the designer's job to the user.

Scale reveals architecture

There's a common belief that complexity is simply the price of growth. I disagree. Scale usually reveals complexity that was already there.

A process requiring five minutes of manual work doesn't feel broken when it happens twice a week. When it happens twenty thousand times, you suddenly need a department.

The natural response is to hire. Sometimes that's right. But there's a question worth asking first: why does this require a person at all?

If every increase in volume demands a proportional increase in operational effort, the system isn't creating leverage. It's creating a larger operation. Good systems behave differently — volume can rise dramatically without effort rising at the same rate. That's one of the fundamental promises of technology, and most software quietly fails to deliver it.

The system should know more

For decades, software has mostly waited for instructions. Click this. Select that. Enter this. Confirm. Save. Submit. Repeat.

But systems increasingly have context. They know what happened previously. They understand relationships between information. They hold permissions, schedules, transactions, dependencies, and history. For the first time, AI makes it practical for systems to act on that context, not just store it.

That changes what software can be. Instead of only asking what did the user tell the system to do, we can ask what should happen next. If the answer can be determined safely and confidently, the system should handle it.

Go back to that fall registration. A registration shouldn't only create a registration. The system should understand what the registration means. Who registered. What they purchased. What program they're joining. What's owed. What needs signing. Where they need to be. Who needs to know. What happens next.

Those aren't eight unrelated workflows. They're consequences of a single event. The architecture should understand that.

This is why the future of sports technology isn't more software. It's infrastructure — a layer organizations operate on rather than manage.

The ultimate interface may not be a better dashboard. It may be needing the dashboard less often.

Subtraction is harder than addition

Adding something is easy. Removing something requires understanding.

You need to know why it exists. What depends on it. What breaks without it. Whether another part of the system can absorb its responsibility.

That's why simplicity is difficult. It demands going deeper than the interface — you have to understand the architecture well enough to remove complexity without removing capability.

The goal isn't minimalism. The goal is maximum capability with minimum unnecessary effort. That's a much harder standard.

The world isn't becoming less complicated. Businesses aren't getting simpler, sports organizations aren't getting simpler, and the systems underneath all of it will keep getting more sophisticated. That's inevitable. But sophistication and complexity aren't the same thing.

The job of good architecture is to absorb the sophistication and shield people from the complexity. When that happens, organizations don't just get faster. They get easier to run. People spend less time managing systems and more time doing work that actually requires a person. Customers never see the machinery. And growth stops requiring another layer of operational friction.

That's the standard I'm building toward.