I am not running a software company.

This becomes slightly inconvenient every time I decide to build software.

Over time, though, I have become more interested in small internal systems because tourism creates an endless supply of operational problems that software is very good at remembering for you.

Bookings.

Pickup points.

Passenger counts.

Supplier handoffs.

Changes.

Notes.

Who needs what.

Whether somebody already sent the updated version.

None of these problems sounds particularly exciting.

That is partly why I like them.

Most small-business software starts before the software

Usually the first version is a person.

They remember everything.

Then the business grows slightly and the first version becomes a spreadsheet.

Then there are several spreadsheets.

Then WhatsApp.

Then somebody copies information from an email into the spreadsheet and sends part of it in WhatsApp.

Then somebody changes something.

Now there are two versions of reality.

This is the point where people often say they need “a platform.”

Maybe.

Sometimes they just need one small piece of software that knows where the truth lives.

I care more about reducing friction than adding features

This has become clearer to me while working on systems around Quick Morocco.

Take a small shared departure.

Four travellers.

One tour.

A few pickup locations.

Some notes.

The software can absolutely support vehicle allocation, capacity checks, supplier responsibility, traveller organization and handoff history.

But if the operator has to walk through twelve screens for a simple four-person departure, the software has failed even if every feature technically works.

Good tools should reveal complexity when the work becomes complex.

They should not force complexity onto easy work simply because the database knows how to store it.

This sounds obvious.

A lot of software does the opposite.

The danger of building what technology makes possible

New tools make building dramatically easier than it used to be.

That is useful.

It is also dangerous.

When the cost of adding something drops, your ability to justify unnecessary things becomes incredible.

Could we add a dashboard?

Yes.

Could we add another status?

Certainly.

Could we create an AI assistant for this button?

Probably.

Should we?

Different question.

I have become much more interested in subtraction.

What does the operator actually need to decide?

What information has to survive?

What can the system remember automatically?

Which controls only need to appear on bigger departures?

What can disappear entirely?

The software should earn every extra step.

You still need to understand the work

This is where being a non-software business can actually help.

I am building around operations I deal with.

I know why a pickup brief becomes annoying.

I know why accommodation names matter.

I know why changing one traveller after a supplier handoff creates another operational state.

That does not make me a software engineer.

It does mean I can recognize whether the tool solves the original problem.

And I think that distinction matters more now that code itself is becoming easier to produce.

Producing software and understanding the work are not the same skill.

You can have technically impressive software that misunderstands the business completely.

Software should remove memory from people

One of my favourite uses of a small internal system is simple: stop making humans remember things the system can remember.

If one accommodation normally maps to one meeting point, remember it.

If a brief changed after it was sent, show that.

If a vehicle cannot physically carry the people assigned to it, complain.

If the operator already confirmed something, keep the state.

These are not glamorous features.

They are tiny reductions in cognitive load.

Enough of those reductions together can change how a working day feels.

I am still learning what deserves software

Not every messy process needs an application.

Sometimes the process should be deleted.

Sometimes a spreadsheet is fine.

Sometimes the business itself is too unstable to encode yet.

And sometimes the process is repetitive enough, important enough and annoying enough that building a small tool becomes sensible.

That last category interests me.

I am not trying to turn the tourism businesses into technology startups.

I want technology to quietly remove stupid work from the tourism businesses.

If it can do that, I do not particularly care whether anybody calls it innovation.

I would rather the pickup list be correct.