Internal business tools
The systems your staff use every day: scheduling and dispatch, time tracking, inventory, work orders, invoicing, reporting. These replace the spreadsheet-and-paper layer that quietly runs most small companies.
Custom software · Sarasota, Florida
Software that fits how you already work.
Off-the-shelf software makes you change your process to match it. A custom application does the opposite. I build web and mobile apps for local businesses — and stay on afterwards to maintain them, because software is never finished on launch day.
Why businesses call
The signs you have outgrown your current setup
You do not need custom software because it sounds impressive. You need it when the tools you have started costing you more than they save. That usually looks like one of these:
- You pay per seat for four different products that do not talk to each other, and someone retypes the same data into all of them
- The business runs on a spreadsheet that only one person truly understands
- Crews fill out paper in the field and someone keys it in at night
- You have been told “the software just cannot do that” one time too many
- You are paying for a large product and using a small corner of it
- Your process is genuinely different from your competitors — and that difference is why customers pick you
What I build
Four kinds of work — and anything adjacent
Most projects start as one of these. If yours does not fit neatly, that is fine; describe the problem and I will tell you honestly whether I am the right person for it.
Customer-facing apps
Web and mobile apps your own customers use — booking, ordering, account portals, loyalty, job status tracking. Built to work on a phone first, because that is where they will open it.
Connecting software you already own
Integrations and automations so your existing tools pass data to each other instead of relying on a person to copy it across. Frequently the fastest and cheapest win available — and sometimes it removes the need to build anything.
Taking over an existing app
Inherited an application whose developer stopped answering? I can review the code, tell you honestly what shape it is in, take over maintenance, and get you back in control of your own system.
Currently in development
A full operations platform for a field-service company
I am midway through building a management platform that replaces a stack of disconnected tools for a company running crews across the region. It is real, in production planning, and shown here without their name, branding, or data.
What it covers
- Time punchCrews clock in and out from their own phones, with the job and task already attached — no paper, no retyping.
- Scheduling & dispatchWho is where, on which crew, with what equipment, across the whole week.
- InvoicingCompleted job data becomes an invoice without anyone entering it a second time.
- Payroll-ready exportsApproved timesheets export straight into payroll instead of being rebuilt by hand each period.
- Point of saleCounter and over-the-phone sales recorded against the same customer records.
- Inventory trackingMaterials tracked against the jobs that consumed them, so job cost is real rather than estimated.
Illustrative mock-up. Not a screenshot, and not real customer data.
Where I deliberately do not build from scratch
Some things carry real legal and financial consequences when they go wrong: payroll tax withholding, card payment handling, and anything storing card numbers. For those I integrate an established, compliant provider rather than reinventing it. Your app handles your process; the regulated plumbing stays with people who are audited for it. Any developer who offers to hand-roll payroll tax or card storage is quietly handing you their liability.
How a build actually goes
You see working software early, not at the end
The classic way software projects fail is a long silent stretch followed by a big reveal that misses the point. Phases exist to make that impossible.
1. Discovery
I spend time watching how the work actually happens — not how the org chart says it does. Most of the important detail lives in the workarounds people have stopped noticing.
2. Scope and fixed phase price
You get a written scope and a fixed price for phase one before anything is built. If the scope changes later, we price the change; you are never surprised by an invoice.
3. Clickable prototype
A prototype you can click through before real code exists. Changing a screen at this stage costs minutes. Changing it after launch costs days.
4. Phase one build
The single highest-value piece first — usually the one eating the most hours today. It goes live and starts paying for itself while later phases are still being built.
5. Pilot with real staff
A handful of people use it in real conditions before everyone does. This is where you find out that the crew leader has no signal at the back of the property.
6. Rollout and training
Everyone moves over, with training and written documentation that stays useful after I have left the room.
7. Ongoing maintenance
The part most people forget to plan for — and the reason apps quietly rot. See below.
After launch
Maintenance is the part nobody budgets for
An app is not a deliverable you receive once. Phones force operating system updates, browsers change, tax rates and price lists move, staff think of things nobody thought of during discovery, and dependencies need security patches whether or not you asked for new features.
Apps that get abandoned rarely break dramatically. They decay — an OS update breaks the camera upload, nobody fixes it, people work around it, and within a year everyone is back on paper.
Ongoing support covers:
- Security patches and dependency updates
- Keeping up with phone, tablet and browser updates
- Backups, uptime monitoring and restore testing
- Bug fixes as they surface
- Small feature additions and adjustments as the business changes
- Support for your staff when they get stuck
Maintenance is quoted per application once it is built, because a three-screen internal tool and a platform with a POS in it are genuinely different commitments. It is agreed in writing before launch, never assumed.
Common questions
Straight answers before you call
How long does an app take to build?
A focused internal tool that solves one clear problem is usually a matter of weeks. A multi-module platform is measured in months, which is exactly why it is built in phases — you should have something live and useful long before the whole thing is finished.
What does it cost?
It depends entirely on scope, so I do not publish a number I would have to walk back. What I can promise is how pricing works: a written scope and a fixed price per phase, agreed before that phase starts. You are never billed for work you did not approve, and you can stop after any phase and keep everything built so far.
Do I have to replace everything at once?
No, and you should not. The best first phase is usually the single process costing you the most hours right now. Everything else keeps running as it does today until its turn comes.
What happens if you get hit by a bus?
A fair question to ask any one-person shop. You own the code, it sits in a repository under your control, and it ships with documentation written for a developer who has never met me. That is the honest answer to single-person risk: make yourself replaceable on paper.
Can you take over an app somebody else built?
Often, yes. I start with a paid code review and give you a straight assessment — including if the honest answer is that rewriting is cheaper than rescuing. You get that assessment in writing either way, and you are free to take it elsewhere.
Will it work for crews out in the field?
That gets designed for specifically: it needs to work one-handed, on a cheap Android phone, in bright sun, with patchy signal. An app that assumes a desk and good Wi-Fi will not get used, and an unused app is worse than the paper it replaced.
Do you handle payroll tax or card payments yourself?
No, deliberately. Those integrate with established compliant providers. Your app owns your process; the regulated parts stay with specialists who carry that liability professionally.
Let's talk
Have a process that no software seems to fit?
Describe it in plain English — no technical vocabulary required. I will tell you honestly whether it needs a custom build, an off-the-shelf product, or just connecting up what you already own.