Lowboy
Bills of lading, billing and reporting for heavy haulage — on the web and on a tablet in the cab, built for one operator and for the next one.
- Laravel 12
- MySQL
- SwiftUI
- iPadOS
- REST API
- bcmath
- Multi-tenancy
Custom software development · Lutz, Florida
Off-the-shelf systems make you bend your process to suit the software. We do it the other way round — the application is built around the way the work already gets done, and it keeps working after launch.
What we build
Most engagements start the same way: something important is being held together by a spreadsheet, a paper form, or somebody's memory.
The application your operation runs on — orders, jobs, inventory, billing. Built to match your process rather than a generic one, with the states and approvals your business actually uses.
Native apps in Swift and SwiftUI, built to work offline first and sync when there is signal — because the field is where the work happens and the signal usually isn't.
Making systems that were never designed to talk to each other do exactly that, and turning what comes back into the report somebody actually has to produce.
Software that runs a business is never finished. Maintenance, changes and the next version are part of the engagement, not a separate conversation you have to start.
Selected work
Five builds, five different shapes of problem — an operation's billing, a consumer app, sensors nobody could report on, and the paperwork behind every new starter.
Bills of lading, billing and reporting for heavy haulage — on the web and on a tablet in the cab, built for one operator and for the next one.
A dive logbook for people who dive, built iPhone-first and honest about where your data lives.
Paper bills of lading replaced by a system that prices, approves, bills and reports on every load.
The paperwork for a new starter, produced correctly in about a minute instead of by hand each time.
Temperature sensors already on the network, turned into alerts that arrive in time and reports that arrive on their own.
In development
ServiceStack is a professional services automation platform for managed service providers — the system an MSP runs its own business on. Tickets, the time spent on them, what that time is worth against a contract, what you had to buy to do the work, and what the month actually left you.
It is not for sale yet. It is, however, the system this company's own service desk runs on, which is the short version of why it works the way it does: every decision in it was made by somebody who had to live with the last one.
Mail to the support address becomes a ticket, filed against the right client, with the attachments kept. Replies thread back onto the same ticket even when the client’s mail software drops the headers, and a reply to a closed one reopens it rather than vanishing.
Minutes go on the reply or the note they belong to, not onto a timesheet somebody fills in on Friday. Billable, covered by the agreement, or written off — decided once, while the work is fresh, rather than argued over at month end.
By the hour, a block of prepaid hours that draws down, or a monthly allowance with the overage billed at the rate. Response and fix targets per priority, with the clock on the ticket — because an SLA nobody can see is an SLA nobody meets.
Most of an MSP’s revenue is contracted and some of it is not, and the some is what gets forgotten. Pay-as-you-go tickets carry your list price, with on-site and remote priced apart — an hour at a client’s premises includes the drive.
The month’s unbilled work becomes an invoice, emailed to the address on the contract with a PDF attached — your letterhead, both addresses, every ticket itemized, and a tear-off remittance slip for whoever still pays by check.
The server, the switch, the laptop on reception — with the serial, the warranty date, and which of their buildings it is actually in. A ticket names the kit it is about and the site it is at, so “out of warranty since March” and “that one is at the Brandon office” are both on the screen before anybody drives anywhere.
Warranties expire quietly, and the first anybody hears of it is usually a dead server and an argument about who pays. The count of what runs out in the next sixty days sits on the screen whether or not anybody went looking — long enough to quote it, have it agreed, and get the part ordered at a price you chose rather than the one you were left with.
Their tickets, their replies, a way to raise a new one without writing an email, and the list of what you look after for them with what is still under warranty — showing them their own and nothing else. No internal notes, no time, no figures, and nothing belonging to anybody but them.
A quote goes out as a PDF with a link under it. They tick the lines they want, decline the ones they don’t, and type their name — and what comes back is a record of who agreed to what, and when, line by line. Nothing to print, sign and scan back.
An accepted quote raises the purchase order, carrying the parts they agreed to and not the ones they refused — and not the labor, which is not a thing anybody receives into stock. Counts move as orders arrive and as work goes out, so an item sitting at minus two is something sold and not yet reordered.
What you billed each month, what the parts behind it cost, and what that leaves — month against month, so this March can be read against last March. Labeled margin and not profit, because wages, the rent and the van are not in it, and a figure that flatters you is worse than no figure at all.
A rate, a status, an address — recorded with the name of whoever changed it and the value it held before. On the record itself rather than in a log you have to go and search, because the moment anybody wants it is the moment they are looking at a figure they don’t recognize.
Built on the work above rather than in place of it — if you run a service desk and this sounds like the one you wish you had, tell us what yours gets wrong.
How it goes
Most software that disappoints was never wrong technically — it was built before anyone had agreed what it was for.
Before anything is designed, we sit with the process as it runs today — including the spreadsheet nobody admits to and the step that only one person knows.
What it does, what it does not do, and what it costs — in plain language, before you commit. If the answer is that you do not need custom software, we will say so.
You see working software early and often, not a demo at the end. Changing your mind in week three is cheap; changing it after launch is not.
Going live is the middle of the project. Fixes, changes and the next version are expected, and the code is documented for whoever picks it up next — including if that is not us.
Who you would be working with
Lutz Computer Services is Patrick Brown — the person who scopes the work is the person who writes it and the person who answers the phone afterwards.
That is a deliberate limit on how much work runs at once, and it is the reason the systems above are still maintained years after they shipped. You will never be handed to an account manager, and nothing gets subcontracted to someone you have not met.
More about the practiceNext step
Describe the process that is costing you time. You will get a straight answer about whether custom software is worth it — including when it is not.
Start a project