MobiFlex started with a question I couldn’t find a good answer to.
A mobile service business can’t just put a Calendly link on its website and let customers take the next empty hour.
The customer’s availability matters.
The business’s availability matters.
And because the business travels to the customer, geography matters too.
A free slot at 11am might look perfect until you realise the 10am job is on the other side of town.
So the original idea behind MobiFlex was availability-based scheduling: find the overlap between when the customer is available, when the business has capacity, and where the business will already be.
To do that properly, MobiFlex needed to understand the real working week. What was booked, when it was happening, and where the business would be.
Scheduling became the backbone.
And that was where the product started.
The calendar wasn’t where most of the business was getting lost
Once MobiFlex was being used in a real service business, a bigger problem became obvious.
Enquiries don’t always get deliberately lost.
They just get old.
Someone asks for a quote. Somebody says they’ll call back. A phone number gets saved. A couple of weeks pass, and suddenly nobody is quite sure who is waiting on who.
By then, following it up can feel more awkward than letting it go.
A lot of work isn’t lost because somebody said no.
It’s lost because nobody is quite sure what was supposed to happen next.
The same thing happens with customer history.
A returning customer calls and somebody has to piece together what happened last time. The person doing the job needs context. The owner still gets asked what was agreed, where to go, what to do, or what needs following up.
One capable person holding the business together can look like a system… until someone else needs to follow it.
That changed what I thought MobiFlex needed to become.
The old way isn’t wrong
One line I came across during this process stuck with me:
“You don’t need software, you just need a system. System first. Software second. Software should follow your pre-existing system.”
That matched what I was seeing.
A diary, phone, messages and memory aren’t bad ways to work. They are fast, familiar and flexible. They got the business this far.
The trouble starts when more people need to follow the work, when customers come back, when enquiries need chasing, or when the owner can’t keep every connection in their head.
And real service work does not always fit the neat shape software wants it to.
A traditional calendar wants an exact appointment. But sometimes a business only knows these four jobs are for Tuesday. Sometimes the work is at a workshop. Sometimes it makes sense to keep jobs from the same area together.
So the development process became pretty simple: build something useful, watch how it gets used, and change it when reality disagrees.
More than once, a real user ignored a feature we had built and found an easier way to do the same thing.
When the customer works around the software, that’s evidence about the software.
You can train the customer harder, or you can make the product fit the work better.
I’d rather do the second.
Less is more
This has probably become the strongest principle behind MobiFlex.
Not less capable. Just…
Less friction. Less duplication. Less clutter. Fewer unnecessary questions. Fewer things in the way of the next useful decision.
At one point I described the process as a “massive culling of $#!t before we add more.”
That still feels about right.
Software has a habit of creating its own work.
You answer an enquiry in Messenger, then enter it again in the CRM. You tell the system “no answer,” then it asks whether you contacted them, how you contacted them, and what happened.
Technically, all of that can be structured data.
But the operator shouldn’t have to perform the structure just because the software wants tidy fields.
If organising the business creates more admin than the disorder did, we haven’t solved the problem.
MobiFlex should carry complexity underneath so the person running the business doesn’t have to.
If the system already knows something, don’t ask again.
If a feature doesn’t match the way a business works, keep it out of the way.
Show the next decision that matters, not every decision the software is capable of making.
Making good business easier to practise
Most good operators already know the things they should be doing.
Reply to the enquiry.
Follow up the quote.
Call the person back.
Keep customer history.
Give the person doing the job enough context.
Remember the repeat work.
Know what happened last time.
Keep an eye on next week.
The hard part is doing all of those ordinary things consistently while the phone is ringing and the work still has to get done.
MobiFlex isn’t trying to teach good operators how to run their business. It’s trying to make good business easier to practise.
Scheduling is still central. It is still where MobiFlex started and where a lot of the working week comes together.
But the useful thread is broader now.
An enquiry comes in. Somebody follows it up. It becomes work. The person doing the job has the context they need. What happened becomes part of the customer history. The next step stays visible.
That is the system I’ve been trying to build.
Not a giant management platform.
A clean operating layer for a small service business.
A real service business has now been running its week in MobiFlex for months. Watching that happen has shaped the product far more than any original feature list could have.
And a lot of the recent work has not been about adding more. It has been about making what is there simpler, clearer and easier for the next business to pick up for itself.
MobiFlex still starts with the working week.
But the bigger idea is this:
Useful business knowledge shouldn’t have to live in one person’s head.
And as a good service business grows, the system around it should make it easier to run, not harder.
If some of this sounds familiar, MobiFlex was built for businesses like yours.