Platforms
The spreadsheet nobody can replace
Most businesses have one. A spreadsheet, a shared inbox, a whiteboard, or a person who just knows. It works, right up until that person is on vacation or the file gets two versions.
The software you can buy almost fits. So you buy it, then you bend the business to match it, and eighteen months later there's a spreadsheet again beside the software you're paying for.
Sometimes the honest answer is that a spreadsheet is fine and you shouldn't build anything. I'll say so.
What the work is
Web application development
A web application is software that runs in a browser. Your team opens it on a laptop in the office or a phone at the job, and there's nothing to install or update on either one.
Before anybody writes code, I sit with whoever does the job today and watch them do it. The workarounds they invented to get through the week are the real spec.
Every screen gets tested against your real records before you sign off on it. A tool looks finished with ten sample jobs in it and falls apart when it meets years of the real thing.
Internal platforms
The thing your team uses all day. Quoting, scheduling, dispatch, inventory, approvals, whatever the actual work is. Built to the process you already run, not to a process a software company imagined.
Built for one operator staring at it for six hours, which is a different job from a website read once by a stranger. Dense, fast, keyboard-first, and boring on purpose.
Client portals
Every time a customer calls to ask where something is, they're doing your admin for you, badly, at the worst moment. A portal is where they answer that themselves — documents, status, history, invoices.
Mobile app development
For a real process, not a demo. We start with what your business does every day — the part still running on paper or in somebody’s memory — then build the thing that carries it.
A mobile app is the right answer when the work happens away from a desk and the phone is already in their hand. It's the wrong answer when a web page would do, and that's more often than anybody selling apps will tell you.
Software consulting
Sometimes you don't need anything built. You need somebody who has built this kind of thing to look at what you have and tell you what to do with it.
Before I recommend anything, I check two things about the software you already pay for. Can it export your data in a form something else can read, and does it have an API, which is the door other software uses to talk to it. Those two answers decide most of what is possible.
The answer is usually to set up the tool you have properly, or to buy one that fits. Building comes last because it costs the most. If the right answer is a product somebody else sells, I will name it, and there is nothing for me to build.
What it costs to run
You get the three-year number before you build, not after. It's usually the number that decides whether you should build at all.
I can give it to you because I've kept six of my own products running that long — through the part where the hosting bill is real, the dependencies need updating, and nobody is excited about it any more.
Questions people ask
- How do I know if we need custom software?
- When the process is genuinely yours and the off-the-shelf tools all require you to change how you work to fit them. If a tool fits, buy the tool. Building something you could have bought is the most expensive mistake in this category.
- Do we own the code?
- Yes. The code, the repositories and the hosting accounts are yours. There's no license, no per-seat fee to me, and no arrangement where the software stops working if we stop working together.
- What happens when it needs changes later?
- It will. Software isn't a project that ends, it's a thing that runs. That's what the partnership covers, and if you'd rather hand it to somebody else the code is written to be handed over.
- Can you work with the systems we already have?
- Usually. Most of this work is connecting things that were never designed to talk to each other. That's on the systems page.