ModelBusiness and PYFFO Business are live on the App Store. Anyone can find them now without knowing me.
They both have dedicated websites explaining their processes and worth
It’s taken more than ten years to be in a position to write that sentence. Seeing them sitting there publicly, with my name attached, the first coherent thought wasn’t this is going to be huge. It was that took a while.
Where they came from
ModelBusiness goes back to around 2012. It’s a business planning and modelling tool, and the core of it hasn’t really changed: how do you capture what a business is actually doing, and turn that into something worth knowing?
In practice it’s for someone starting or running a small business (a plumber, a cafe, a shop) who needs to know whether the numbers work before committing to something. What profit looks like across five years. How many units have to go out the door before you break even. What a loan actually costs once the interest is in it. Answers to the questions that decide whether you do the thing or don’t.
The design was refined over years. Some of that was genuine improvement. Some of it was me going round in circles.
The circle I spent longest in was web app versus on device. I went back and forth for a long time, and not because I couldn’t make a decision. Both answers were defensible, and the right one kept moving as the tools changed underneath me. Then there was the question of how you capture the data at all: how much to ask someone for, how much to infer, and how to produce a result that means something rather than a number that merely looks authoritative.
That last one turns out to be the hard part of any tool like this, and it took me an embarrassingly long time to accept how much of the work it really is.
PYFFO came from somewhere else, and later. The idea has been with me the better part of a decade. I’ve written about where it came from, and it started as an anti-procrastination guide. The sensible next step would have been a video tutorial series. That was genuinely the plan for a while. It would have been quicker, and it would have been finished years ago.
Instead I looked at it properly and realised I’d been aiming at the wrong target. I’d been writing about getting yourself moving. The actual problem was usually that the process was crap. You’re not lazy. You’re doing a thing that takes four steps because nobody ever asked whether it needed to.
So the guide became a tool. PYFFO helps you find where the friction actually is, work out what’s worth changing, and then measure whether the change did anything. It won’t fix your processes for you. It will show you what they’re costing you, which is normally the part nobody has ever put a number on.
Presented with the easy version and the hard version of the same idea, I took the one that meant building an app. Fairly characteristic, that.
The work nobody sees
The late nights aren’t heroic. They’re mostly spent deciding things.
What should this actually do? What happens when someone answers I don’t know? If two people describe the same problem in different words, what do you do with the numbers?
That last one took me longer than any code I wrote. Run a couple of audits in PYFFO and eventually two observations turn out to be the same problem seen from different desks. You could add both figures to the total. It gives you a bigger number, and bigger numbers look better in a report. It’s also wrong, and the person who has to stand behind that report is the one who gets embarrassed by it.
So PYFFO holds the smaller figure back, tells you it’s done so, and asks you to decide. It never merges anything on its own.
That’s one decision. There are hundreds, and each one needs thinking about, building, and then testing to find out whether the thing you built behaves the way you decided it should. Usually it doesn’t, first time.
A lot of it was genuinely satisfying. There’s a specific pleasure in watching a screen finally do what you pictured months earlier, and the weekends weren’t some noble sacrifice. That’s mostly where the interesting bit lived, and I lost track of time in them regularly.
Not all of it, mind. Some of it was just grinding.
Two rejections
You finish. The thing works. You’ve tested it on real devices and you’re quietly pleased with it. Then you discover that finishing the software is roughly where the process starts.
Some of it is only fiddly: certificates, signing keys, screenshot sizes that differ subtly between stores, privacy declarations, content ratings. Tedious, but tractable. The education came from two rejections that were opposite in kind.
The first one, they were right. ModelBusiness came back rejected because it crashed on launch, which was baffling, because it ran perfectly on four physical devices sitting on my desk. It took a while to work out why: it only crashed on a device that had never had the app installed before. A safety check I’d added, one meant to protect people’s data, fired on a clean install and took the app down with it. Every device I’d tested on already had installation history on it, so not one of them could ever have shown me the problem.
That was humbling in a useful way. A reviewer found a real bug I’d have shipped to every new user, and I’d otherwise have discovered it via furious one-star reviews. Reproducing it meant starting from a genuinely clean device and walking the app’s first sixty seconds the way a stranger would, which is now the last thing I do before any build goes anywhere.
The second one, they weren’t. The next rejection said the app accessed content purchased outside it and needed to use in-app purchase. ModelBusiness has no in-app purchases. No subscription, no unlock, no restore, no premium tier, and no link out to anywhere you could pay for anything. One price, once, everything in the download. There was nothing to fix, because there was nothing there.
The temptation is to make the rejection go away: add something, change something, resubmit, just to get moving. That would have been the wrong move. It would have built the exact problem they thought existed.
So you don’t build anything. You write your position and you defend it. Carefully, because you’re arguing with someone who can simply say no again, and because being right isn’t the same as being persuasive to a stranger with a queue. I set out plainly what the app does and doesn’t contain, said I believed the flag had been applied in error, and asked, genuinely, that if there was a screen that prompted it, they point me at it so I could deal with it properly.
Then you wait, and the waiting is its own thing. One round took four days just to come back to a build I’d already fixed. There’s no conversation, no chance to spot the misunderstanding halfway through and correct it. The argument itself does the work; you just can’t make the answer arrive any sooner.
It was approved. Nothing rewritten, nothing removed. I’d only explained it.
There’s a related oddity worth mentioning. With PYFFO Business, the email telling me it was in review and the email telling me there was an issue are both stamped 5:35. I can’t tell you what happened in between, but it didn’t read like anybody had opened the app.
Telling people about it
Then you have to explain it to everyone else, and I don’t think I properly appreciated this beforehand. Building something and helping somebody understand why it matters are two different jobs, and I’d only planned for one of them.
Positioning. A website. Product descriptions that say something true and useful inside eighty characters. Screenshots that show the app doing real work rather than a title screen. Icons distinct enough that related apps on the same home screen don’t look like three copies of each other. Working out what the product is for, in words a person who has never met you understands in about four seconds.
None of that is coding, and I was slower at all of it. It’s also what decides whether anyone finds the product and whether they understand it when they do. The engineering can be sound and still never get looked at.
And yes, I noticed: a product whose whole purpose is finding unnecessary friction needed a remarkable amount of friction to get out the door. The irony was not lost on me.
The part that caught me out
I’ve been doing this a long time. I’ve shipped software for other people for years, presented it, taken the questions. I assumed I’d be fine.
Putting out something that’s yours is a different thing entirely.
Client work starts with an agreed problem and a shared idea of what good looks like. You can still get the execution wrong, and I have, but whether the problem was worth solving was settled before anybody wrote a line. Your own product hands that question back to you. You picked the problem. You decided this approach deserved a place in a market that never asked for it. Someone opens it and forms an opinion about your judgement, not just your work.
So the doubts arrived on schedule. Is the value obvious, or obvious only to me because I’ve been living inside it for a decade? Is it ready, or is ready just the word I’ve started using because I’m tired of the question? Would another month make it better, or only make me feel better?
That last one is the trap. There’s always another refinement available. I know the difference between improving something and hiding behind improving something, and knowing the difference doesn’t help much when you’re in the middle of it.
Experience doesn’t switch any of this off. It only means you recognise the feeling faster. You still have to push the button.
So
There’s more to do. PYFFO Business is still working its way through Google Play, the other two PYFFO editions are behind it, and there’s the small matter of anyone actually finding any of it.
But that’s tomorrow’s problem.
Two ideas I’ve been carrying for years are real things now, sitting out in the world with a page each and a download button, and other people can use them.
I built them. I finished them. I put them out.
I did it!