Most businesses end up running on a spreadsheet nobody wants to touch, or on a subscription that costs more every year and still does not quite fit. I build the software instead. Not a theme with plugins bolted on, an application written for the way your business actually works.
I have built this twice already, and I still run both
The tenth is the one your business actually runs on. So someone keeps a spreadsheet on the side, and now there are two versions of the truth.
Per seat, per location, per transaction. You grow, the bill grows faster, and the decision was made by a company you have never spoken to.
Your feature request goes into a roadmap you never see. A small change that would save your staff an hour a day is never going to happen.
Two of these are not examples. They are products I built and still operate: Zabtek POS, which runs a restaurant counter and its online ordering from one menu, and Staffed, which lets an organisation post open shifts and have staff claim them.
Taking orders at a counter and online from the same menu and the same prices, with the kitchen seeing both. This is Zabtek POS, which is live and taking real orders.
Posting open shifts, letting staff and volunteers request them, and approving without a group text chain. This is Staffed, which runs at staffedapp.com.
Somewhere your customers log in to see their job, their documents, their invoices or their history, instead of emailing you to ask.
The quoting sheet, the job tracker, the stock count. The spreadsheet that holds the business together, turned into something two people can use at once without breaking it.
Not a feature list. What happens today, where it goes wrong, and which part actually costs you money or time. Some of what you think you need usually turns out not to matter.
Written down, before the build starts. If the honest answer is that existing software already does this well enough, I will tell you that instead of selling you a build.
Working software you can click through, not a demo at the end. The parts that are wrong get found while they are still cheap to change.
Hosting, updates and fixes, by the person who wrote it. Or I hand over the code and the documentation and you take it in house.
Up front, yes. Whether it stays that way depends on what you are paying now and how many seats or locations you are adding. I will do that comparison honestly for your numbers, including the case where the subscription wins and you should keep it.
A focused internal tool can be weeks. Something like ordering or scheduling, with real users and payments, is months. You get a realistic range in the scope, not an optimistic one.
A fair question to ask a one-person shop. You own the code, it is written to be readable, and it ships with documentation so another developer can pick it up. I would rather you ask that now than find out later.
Often that is the better answer. Connecting your existing tools so they talk to each other is usually cheaper than replacing them, and I will say so when that is the case.
I build web applications that work properly on a phone, which covers most of what businesses actually need. If your use case genuinely needs a native app in the app stores, I will tell you that is outside what I do.
Tell me what your business does and where it keeps getting stuck. I will tell you whether custom software is the right answer, what it would cost, and when it is not worth building.